)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":8655,"name":"Jakub Libosvar","email":"libosvar@redhat.com","username":"jlibosva"},"change_message_id":"dd535065de360706c46f999a0976fcc09f91b03a","unresolved":false,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"How to support trunk ports with Open vSwitch Agent"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"This patch documents the various strategies that can be"},{"line_number":10,"context_line":"considered to support the vlan-aware-vms API with the"},{"line_number":11,"context_line":"OVS mech driver and respective agent."},{"line_number":12,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":12,"id":"7aa08908_87229c52","line":9,"range":{"start_line":9,"start_character":0,"end_line":9,"end_character":43},"updated":"2016-06-17 10:11:02.000000000","message":"Why does it belong to devref? Are described alternative approaches gonna be removed later after code for chosen solution is merged?","commit_id":"3088e93097770fcc67e64a0f0090b18be474f644"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"6497a1bc0fbdf1219e5f65c8fe385d269393324f","unresolved":false,"context_lines":[{"line_number":6,"context_line":""},{"line_number":7,"context_line":"How to support trunk ports with Open vSwitch Agent"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"This patch documents the various strategies that can be"},{"line_number":10,"context_line":"considered to support the vlan-aware-vms API with the"},{"line_number":11,"context_line":"OVS mech driver and respective agent."},{"line_number":12,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":12,"id":"7aa08908_253d848e","line":9,"range":{"start_line":9,"start_character":0,"end_line":9,"end_character":43},"in_reply_to":"7aa08908_87229c52","updated":"2016-06-17 20:04:07.000000000","message":"The rationale/comparison is provided to help answer questions like: \u0027why did you not choose approach X over Y? For future reference this should not be removed.","commit_id":"3088e93097770fcc67e64a0f0090b18be474f644"}],"doc/source/devref/openvswitch_agent.rst":[{"author":{"_account_id":6681,"name":"Brent Eagles","email":"beagles@redhat.com","username":"beagles"},"change_message_id":"57936757207b6978c83748cd039e3384b2902e0e","unresolved":false,"context_lines":[{"line_number":105,"context_line":"Bridge Management with Trunk Ports"},{"line_number":106,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"The current (as in liberty) ovs-agent cannot implement trunk ports. vifs"},{"line_number":109,"context_line":"are plugged into br-int. br-int ports are configured as VLAN access"},{"line_number":110,"context_line":"ports (as in ovs-vsctl add-port br-int PORT tag\u003dTAG). This means that"},{"line_number":111,"context_line":"br-int accepts untagged traffic from the VMs and tags that traffic with"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a5de9d1_2e4516b2","line":108,"updated":"2016-02-02 15:24:49.000000000","message":"Nit: we probably want to seek consistency. ovs-neutron-agent or simply \"agent\" for ovs-agent, VIFs for vifs, OVS for ovs, etc.\n\ns/cannot implement/does not support/","commit_id":"23e11491e68ca678c7b657726214f1048e18d61e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"408cc82723723aea4992d1ccd1b97ee11535d96b","unresolved":false,"context_lines":[{"line_number":105,"context_line":"Bridge Management with Trunk Ports"},{"line_number":106,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"The current (as in liberty) ovs-agent cannot implement trunk ports. vifs"},{"line_number":109,"context_line":"are plugged into br-int. br-int ports are configured as VLAN access"},{"line_number":110,"context_line":"ports (as in ovs-vsctl add-port br-int PORT tag\u003dTAG). This means that"},{"line_number":111,"context_line":"br-int accepts untagged traffic from the VMs and tags that traffic with"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a5de9d1_7ec7c064","line":108,"in_reply_to":"7a5de9d1_2e4516b2","updated":"2016-02-02 17:07:55.000000000","message":"Done","commit_id":"23e11491e68ca678c7b657726214f1048e18d61e"},{"author":{"_account_id":6681,"name":"Brent Eagles","email":"beagles@redhat.com","username":"beagles"},"change_message_id":"57936757207b6978c83748cd039e3384b2902e0e","unresolved":false,"context_lines":[{"line_number":109,"context_line":"are plugged into br-int. br-int ports are configured as VLAN access"},{"line_number":110,"context_line":"ports (as in ovs-vsctl add-port br-int PORT tag\u003dTAG). This means that"},{"line_number":111,"context_line":"br-int accepts untagged traffic from the VMs and tags that traffic with"},{"line_number":112,"context_line":"hypervisor-local vlan ids to separate tenant nets. All tagged traffic"},{"line_number":113,"context_line":"from VMs is dropped by ovs. Any trunk port implementation must accept"},{"line_number":114,"context_line":"tagged traffic from VMs and remap it. ovs ports themselves must act as"},{"line_number":115,"context_line":"trunk ports (as in ovs-vsctl set Port PORT vlan_mode\u003dtrunk)."}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a5de9d1_7dc4ad5e","line":112,"updated":"2016-02-02 15:24:49.000000000","message":"Is it worthwhile mentioning that VLAN ids are stripped from incoming packets as well?\n\nNit: s/nets/networks/","commit_id":"23e11491e68ca678c7b657726214f1048e18d61e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"408cc82723723aea4992d1ccd1b97ee11535d96b","unresolved":false,"context_lines":[{"line_number":109,"context_line":"are plugged into br-int. br-int ports are configured as VLAN access"},{"line_number":110,"context_line":"ports (as in ovs-vsctl add-port br-int PORT tag\u003dTAG). This means that"},{"line_number":111,"context_line":"br-int accepts untagged traffic from the VMs and tags that traffic with"},{"line_number":112,"context_line":"hypervisor-local vlan ids to separate tenant nets. All tagged traffic"},{"line_number":113,"context_line":"from VMs is dropped by ovs. Any trunk port implementation must accept"},{"line_number":114,"context_line":"tagged traffic from VMs and remap it. ovs ports themselves must act as"},{"line_number":115,"context_line":"trunk ports (as in ovs-vsctl set Port PORT vlan_mode\u003dtrunk)."}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a5de9d1_5e676425","line":112,"in_reply_to":"7a5de9d1_7dc4ad5e","updated":"2016-02-02 17:07:55.000000000","message":"Done","commit_id":"23e11491e68ca678c7b657726214f1048e18d61e"},{"author":{"_account_id":6681,"name":"Brent Eagles","email":"beagles@redhat.com","username":"beagles"},"change_message_id":"57936757207b6978c83748cd039e3384b2902e0e","unresolved":false,"context_lines":[{"line_number":112,"context_line":"hypervisor-local vlan ids to separate tenant nets. All tagged traffic"},{"line_number":113,"context_line":"from VMs is dropped by ovs. Any trunk port implementation must accept"},{"line_number":114,"context_line":"tagged traffic from VMs and remap it. ovs ports themselves must act as"},{"line_number":115,"context_line":"trunk ports (as in ovs-vsctl set Port PORT vlan_mode\u003dtrunk)."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"Below we list a few high level alternatives of supporting trunk ports with"},{"line_number":118,"context_line":"ovs."}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a5de9d1_bdfea536","line":115,"updated":"2016-02-02 15:24:49.000000000","message":"This last sentence is not clear here. Do you mean that the OVS port for the VIF must be configured as trunk ports to support passing tagged data?","commit_id":"23e11491e68ca678c7b657726214f1048e18d61e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"408cc82723723aea4992d1ccd1b97ee11535d96b","unresolved":false,"context_lines":[{"line_number":112,"context_line":"hypervisor-local vlan ids to separate tenant nets. All tagged traffic"},{"line_number":113,"context_line":"from VMs is dropped by ovs. Any trunk port implementation must accept"},{"line_number":114,"context_line":"tagged traffic from VMs and remap it. ovs ports themselves must act as"},{"line_number":115,"context_line":"trunk ports (as in ovs-vsctl set Port PORT vlan_mode\u003dtrunk)."},{"line_number":116,"context_line":""},{"line_number":117,"context_line":"Below we list a few high level alternatives of supporting trunk ports with"},{"line_number":118,"context_line":"ovs."}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a5de9d1_decd945e","line":115,"in_reply_to":"7a5de9d1_bdfea536","updated":"2016-02-02 17:07:55.000000000","message":"Exactly.","commit_id":"23e11491e68ca678c7b657726214f1048e18d61e"},{"author":{"_account_id":6681,"name":"Brent Eagles","email":"beagles@redhat.com","username":"beagles"},"change_message_id":"57936757207b6978c83748cd039e3384b2902e0e","unresolved":false,"context_lines":[{"line_number":120,"context_line":"Alternative 1 - Special treatment of trunk vifs"},{"line_number":121,"context_line":"+++++++++++++++++++++++++++++++++++++++++++++++"},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"An early (not merged) trunk port implementation chose to use a"},{"line_number":124,"context_line":"pair of MAC learning ovs bridges to remap between the VM-internal and"},{"line_number":125,"context_line":"hypervisor-local network domains. Legacy ports are plugged into br-int"},{"line_number":126,"context_line":"as usual. But for each trunk port a per-port bridge is created and"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a5de9d1_ddb4c183","line":123,"updated":"2016-02-02 15:24:49.000000000","message":"Maybe just \"proof of concept\" instead of \"not merged\"?","commit_id":"23e11491e68ca678c7b657726214f1048e18d61e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"408cc82723723aea4992d1ccd1b97ee11535d96b","unresolved":false,"context_lines":[{"line_number":120,"context_line":"Alternative 1 - Special treatment of trunk vifs"},{"line_number":121,"context_line":"+++++++++++++++++++++++++++++++++++++++++++++++"},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"An early (not merged) trunk port implementation chose to use a"},{"line_number":124,"context_line":"pair of MAC learning ovs bridges to remap between the VM-internal and"},{"line_number":125,"context_line":"hypervisor-local network domains. Legacy ports are plugged into br-int"},{"line_number":126,"context_line":"as usual. But for each trunk port a per-port bridge is created and"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a5de9d1_7ef10095","line":123,"in_reply_to":"7a5de9d1_ddb4c183","updated":"2016-02-02 17:07:55.000000000","message":"Done","commit_id":"23e11491e68ca678c7b657726214f1048e18d61e"},{"author":{"_account_id":6681,"name":"Brent Eagles","email":"beagles@redhat.com","username":"beagles"},"change_message_id":"57936757207b6978c83748cd039e3384b2902e0e","unresolved":false,"context_lines":[{"line_number":122,"context_line":""},{"line_number":123,"context_line":"An early (not merged) trunk port implementation chose to use a"},{"line_number":124,"context_line":"pair of MAC learning ovs bridges to remap between the VM-internal and"},{"line_number":125,"context_line":"hypervisor-local network domains. Legacy ports are plugged into br-int"},{"line_number":126,"context_line":"as usual. But for each trunk port a per-port bridge is created and"},{"line_number":127,"context_line":"sandwiched between the VM and br-int. That is the tap interface plugged"},{"line_number":128,"context_line":"into the per-port bridge and the per-port bridge patched to br-int."}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a5de9d1_083695b4","line":125,"updated":"2016-02-02 15:24:49.000000000","message":"Just a thought: Legacy or regular non-trunk ports? Legacy implies some kind of old type of port that has somehow \"survived\" changes and is there for backwards compatibility and that trunk ports somehow supercedes them. I guess if you include the context of Alternative 2, the notion of \"legacy\" makes sense. IRL, I don\u0027t consider a non-trunking port to a network as a legacy port ;)","commit_id":"23e11491e68ca678c7b657726214f1048e18d61e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"408cc82723723aea4992d1ccd1b97ee11535d96b","unresolved":false,"context_lines":[{"line_number":122,"context_line":""},{"line_number":123,"context_line":"An early (not merged) trunk port implementation chose to use a"},{"line_number":124,"context_line":"pair of MAC learning ovs bridges to remap between the VM-internal and"},{"line_number":125,"context_line":"hypervisor-local network domains. Legacy ports are plugged into br-int"},{"line_number":126,"context_line":"as usual. But for each trunk port a per-port bridge is created and"},{"line_number":127,"context_line":"sandwiched between the VM and br-int. That is the tap interface plugged"},{"line_number":128,"context_line":"into the per-port bridge and the per-port bridge patched to br-int."}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a5de9d1_14b8ebe4","line":125,"in_reply_to":"7a5de9d1_083695b4","updated":"2016-02-02 17:07:55.000000000","message":"Switched to using \u0027regular\u0027.","commit_id":"23e11491e68ca678c7b657726214f1048e18d61e"},{"author":{"_account_id":6681,"name":"Brent Eagles","email":"beagles@redhat.com","username":"beagles"},"change_message_id":"57936757207b6978c83748cd039e3384b2902e0e","unresolved":false,"context_lines":[{"line_number":123,"context_line":"An early (not merged) trunk port implementation chose to use a"},{"line_number":124,"context_line":"pair of MAC learning ovs bridges to remap between the VM-internal and"},{"line_number":125,"context_line":"hypervisor-local network domains. Legacy ports are plugged into br-int"},{"line_number":126,"context_line":"as usual. But for each trunk port a per-port bridge is created and"},{"line_number":127,"context_line":"sandwiched between the VM and br-int. That is the tap interface plugged"},{"line_number":128,"context_line":"into the per-port bridge and the per-port bridge patched to br-int."},{"line_number":129,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a5de9d1_039af6c5","line":126,"updated":"2016-02-02 15:24:49.000000000","message":"consider: Trunk ports, however, include a dedicated bridge between the VM and br-int. Instead of connecting directly to br-int, the VM connects to the trunk port\u0027s bridge which is connected by patch port to br-int.","commit_id":"23e11491e68ca678c7b657726214f1048e18d61e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"408cc82723723aea4992d1ccd1b97ee11535d96b","unresolved":false,"context_lines":[{"line_number":123,"context_line":"An early (not merged) trunk port implementation chose to use a"},{"line_number":124,"context_line":"pair of MAC learning ovs bridges to remap between the VM-internal and"},{"line_number":125,"context_line":"hypervisor-local network domains. Legacy ports are plugged into br-int"},{"line_number":126,"context_line":"as usual. But for each trunk port a per-port bridge is created and"},{"line_number":127,"context_line":"sandwiched between the VM and br-int. That is the tap interface plugged"},{"line_number":128,"context_line":"into the per-port bridge and the per-port bridge patched to br-int."},{"line_number":129,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a5de9d1_91162df0","line":126,"in_reply_to":"7a5de9d1_039af6c5","updated":"2016-02-02 17:07:55.000000000","message":"Done","commit_id":"23e11491e68ca678c7b657726214f1048e18d61e"},{"author":{"_account_id":6681,"name":"Brent Eagles","email":"beagles@redhat.com","username":"beagles"},"change_message_id":"57936757207b6978c83748cd039e3384b2902e0e","unresolved":false,"context_lines":[{"line_number":128,"context_line":"into the per-port bridge and the per-port bridge patched to br-int."},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"Here\u0027s a simplified drawing of this model. Details like the Linux bridges"},{"line_number":131,"context_line":"created by the hybrid ovs-linux firewall driver are intentionally omitted."},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"We also do not discuss yet where the boundary is between neutron and nova"},{"line_number":134,"context_line":"(ie. the vif driver). We believe we should decide on an ovs model first"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a5de9d1_43bd4e01","line":131,"updated":"2016-02-02 15:24:49.000000000","message":"Might be worthwhile mentioning that while they are supported they are omitted for simplicity.","commit_id":"23e11491e68ca678c7b657726214f1048e18d61e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"408cc82723723aea4992d1ccd1b97ee11535d96b","unresolved":false,"context_lines":[{"line_number":128,"context_line":"into the per-port bridge and the per-port bridge patched to br-int."},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"Here\u0027s a simplified drawing of this model. Details like the Linux bridges"},{"line_number":131,"context_line":"created by the hybrid ovs-linux firewall driver are intentionally omitted."},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"We also do not discuss yet where the boundary is between neutron and nova"},{"line_number":134,"context_line":"(ie. the vif driver). We believe we should decide on an ovs model first"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a5de9d1_31a099a5","line":131,"in_reply_to":"7a5de9d1_43bd4e01","updated":"2016-02-02 17:07:55.000000000","message":"Done","commit_id":"23e11491e68ca678c7b657726214f1048e18d61e"},{"author":{"_account_id":6681,"name":"Brent Eagles","email":"beagles@redhat.com","username":"beagles"},"change_message_id":"57936757207b6978c83748cd039e3384b2902e0e","unresolved":false,"context_lines":[{"line_number":132,"context_line":""},{"line_number":133,"context_line":"We also do not discuss yet where the boundary is between neutron and nova"},{"line_number":134,"context_line":"(ie. the vif driver). We believe we should decide on an ovs model first"},{"line_number":135,"context_line":"and draw the boundary between neutron and nova later."},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"By \u0027trunk port\u0027 later we mean a legacy port referred by an instance of the"},{"line_number":138,"context_line":"\u0027trunk\u0027 resource."}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a5de9d1_83f826c6","line":135,"updated":"2016-02-02 15:24:49.000000000","message":"Maybe merge with the previous paragraph?","commit_id":"23e11491e68ca678c7b657726214f1048e18d61e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"408cc82723723aea4992d1ccd1b97ee11535d96b","unresolved":false,"context_lines":[{"line_number":132,"context_line":""},{"line_number":133,"context_line":"We also do not discuss yet where the boundary is between neutron and nova"},{"line_number":134,"context_line":"(ie. the vif driver). We believe we should decide on an ovs model first"},{"line_number":135,"context_line":"and draw the boundary between neutron and nova later."},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"By \u0027trunk port\u0027 later we mean a legacy port referred by an instance of the"},{"line_number":138,"context_line":"\u0027trunk\u0027 resource."}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a5de9d1_d178252e","line":135,"in_reply_to":"7a5de9d1_83f826c6","updated":"2016-02-02 17:07:55.000000000","message":"Done","commit_id":"23e11491e68ca678c7b657726214f1048e18d61e"},{"author":{"_account_id":6681,"name":"Brent Eagles","email":"beagles@redhat.com","username":"beagles"},"change_message_id":"57936757207b6978c83748cd039e3384b2902e0e","unresolved":false,"context_lines":[{"line_number":134,"context_line":"(ie. the vif driver). We believe we should decide on an ovs model first"},{"line_number":135,"context_line":"and draw the boundary between neutron and nova later."},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"By \u0027trunk port\u0027 later we mean a legacy port referred by an instance of the"},{"line_number":138,"context_line":"\u0027trunk\u0027 resource."},{"line_number":139,"context_line":""},{"line_number":140,"context_line":"::"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a5de9d1_a3e3e204","line":137,"updated":"2016-02-02 15:24:49.000000000","message":"I\u0027m not sure what this means. With respect to previous usage of the term \"legacy\", isn\u0027t the trunk port definitely NOT a legacy port, i.e. configured as a trunking port allowing tagged and untagged traffic between the VM and the trunk\u0027s bridge? The only thing \"legacy\" about it is that it happens to be connected to a VM, isn\u0027t it?","commit_id":"23e11491e68ca678c7b657726214f1048e18d61e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"408cc82723723aea4992d1ccd1b97ee11535d96b","unresolved":false,"context_lines":[{"line_number":134,"context_line":"(ie. the vif driver). We believe we should decide on an ovs model first"},{"line_number":135,"context_line":"and draw the boundary between neutron and nova later."},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"By \u0027trunk port\u0027 later we mean a legacy port referred by an instance of the"},{"line_number":138,"context_line":"\u0027trunk\u0027 resource."},{"line_number":139,"context_line":""},{"line_number":140,"context_line":"::"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a5de9d1_3149798f","line":137,"in_reply_to":"7a5de9d1_a3e3e204","updated":"2016-02-02 17:07:55.000000000","message":"Maybe I just better delete this.","commit_id":"23e11491e68ca678c7b657726214f1048e18d61e"},{"author":{"_account_id":6681,"name":"Brent Eagles","email":"beagles@redhat.com","username":"beagles"},"change_message_id":"57936757207b6978c83748cd039e3384b2902e0e","unresolved":false,"context_lines":[{"line_number":189,"context_line":"            in_port\u003dPATCH-INT-END-OFPORT,actions\u003ddrop"},{"line_number":190,"context_line":""},{"line_number":191,"context_line":"    # make the tap port pass all tags"},{"line_number":192,"context_line":"    ovs-vsctl set Port TAP-PORT vlan_mode\u003dtrunk"},{"line_number":193,"context_line":""},{"line_number":194,"context_line":"    # install remap flows for untagged traffic (trunk port)"},{"line_number":195,"context_line":"    ovs-ofctl add-flow TRUNK-BRIDGE \\"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a5de9d1_2ecb5920","line":192,"updated":"2016-02-02 15:24:49.000000000","message":"By \"TAP-PORT\u0027 we are referring to the port that is connected to the guest, right? Maybe a table that defines the terms? e.g.\n\nTAP-PORT | port connected to guest\nTRUNK-BRIDGE | bridge interposed between guest and integration bridge (br-int)\n\netc.","commit_id":"23e11491e68ca678c7b657726214f1048e18d61e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"408cc82723723aea4992d1ccd1b97ee11535d96b","unresolved":false,"context_lines":[{"line_number":189,"context_line":"            in_port\u003dPATCH-INT-END-OFPORT,actions\u003ddrop"},{"line_number":190,"context_line":""},{"line_number":191,"context_line":"    # make the tap port pass all tags"},{"line_number":192,"context_line":"    ovs-vsctl set Port TAP-PORT vlan_mode\u003dtrunk"},{"line_number":193,"context_line":""},{"line_number":194,"context_line":"    # install remap flows for untagged traffic (trunk port)"},{"line_number":195,"context_line":"    ovs-ofctl add-flow TRUNK-BRIDGE \\"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a5de9d1_d4081330","line":192,"in_reply_to":"7a5de9d1_2ecb5920","updated":"2016-02-02 17:07:55.000000000","message":"Done","commit_id":"23e11491e68ca678c7b657726214f1048e18d61e"},{"author":{"_account_id":6681,"name":"Brent Eagles","email":"beagles@redhat.com","username":"beagles"},"change_message_id":"57936757207b6978c83748cd039e3384b2902e0e","unresolved":false,"context_lines":[{"line_number":235,"context_line":"* Two code paths to maintain in ovs-agent. Both handling similar things:"},{"line_number":236,"context_line":"  ports and trunk ports."},{"line_number":237,"context_line":"* If the per-port bridge is to be created by the vif driver,"},{"line_number":238,"context_line":"  the is_trunk_port bit must be passed to nova."},{"line_number":239,"context_line":"* Legacy ports cannot be turned into trunk ports after being added to a VM."},{"line_number":240,"context_line":"  That is the user have to make the decision to have a legacy port or a trunk"},{"line_number":241,"context_line":"  port before the VM is booted."}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a5de9d1_69514bd8","line":238,"updated":"2016-02-02 15:24:49.000000000","message":"What are the chances that nova is actually going to do this? Isn\u0027t it simpler just to have port binding process in neutron create the new bridge and send the appropriate event to nova that it currently uses to synchronize the vif plugging process?","commit_id":"23e11491e68ca678c7b657726214f1048e18d61e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"408cc82723723aea4992d1ccd1b97ee11535d96b","unresolved":false,"context_lines":[{"line_number":235,"context_line":"* Two code paths to maintain in ovs-agent. Both handling similar things:"},{"line_number":236,"context_line":"  ports and trunk ports."},{"line_number":237,"context_line":"* If the per-port bridge is to be created by the vif driver,"},{"line_number":238,"context_line":"  the is_trunk_port bit must be passed to nova."},{"line_number":239,"context_line":"* Legacy ports cannot be turned into trunk ports after being added to a VM."},{"line_number":240,"context_line":"  That is the user have to make the decision to have a legacy port or a trunk"},{"line_number":241,"context_line":"  port before the VM is booted."}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a5de9d1_8aa9127e","line":238,"in_reply_to":"7a5de9d1_69514bd8","updated":"2016-02-02 17:07:55.000000000","message":"I think we have to distinguish between two synchronization points.\n\nsync point B: neutron tells nova: You can go ahead with resuming the VM, because I\u0027m all done setting up the connectivity. The first frame sent by the VM will not be lost.\n\nsync point A: neutron tells nova: I\u0027m done creating the bridge where you want to plug. You can hand over the VM creation to libvirt. (From that point on nova does not have control over when the actual plug will happen.)\n\nAFAICT we have sync point B, but not sync point A. Nova assumes that it always plugs into the same integration bridge which is always there, so there\u0027s no need to wait for anybody. Of course if we want to create this sync point the event framework can be used for it.\n\nAlso nova stop/start and suspend/resume cycles can add some complexity here.","commit_id":"23e11491e68ca678c7b657726214f1048e18d61e"},{"author":{"_account_id":6681,"name":"Brent Eagles","email":"beagles@redhat.com","username":"beagles"},"change_message_id":"57936757207b6978c83748cd039e3384b2902e0e","unresolved":false,"context_lines":[{"line_number":286,"context_line":"* One code path to maintain in ovs-agent. The same code handles legacy ports"},{"line_number":287,"context_line":"  and trunk ports."},{"line_number":288,"context_line":"* Legacy ports can be turned into trunk ports after being added to a VM. That"},{"line_number":289,"context_line":"  is the user is free to add subports to any port at any time."},{"line_number":290,"context_line":""},{"line_number":291,"context_line":"Cons:"},{"line_number":292,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a5de9d1_eef6a1f8","line":289,"updated":"2016-02-02 15:24:49.000000000","message":"Is there even a use case for this? Doesn\u0027t it seem odd that a cloud guest would change in \"purpose\" to such an extreme.","commit_id":"23e11491e68ca678c7b657726214f1048e18d61e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"408cc82723723aea4992d1ccd1b97ee11535d96b","unresolved":false,"context_lines":[{"line_number":286,"context_line":"* One code path to maintain in ovs-agent. The same code handles legacy ports"},{"line_number":287,"context_line":"  and trunk ports."},{"line_number":288,"context_line":"* Legacy ports can be turned into trunk ports after being added to a VM. That"},{"line_number":289,"context_line":"  is the user is free to add subports to any port at any time."},{"line_number":290,"context_line":""},{"line_number":291,"context_line":"Cons:"},{"line_number":292,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a5de9d1_6ae4d6ab","line":289,"in_reply_to":"7a5de9d1_eef6a1f8","updated":"2016-02-02 17:07:55.000000000","message":"In the before-cloud-world there was nothing special in doing this.","commit_id":"23e11491e68ca678c7b657726214f1048e18d61e"},{"author":{"_account_id":6681,"name":"Brent Eagles","email":"beagles@redhat.com","username":"beagles"},"change_message_id":"57936757207b6978c83748cd039e3384b2902e0e","unresolved":false,"context_lines":[{"line_number":303,"context_line":"* All other upgrade methods requires unplugging from br-int and plugging"},{"line_number":304,"context_line":"  into the per port bridge. This means short interruption in vm network"},{"line_number":305,"context_line":"  connectivity (FIXME Really? ovsdb has atomic transactions. Are they atomic"},{"line_number":306,"context_line":"  on the control plane only, or in the data plane too?)."},{"line_number":307,"context_line":""},{"line_number":308,"context_line":"Alternative 3 - Remap without a bridge pair"},{"line_number":309,"context_line":"+++++++++++++++++++++++++++++++++++++++++++"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a5de9d1_ee71c1a9","line":306,"updated":"2016-02-02 15:24:49.000000000","message":"Do we have any information or has there been any discussion on what the performance impact of interposing the bridge between the VM and the integration bridge? I\u0027d think that we\u0027d want to keep the default paths as simple as possible.","commit_id":"23e11491e68ca678c7b657726214f1048e18d61e"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"408cc82723723aea4992d1ccd1b97ee11535d96b","unresolved":false,"context_lines":[{"line_number":303,"context_line":"* All other upgrade methods requires unplugging from br-int and plugging"},{"line_number":304,"context_line":"  into the per port bridge. This means short interruption in vm network"},{"line_number":305,"context_line":"  connectivity (FIXME Really? ovsdb has atomic transactions. Are they atomic"},{"line_number":306,"context_line":"  on the control plane only, or in the data plane too?)."},{"line_number":307,"context_line":""},{"line_number":308,"context_line":"Alternative 3 - Remap without a bridge pair"},{"line_number":309,"context_line":"+++++++++++++++++++++++++++++++++++++++++++"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a5de9d1_0a48c286","line":306,"in_reply_to":"7a5de9d1_ee71c1a9","updated":"2016-02-02 17:07:55.000000000","message":"That\u0027s a really important question. The usual high level claim of ovs is that multiple bridges in the logical model still collapses to a single set of data path flow rules. But I\u0027m no ovs expert, and I\u0027d really appreciate more input on this.","commit_id":"23e11491e68ca678c7b657726214f1048e18d61e"},{"author":{"_account_id":6788,"name":"Rossella Sblendido","email":"rsblendido@suse.com","username":"rossella-o"},"change_message_id":"1afed534dc70f2e4d2b54fdcc797708b3fd479a2","unresolved":false,"context_lines":[{"line_number":231,"context_line":""},{"line_number":232,"context_line":"    * a vif_type"},{"line_number":233,"context_line":"    * a vif detail inside a vif_type"},{"line_number":234,"context_line":""},{"line_number":235,"context_line":"This model has the following advantages and disadvantages:"},{"line_number":236,"context_line":""},{"line_number":237,"context_line":"Pros:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a5ae5dd_a1c42540","line":234,"updated":"2016-02-03 17:22:30.000000000","message":"another point that should be mentioned is that we need to find a way to pass to the agent all the information regarding the sub-ports in get_device_details.  Right now the agent monitors the ports that are created in the integration bridge and when it detects a new one, asks information to the neutron server and install the flows. If nova creates the trunk bridge, it will be connected to br-int so the agent will detect this new port. When asking for the details of this new port the agent should get that it\u0027s a trunk port and should get all the child-ports otherwise it won\u0027t be able to configure the flows correctly.","commit_id":"f8dd91771d34fd92912585eea75620d88d811f26"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"b940edc601a1a479c0fae8df8a9395341bd87827","unresolved":false,"context_lines":[{"line_number":231,"context_line":""},{"line_number":232,"context_line":"    * a vif_type"},{"line_number":233,"context_line":"    * a vif detail inside a vif_type"},{"line_number":234,"context_line":""},{"line_number":235,"context_line":"This model has the following advantages and disadvantages:"},{"line_number":236,"context_line":""},{"line_number":237,"context_line":"Pros:"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a5ae5dd_80073517","line":234,"in_reply_to":"5a5ae5dd_a1c42540","updated":"2016-02-10 15:31:43.000000000","message":"Will add this in the next patch set.","commit_id":"f8dd91771d34fd92912585eea75620d88d811f26"},{"author":{"_account_id":6788,"name":"Rossella Sblendido","email":"rsblendido@suse.com","username":"rossella-o"},"change_message_id":"1afed534dc70f2e4d2b54fdcc797708b3fd479a2","unresolved":false,"context_lines":[{"line_number":248,"context_line":"* Regular ports cannot be turned into trunk ports after being added to a VM."},{"line_number":249,"context_line":"  That is the user have to make the decision to have a regular port or a"},{"line_number":250,"context_line":"  trunk port before the VM is booted."},{"line_number":251,"context_line":""},{"line_number":252,"context_line":"Alternative 2 - Generic treatment of all VIFs"},{"line_number":253,"context_line":"+++++++++++++++++++++++++++++++++++++++++++++"},{"line_number":254,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a5ae5dd_21fef56b","line":251,"updated":"2016-02-03 17:22:30.000000000","message":"we need to add a way to manage those trunk bridges. For example when OVS restarts, we need to re-install the flows. So the agent needs to keep track of those bridges...","commit_id":"f8dd91771d34fd92912585eea75620d88d811f26"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"b940edc601a1a479c0fae8df8a9395341bd87827","unresolved":false,"context_lines":[{"line_number":248,"context_line":"* Regular ports cannot be turned into trunk ports after being added to a VM."},{"line_number":249,"context_line":"  That is the user have to make the decision to have a regular port or a"},{"line_number":250,"context_line":"  trunk port before the VM is booted."},{"line_number":251,"context_line":""},{"line_number":252,"context_line":"Alternative 2 - Generic treatment of all VIFs"},{"line_number":253,"context_line":"+++++++++++++++++++++++++++++++++++++++++++++"},{"line_number":254,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a57f1b5_eee7653e","line":251,"in_reply_to":"5a5ae5dd_21fef56b","updated":"2016-02-10 15:31:43.000000000","message":"Absolutely. We need to keep track of all objects in the bridge model.","commit_id":"f8dd91771d34fd92912585eea75620d88d811f26"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"e23ca0a4e22099727b4c638f1c6c44477c29e2be","unresolved":false,"context_lines":[{"line_number":249,"context_line":"  That is the user have to make the decision to have a regular port or a"},{"line_number":250,"context_line":"  trunk port before the VM is booted."},{"line_number":251,"context_line":""},{"line_number":252,"context_line":"Alternative 2 - Generic treatment of all VIFs"},{"line_number":253,"context_line":"+++++++++++++++++++++++++++++++++++++++++++++"},{"line_number":254,"context_line":""},{"line_number":255,"context_line":"Similar to Alternative 1, but eliminates direct plugging into br-int. All"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a5ae5dd_5ea1d0f6","line":252,"updated":"2016-02-08 16:07:51.000000000","message":"FWIW, this is my preference.  I think it\u0027s the best overall option.","commit_id":"f8dd91771d34fd92912585eea75620d88d811f26"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"6e06425934b82a1233b3087876f2db24506d3241","unresolved":false,"context_lines":[{"line_number":253,"context_line":"+++++++++++++++++++++++++++++++++++++++++++++"},{"line_number":254,"context_line":""},{"line_number":255,"context_line":"Similar to Alternative 1, but eliminates direct plugging into br-int. All"},{"line_number":256,"context_line":"ports must have a per-port bridge."},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"::"},{"line_number":259,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a57f1b5_3c581332","line":256,"updated":"2016-02-11 13:59:41.000000000","message":"since we already have a linuxbridge for security groups, what if we just use that and eliminate the OVS bridge? :P","commit_id":"f8dd91771d34fd92912585eea75620d88d811f26"},{"author":{"_account_id":6788,"name":"Rossella Sblendido","email":"rsblendido@suse.com","username":"rossella-o"},"change_message_id":"1afed534dc70f2e4d2b54fdcc797708b3fd479a2","unresolved":false,"context_lines":[{"line_number":253,"context_line":"+++++++++++++++++++++++++++++++++++++++++++++"},{"line_number":254,"context_line":""},{"line_number":255,"context_line":"Similar to Alternative 1, but eliminates direct plugging into br-int. All"},{"line_number":256,"context_line":"ports must have a per-port bridge."},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"::"},{"line_number":259,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a5ae5dd_e16d3d33","line":256,"updated":"2016-02-03 17:22:30.000000000","message":"we already have a per-port bridge, the linuxbridge used for security groups. That would make 2 bridges per port. Scary.","commit_id":"f8dd91771d34fd92912585eea75620d88d811f26"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"93c1e8c2bbed63abfb4ffdbd4e332ea232f637a7","unresolved":false,"context_lines":[{"line_number":253,"context_line":"+++++++++++++++++++++++++++++++++++++++++++++"},{"line_number":254,"context_line":""},{"line_number":255,"context_line":"Similar to Alternative 1, but eliminates direct plugging into br-int. All"},{"line_number":256,"context_line":"ports must have a per-port bridge."},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"::"},{"line_number":259,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a57f1b5_5d9626f1","line":256,"in_reply_to":"3a57f1b5_3c581332","updated":"2016-02-11 15:55:50.000000000","message":"The OVS firewall driver that eliminates the need for LB is here: https://review.openstack.org/#/c/249337/","commit_id":"f8dd91771d34fd92912585eea75620d88d811f26"},{"author":{"_account_id":6788,"name":"Rossella Sblendido","email":"rsblendido@suse.com","username":"rossella-o"},"change_message_id":"b5b7682396dd51f3ed03efb8fa70e760a5aefc38","unresolved":false,"context_lines":[{"line_number":253,"context_line":"+++++++++++++++++++++++++++++++++++++++++++++"},{"line_number":254,"context_line":""},{"line_number":255,"context_line":"Similar to Alternative 1, but eliminates direct plugging into br-int. All"},{"line_number":256,"context_line":"ports must have a per-port bridge."},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"::"},{"line_number":259,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a57f1b5_e4675623","line":256,"in_reply_to":"5a5ae5dd_4c4838b3","updated":"2016-02-11 09:22:01.000000000","message":"Thanks for the clarification. I hope the LB will go away soon but I don\u0027t see anybody working at the OVS firewall driver...am I missing something?","commit_id":"f8dd91771d34fd92912585eea75620d88d811f26"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"e23ca0a4e22099727b4c638f1c6c44477c29e2be","unresolved":false,"context_lines":[{"line_number":253,"context_line":"+++++++++++++++++++++++++++++++++++++++++++++"},{"line_number":254,"context_line":""},{"line_number":255,"context_line":"Similar to Alternative 1, but eliminates direct plugging into br-int. All"},{"line_number":256,"context_line":"ports must have a per-port bridge."},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"::"},{"line_number":259,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a5ae5dd_e3cfc526","line":256,"in_reply_to":"5a5ae5dd_e16d3d33","updated":"2016-02-08 16:07:51.000000000","message":"at least the LB is going away with the OVS firewall driver.\n\nWith LB eliminated, I don\u0027t think the separate OVS bridge should have a real effect on data path performance.\n\nIt\u0027s possible to *only* use br-int for this, but it would require fairly significant re-working of how the ovs agent uses OVS.","commit_id":"f8dd91771d34fd92912585eea75620d88d811f26"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"06272d67a9edc94ea90ac6cd6d8d14effd29dffe","unresolved":false,"context_lines":[{"line_number":253,"context_line":"+++++++++++++++++++++++++++++++++++++++++++++"},{"line_number":254,"context_line":""},{"line_number":255,"context_line":"Similar to Alternative 1, but eliminates direct plugging into br-int. All"},{"line_number":256,"context_line":"ports must have a per-port bridge."},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"::"},{"line_number":259,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a5ae5dd_4c4838b3","line":256,"in_reply_to":"5a5ae5dd_e3cfc526","updated":"2016-02-08 21:35:33.000000000","message":"To further clarify the claim about the separate bridge not affecting performance, the patch ports between 2 bridges are a concept in OVS userspace only.  It\u0027s optimized out when the flows are programmed in the kernel.","commit_id":"f8dd91771d34fd92912585eea75620d88d811f26"},{"author":{"_account_id":6788,"name":"Rossella Sblendido","email":"rsblendido@suse.com","username":"rossella-o"},"change_message_id":"1afed534dc70f2e4d2b54fdcc797708b3fd479a2","unresolved":false,"context_lines":[{"line_number":286,"context_line":""},{"line_number":287,"context_line":"This model requires passing less extra information from neutron to nova:"},{"line_number":288,"context_line":""},{"line_number":289,"context_line":"* The bridge name to plug into."},{"line_number":290,"context_line":""},{"line_number":291,"context_line":"This model has the following advantages and disadvantages:"},{"line_number":292,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a5ae5dd_e1269d15","line":289,"updated":"2016-02-03 17:22:30.000000000","message":"do we need that? A naming convention can be used just as it\u0027s done right now to create the linuxbridge connected to the port...","commit_id":"f8dd91771d34fd92912585eea75620d88d811f26"},{"author":{"_account_id":6788,"name":"Rossella Sblendido","email":"rsblendido@suse.com","username":"rossella-o"},"change_message_id":"b5b7682396dd51f3ed03efb8fa70e760a5aefc38","unresolved":false,"context_lines":[{"line_number":286,"context_line":""},{"line_number":287,"context_line":"This model requires passing less extra information from neutron to nova:"},{"line_number":288,"context_line":""},{"line_number":289,"context_line":"* The bridge name to plug into."},{"line_number":290,"context_line":""},{"line_number":291,"context_line":"This model has the following advantages and disadvantages:"},{"line_number":292,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a57f1b5_c47a5af1","line":289,"in_reply_to":"5a5ae5dd_838db1d4","updated":"2016-02-11 09:22:01.000000000","message":"Great :)","commit_id":"f8dd91771d34fd92912585eea75620d88d811f26"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"e23ca0a4e22099727b4c638f1c6c44477c29e2be","unresolved":false,"context_lines":[{"line_number":286,"context_line":""},{"line_number":287,"context_line":"This model requires passing less extra information from neutron to nova:"},{"line_number":288,"context_line":""},{"line_number":289,"context_line":"* The bridge name to plug into."},{"line_number":290,"context_line":""},{"line_number":291,"context_line":"This model has the following advantages and disadvantages:"},{"line_number":292,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a5ae5dd_838db1d4","line":289,"in_reply_to":"5a5ae5dd_e1269d15","updated":"2016-02-08 16:07:51.000000000","message":"Yes, you could use a naming convention, but even then you still have to pass a new piece of information to Nova (use this new naming convention to find the bridge instead of the one from nova.conf).  At that point, we might as well just tell nova the bridge name.\n\nAlso, I already implemented the ability to tell nova the bridge name, so hopefully we can stick with that.  :-)","commit_id":"f8dd91771d34fd92912585eea75620d88d811f26"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"e23ca0a4e22099727b4c638f1c6c44477c29e2be","unresolved":false,"context_lines":[{"line_number":299,"context_line":""},{"line_number":300,"context_line":"Cons:"},{"line_number":301,"context_line":""},{"line_number":302,"context_line":"* Regular ports are affected - both on the data and on the control planes."},{"line_number":303,"context_line":"* This model can only be a final state after an upgrade procedure. This"},{"line_number":304,"context_line":"  procedure must be invented to upgrade regular VIF wirings. If the upgrade is"},{"line_number":305,"context_line":"  gradual there will be two different kinds of VIF wirings coexisting at"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a5ae5dd_a37a2dbb","line":302,"updated":"2016-02-08 16:07:51.000000000","message":"I don\u0027t think the data plane impact is a real concern (at least once the OVS firewall driver is in use)","commit_id":"f8dd91771d34fd92912585eea75620d88d811f26"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"b940edc601a1a479c0fae8df8a9395341bd87827","unresolved":false,"context_lines":[{"line_number":299,"context_line":""},{"line_number":300,"context_line":"Cons:"},{"line_number":301,"context_line":""},{"line_number":302,"context_line":"* Regular ports are affected - both on the data and on the control planes."},{"line_number":303,"context_line":"* This model can only be a final state after an upgrade procedure. This"},{"line_number":304,"context_line":"  procedure must be invented to upgrade regular VIF wirings. If the upgrade is"},{"line_number":305,"context_line":"  gradual there will be two different kinds of VIF wirings coexisting at"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a57f1b5_83d1eacf","line":302,"in_reply_to":"5a5ae5dd_a37a2dbb","updated":"2016-02-10 15:31:43.000000000","message":"I only meant the change in the wiring, not in performance. Improved wording coming in the next patch set.","commit_id":"f8dd91771d34fd92912585eea75620d88d811f26"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"e23ca0a4e22099727b4c638f1c6c44477c29e2be","unresolved":false,"context_lines":[{"line_number":312,"context_line":"* All other upgrade methods requires unplugging from br-int and plugging"},{"line_number":313,"context_line":"  into the per port bridge. This means short interruption in vm network"},{"line_number":314,"context_line":"  connectivity (FIXME Really? ovsdb has atomic transactions. Are they atomic"},{"line_number":315,"context_line":"  on the control plane only, or in the data plane too?)."},{"line_number":316,"context_line":""},{"line_number":317,"context_line":"Alternative 3 - Remap without a bridge pair"},{"line_number":318,"context_line":"+++++++++++++++++++++++++++++++++++++++++++"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a5ae5dd_a328ed9a","line":315,"updated":"2016-02-08 16:07:51.000000000","message":"I think we\u0027re talking about a *very* short interruption here.","commit_id":"f8dd91771d34fd92912585eea75620d88d811f26"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"6e06425934b82a1233b3087876f2db24506d3241","unresolved":false,"context_lines":[{"line_number":312,"context_line":"* All other upgrade methods requires unplugging from br-int and plugging"},{"line_number":313,"context_line":"  into the per port bridge. This means short interruption in vm network"},{"line_number":314,"context_line":"  connectivity (FIXME Really? ovsdb has atomic transactions. Are they atomic"},{"line_number":315,"context_line":"  on the control plane only, or in the data plane too?)."},{"line_number":316,"context_line":""},{"line_number":317,"context_line":"Alternative 3 - Remap without a bridge pair"},{"line_number":318,"context_line":"+++++++++++++++++++++++++++++++++++++++++++"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a57f1b5_5c5b8f2e","line":315,"updated":"2016-02-11 13:59:41.000000000","message":"So in the reference implementation the security groups filtering bridge sits between libvirt and OVS. The part that needs to be replugged is between the filtering bridge and OVS. That could be done entirely without libvirt knowing.","commit_id":"f8dd91771d34fd92912585eea75620d88d811f26"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"93c1e8c2bbed63abfb4ffdbd4e332ea232f637a7","unresolved":false,"context_lines":[{"line_number":312,"context_line":"* All other upgrade methods requires unplugging from br-int and plugging"},{"line_number":313,"context_line":"  into the per port bridge. This means short interruption in vm network"},{"line_number":314,"context_line":"  connectivity (FIXME Really? ovsdb has atomic transactions. Are they atomic"},{"line_number":315,"context_line":"  on the control plane only, or in the data plane too?)."},{"line_number":316,"context_line":""},{"line_number":317,"context_line":"Alternative 3 - Remap without a bridge pair"},{"line_number":318,"context_line":"+++++++++++++++++++++++++++++++++++++++++++"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a57f1b5_3d71eae0","line":315,"in_reply_to":"3a57f1b5_5c5b8f2e","updated":"2016-02-11 15:55:50.000000000","message":"That\u0027s true, as long as the env hasn\u0027t started using this yet: https://review.openstack.org/#/c/249337/","commit_id":"f8dd91771d34fd92912585eea75620d88d811f26"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"b940edc601a1a479c0fae8df8a9395341bd87827","unresolved":false,"context_lines":[{"line_number":312,"context_line":"* All other upgrade methods requires unplugging from br-int and plugging"},{"line_number":313,"context_line":"  into the per port bridge. This means short interruption in vm network"},{"line_number":314,"context_line":"  connectivity (FIXME Really? ovsdb has atomic transactions. Are they atomic"},{"line_number":315,"context_line":"  on the control plane only, or in the data plane too?)."},{"line_number":316,"context_line":""},{"line_number":317,"context_line":"Alternative 3 - Remap without a bridge pair"},{"line_number":318,"context_line":"+++++++++++++++++++++++++++++++++++++++++++"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a57f1b5_6e6e15cb","line":315,"in_reply_to":"5a5ae5dd_a328ed9a","updated":"2016-02-10 15:31:43.000000000","message":"The re-plug could get hairy not just because the interruption in connectivity. Think about that libvirt did the plug in the first place. If we re-plug the tap interface while libvirt still knows about the original plugging that could lead to really ugly situations. Is there a way to get libvirt do the re-plug? Probably not.","commit_id":"f8dd91771d34fd92912585eea75620d88d811f26"},{"author":{"_account_id":6788,"name":"Rossella Sblendido","email":"rsblendido@suse.com","username":"rossella-o"},"change_message_id":"1afed534dc70f2e4d2b54fdcc797708b3fd479a2","unresolved":false,"context_lines":[{"line_number":317,"context_line":"Alternative 3 - Remap without a bridge pair"},{"line_number":318,"context_line":"+++++++++++++++++++++++++++++++++++++++++++"},{"line_number":319,"context_line":""},{"line_number":320,"context_line":"Given a single bridge and sufficiently complex flow rules it is theoretically"},{"line_number":321,"context_line":"possible to remap between the VM-internal and hypervisor-local domains without"},{"line_number":322,"context_line":"a per-port bridge. Given my limited understanding of what is possible with ovs"},{"line_number":323,"context_line":"this seems to be in conflict with using MAC learning bridges (actions\u003dnormal)."}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a5ae5dd_3c14dcf3","line":320,"updated":"2016-02-03 17:22:30.000000000","message":"Something like that should work:\nImagine we have a trunk port and 2 child ports\n1) one with seg ID 1 that belongs to network1, that it\u0027s using internally VLAN 3\n2) with seg ID 2 that belongs to network2 that it\u0027s using internally VLAN 4\n\nThe flows that need to be installed for the trunk port are:\nIncoming packets:\n1) if they have VLAN 3, they are meant for subport1 so, strip VLAN 3 and push VLAN 1\n2) if they have VLAN 4, they are meant for subport2, strip VLAN 4 and push VLAN 2\nOutgoing packets:\n1) if they have VLAN 1, strip it and push VLAN 3\n2) If they have VLAN 2, strip it and push VLAN 4\n\nFor untagged traffic the flows are the same as they are now.","commit_id":"f8dd91771d34fd92912585eea75620d88d811f26"},{"author":{"_account_id":8788,"name":"Miguel Angel Ajo","email":"mangelajo@redhat.com","username":"mangelajo"},"change_message_id":"7b59c797c46961621fe48290e52fccc0c2cf463a","unresolved":false,"context_lines":[{"line_number":317,"context_line":"Alternative 3 - Remap without a bridge pair"},{"line_number":318,"context_line":"+++++++++++++++++++++++++++++++++++++++++++"},{"line_number":319,"context_line":""},{"line_number":320,"context_line":"Given a single bridge and sufficiently complex flow rules it is theoretically"},{"line_number":321,"context_line":"possible to remap between the VM-internal and hypervisor-local domains without"},{"line_number":322,"context_line":"a per-port bridge. Given my limited understanding of what is possible with ovs"},{"line_number":323,"context_line":"this seems to be in conflict with using MAC learning bridges (actions\u003dnormal)."}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a5ae5dd_3bd474ea","line":320,"in_reply_to":"5a5ae5dd_3c14dcf3","updated":"2016-02-05 15:16:36.000000000","message":"IMHO, if we were able to make this work, this would be the simplest option, because we don\u0027t have any overhead to the system via extra bridges or complexity.\n\nIt\u0027s true that extra rules, of course, add extra complexity, but this is the OVS agent, isn\u0027t it? :)\n\nIf we were able to implement the rules in a tiny POC (a\u0027la [1]), that\u0027d be great.\n\nI was thinking of one option : not tag the trunk ports (via ovs-vsctl set tag..) and then have a pipeline:\n\nwith (the most complex case) two ports (A.X,B.Y) on the same br-int trying to talk to each other over vlan/net 1 (only one direction implemented A-\u003eB and A-\u003eothers/normal)\n\n# outgoing packets\nin_port\u003dA, dl_vlan\u003dX, action\u003dmod_vlan_vid:1,resubmit(,NEXT)\naction\u003dresubmit(,NEXT) # for outgoing packets not modified\n\n# incoming packets\ntable\u003dNEXT,dl_vlan\u003d1, dl_dst\u003dxx:xx:xx:xx:xx:xx, mod_vlan_vid:Y, output:B\ntable\u003dNEXT,dl_vlan\u003d2, dl_dst\u003dxx:xx:xx:xx:xx:xx, mod_vlan_vid:Z, output:B\ntable\u003dNEXT,dl_vlan\u003d3, dl_dst\u003dxx:xx:xx:xx:xx:xx, mod_vlan_vid:W, output:B\ntable\u003dNEXT,action\u003dNORMAL  # for remaining packets which don\u0027t go to a VM hooked to this br-int and need to go out...\n\n\nbut then, if we use normal, other unrelated ARP and ICMP packets could be sent to the non vsctl set tagged ports... hmmmm....., and we\u0027re missing the broadcast traffic... \n\nProbably if we want to go this route we may need  to refactor and avoid NORMAL rules at all....\n\n\nThoughts?\n\n\n\n[1] https://github.com/mangelajo/ovs-experiments/blob/master/qos/qos_complex_traffic_shapping.sh","commit_id":"f8dd91771d34fd92912585eea75620d88d811f26"},{"author":{"_account_id":10528,"name":"Fengshou Zhao","email":"zhao.fengshou@zte.com.cn"},"change_message_id":"32312a673fa700eea10a7c295e599df1f850db20","unresolved":false,"context_lines":[{"line_number":317,"context_line":"Alternative 3 - Remap without a bridge pair"},{"line_number":318,"context_line":"+++++++++++++++++++++++++++++++++++++++++++"},{"line_number":319,"context_line":""},{"line_number":320,"context_line":"Given a single bridge and sufficiently complex flow rules it is theoretically"},{"line_number":321,"context_line":"possible to remap between the VM-internal and hypervisor-local domains without"},{"line_number":322,"context_line":"a per-port bridge. Given my limited understanding of what is possible with ovs"},{"line_number":323,"context_line":"this seems to be in conflict with using MAC learning bridges (actions\u003dnormal)."}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a5ae5dd_ffe53108","line":320,"in_reply_to":"5a5ae5dd_3c14dcf3","updated":"2016-02-08 08:49:01.000000000","message":"This way works. But it seems that the VLAN_ID assignment of a subport and ordinary port is not consistent. The former one is assigned by CLI command or Neutron Server, the later one is assigned by agent.","commit_id":"f8dd91771d34fd92912585eea75620d88d811f26"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"b940edc601a1a479c0fae8df8a9395341bd87827","unresolved":false,"context_lines":[{"line_number":317,"context_line":"Alternative 3 - Remap without a bridge pair"},{"line_number":318,"context_line":"+++++++++++++++++++++++++++++++++++++++++++"},{"line_number":319,"context_line":""},{"line_number":320,"context_line":"Given a single bridge and sufficiently complex flow rules it is theoretically"},{"line_number":321,"context_line":"possible to remap between the VM-internal and hypervisor-local domains without"},{"line_number":322,"context_line":"a per-port bridge. Given my limited understanding of what is possible with ovs"},{"line_number":323,"context_line":"this seems to be in conflict with using MAC learning bridges (actions\u003dnormal)."}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a57f1b5_34faaabe","line":320,"in_reply_to":"5a5ae5dd_fe6c3cd1","updated":"2016-02-10 15:31:43.000000000","message":"I mentioned this alternative for the sake of completeness but I think it would be actually very complicated to implement it. First of all this would not simply change ovs-agent itself, but the ovs model would need to get re-designed (I mean how ovs configuration looks like).\n\nLet me reach back to Rossella\u0027s example. If we have a single bridge then it is not enough to provide a remapping per bridge, because the feature explicitly allows per-port remapping tables. For frames sent by the VM we could use in_port,dl_vlan filters to provide per-port remapping. But for frames sent to VMs we\u0027d need out_port,dl_vlan filters. But you can\u0027t use out_port since ovs decides it only when you send the frame to action\u003dNORMAL and that must be the last action.\n\nThat\u0027s the point where we need to introduce a new bridge per-port, so on that new bridge you implicitly know the result of the normal action by filtering for in_port\u003dpatch_from_br_int,dl_vlan.\n\n@Miguel: I don\u0027t think we can filter for MAC addresses in the general case. Maybe we could do that with l2pop enabled. But without l2pop can we assume we know all L2 addresses in the network? IMO it\u0027s better if we don\u0027t.","commit_id":"f8dd91771d34fd92912585eea75620d88d811f26"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"e23ca0a4e22099727b4c638f1c6c44477c29e2be","unresolved":false,"context_lines":[{"line_number":317,"context_line":"Alternative 3 - Remap without a bridge pair"},{"line_number":318,"context_line":"+++++++++++++++++++++++++++++++++++++++++++"},{"line_number":319,"context_line":""},{"line_number":320,"context_line":"Given a single bridge and sufficiently complex flow rules it is theoretically"},{"line_number":321,"context_line":"possible to remap between the VM-internal and hypervisor-local domains without"},{"line_number":322,"context_line":"a per-port bridge. Given my limited understanding of what is possible with ovs"},{"line_number":323,"context_line":"this seems to be in conflict with using MAC learning bridges (actions\u003dnormal)."}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a5ae5dd_fe6c3cd1","line":320,"in_reply_to":"5a5ae5dd_ffe53108","updated":"2016-02-08 16:07:51.000000000","message":"Doing this with flows on a single bridge is certainly possible.  As an example, OVN already implements the OVS side of vlan-aware-vms purely with flows on a single bridge.\n\nHowever, you\u0027d have to get rid of using the normal action.  I think that\u0027s going to be a much more complex change than using one of the previous alternatives.  That would be a fairly significant development effort that would then become a pre-requisite before implementing vlan-aware-vms.\n\nTo be honest, if you really want to give up on the way the OVS agent works and move to a flow based solution, I\u0027d encourage you to look at OVN (part of the OVS project), as that\u0027s exactly what it\u0027s doing.","commit_id":"f8dd91771d34fd92912585eea75620d88d811f26"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"6e06425934b82a1233b3087876f2db24506d3241","unresolved":false,"context_lines":[{"line_number":319,"context_line":""},{"line_number":320,"context_line":"Given a single bridge and sufficiently complex flow rules it is theoretically"},{"line_number":321,"context_line":"possible to remap between the VM-internal and hypervisor-local domains without"},{"line_number":322,"context_line":"a per-port bridge. Given my limited understanding of what is possible with ovs"},{"line_number":323,"context_line":"this seems to be in conflict with using MAC learning bridges (actions\u003dnormal)."},{"line_number":324,"context_line":""},{"line_number":325,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a57f1b5_fc427b3d","line":322,"updated":"2016-02-11 13:59:41.000000000","message":"It looks like we\u0027ve got ourselves a sticky wicket when it comes to port security on sub-ports. If sub-ports are an admin-only resource, then ignore me, but if regular tenants use them, they need iptables filtering to prevent DHCP spoofing, MAC spoofing, IP spoofing, and RA spoofing.\n\nWithout a big rewrite of iptables filtering, the linux bridge used for filtering needs to occur after the VLANs are demultiplexed.\n\n\nCurrently, the architecture is this:\n\nVM\u003c-----\u003eLB with iptables\u003c-----\u003ebr-int\n\nIf we want OVS to demultiplex, it would need to be something like this:\n\nVM\u003c-(tagged net1 and net2)---\u003eOVS(some bridge)\u003c-(untagged net1)-\u003eLB with iptables\u003c----\u003ebr-int\n                                            ^-(untagged net2)---\u003eLB with iptables\u003c------^\n\n\n\n\nTo that extent, I\u0027d like to propose one more alternative to consider. Demultiplex the VLANs using Linux bridge. From OVS\u0027s perspective, it will see separate interfaces for each sub-port and treat them just like regular ports. The iptables code will see separate LB bridges and wire them just like normal bridges. The only magic is in wiring up the Linux bridges.\n\nVM\u003c-(tagged net1 and net2)---\u003eLinux bridge\u003c--(\u0027native vlan\u0027 untagged traffic)--\u003ebr-int\n                              ^--\u003eLB for net1-subport\u003c--(VM\u0027s net1 untagged)----^\nveth pair with tag push/pop logic^                    ^veth pair that OVS agent handles like VM","commit_id":"f8dd91771d34fd92912585eea75620d88d811f26"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"ab810fc9435338ffbfc7598c87c0322f3b792d8f","unresolved":false,"context_lines":[{"line_number":319,"context_line":""},{"line_number":320,"context_line":"Given a single bridge and sufficiently complex flow rules it is theoretically"},{"line_number":321,"context_line":"possible to remap between the VM-internal and hypervisor-local domains without"},{"line_number":322,"context_line":"a per-port bridge. Given my limited understanding of what is possible with ovs"},{"line_number":323,"context_line":"this seems to be in conflict with using MAC learning bridges (actions\u003dnormal)."},{"line_number":324,"context_line":""},{"line_number":325,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a57f1b5_fcb03b45","line":322,"updated":"2016-02-11 14:01:10.000000000","message":"here is this comment on paste. gerrit makes it hard to see my diagrams: http://paste.openstack.org/show/486688/","commit_id":"f8dd91771d34fd92912585eea75620d88d811f26"},{"author":{"_account_id":6788,"name":"Rossella Sblendido","email":"rsblendido@suse.com","username":"rossella-o"},"change_message_id":"761c26c8c1f195060d4c1662ebdf36d34a699fa1","unresolved":false,"context_lines":[{"line_number":319,"context_line":""},{"line_number":320,"context_line":"Given a single bridge and sufficiently complex flow rules it is theoretically"},{"line_number":321,"context_line":"possible to remap between the VM-internal and hypervisor-local domains without"},{"line_number":322,"context_line":"a per-port bridge. Given my limited understanding of what is possible with ovs"},{"line_number":323,"context_line":"this seems to be in conflict with using MAC learning bridges (actions\u003dnormal)."},{"line_number":324,"context_line":""},{"line_number":325,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a18252c_aa27d7b4","line":322,"in_reply_to":"3a57f1b5_180d1c90","updated":"2016-04-13 14:24:21.000000000","message":"I like Kevin\u0027s proposal, I\u0027ve updated the patch accordingly","commit_id":"f8dd91771d34fd92912585eea75620d88d811f26"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"93c1e8c2bbed63abfb4ffdbd4e332ea232f637a7","unresolved":false,"context_lines":[{"line_number":319,"context_line":""},{"line_number":320,"context_line":"Given a single bridge and sufficiently complex flow rules it is theoretically"},{"line_number":321,"context_line":"possible to remap between the VM-internal and hypervisor-local domains without"},{"line_number":322,"context_line":"a per-port bridge. Given my limited understanding of what is possible with ovs"},{"line_number":323,"context_line":"this seems to be in conflict with using MAC learning bridges (actions\u003dnormal)."},{"line_number":324,"context_line":""},{"line_number":325,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3a57f1b5_180d1c90","line":322,"in_reply_to":"3a57f1b5_fcb03b45","updated":"2016-02-11 15:55:50.000000000","message":"Interesting proposal, Kevin.  The main downside I see is that for OVS, ideally we\u0027re heading toward getting rid of LB completely.  I think an OVS focused implementation is desirable for use along with the OVS firewall driver.  That will provide *MUCH* better data path performance.\n\nOne option to avoid the added LB complexity you have pointed out is to depend on the OVS firewall driver for this feature.  There are downsides there too though, such as the other thread talking about having to replug vifs on an upgrade.  In an OVS-only env, the interface we need to replug *is* the one libvirt plugged.\n\nTo work without the OVS firewall driver, I see how one of the diagrams you posted is needed.  Your alternative is definitely simpler (eliminates a new bridge), though I imagine the original would share more code with an OVS-only environment.\n\n(I\u0027m not sure I have any conclusions in there ... just thinking out loud)","commit_id":"f8dd91771d34fd92912585eea75620d88d811f26"},{"author":{"_account_id":21273,"name":"Ilya Chukhnakov","email":"Ilya.chukhnakov@gmail.com","username":"ichukhnakov"},"change_message_id":"87128ec04e17ccdc94ccc3563744d4d1f934391c","unresolved":false,"context_lines":[{"line_number":319,"context_line":""},{"line_number":320,"context_line":"Given a single bridge and sufficiently complex flow rules it is theoretically"},{"line_number":321,"context_line":"possible to remap between the VM-internal and hypervisor-local domains without"},{"line_number":322,"context_line":"a per-port bridge. Given my limited understanding of what is possible with ovs"},{"line_number":323,"context_line":"this seems to be in conflict with using MAC learning bridges (actions\u003dnormal)."},{"line_number":324,"context_line":""},{"line_number":325,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a18252c_afb19be3","line":322,"in_reply_to":"5a18252c_aa27d7b4","updated":"2016-04-13 17:48:47.000000000","message":"I\u0027d like to propose another option that I\u0027ve tested recently:\n\nHandle subports exactly the same way as we do with the additional interfaces, except for *one* thing - instead of creating \u0027tap\u0027 device for subport and attaching it to the VM, simply create a vlan device (parent \u0027tap\u0027 is already attached).\n\nE.g. if the parent port is \u0027tap8569d832-df\u0027, then to add a subport \u0027tapaea5a5f6-00\u0027 on vlan 1111 do the following:\n\nip link add link tap8569d832-df name tapaea5a5f6-00 type vlan id 1111\n\nPros: this should require very minimal changes in code/logic and should work for every case that is supported by additional interfaces\n\nCons: this will require more tap/vlan devices then what could be done for OVS Native firewall. But since that code should work for both Native and Hybrid firewall cases and Hybrid requires it anyway, we can optimise the Native case later.","commit_id":"f8dd91771d34fd92912585eea75620d88d811f26"},{"author":{"_account_id":4656,"name":"Sean M. Collins","email":"sean@coreitpro.com","username":"scollins"},"change_message_id":"333cd69cb13ce39e8f76cb572fa3bb36ed405368","unresolved":false,"context_lines":[{"line_number":105,"context_line":"Bridge Management with Trunk Ports"},{"line_number":106,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"In the current implementation there\u0027s a LinuxBridge to which every"},{"line_number":109,"context_line":"VM is connected that is needed to implement security groups (when"},{"line_number":110,"context_line":"OVS Firewall driver is not used). This bridge is also in charge"},{"line_number":111,"context_line":"of remapping the traffic between the VM-internal and hypervisor-local"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a18252c_bed99959","line":108,"updated":"2016-04-14 14:37:11.000000000","message":"Linux bridge device","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":4656,"name":"Sean M. Collins","email":"sean@coreitpro.com","username":"scollins"},"change_message_id":"333cd69cb13ce39e8f76cb572fa3bb36ed405368","unresolved":false,"context_lines":[{"line_number":106,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":107,"context_line":""},{"line_number":108,"context_line":"In the current implementation there\u0027s a LinuxBridge to which every"},{"line_number":109,"context_line":"VM is connected that is needed to implement security groups (when"},{"line_number":110,"context_line":"OVS Firewall driver is not used). This bridge is also in charge"},{"line_number":111,"context_line":"of remapping the traffic between the VM-internal and hypervisor-local"},{"line_number":112,"context_line":"network domains. When a trunk port is created the wiring is the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a18252c_1edb6d50","line":109,"updated":"2016-04-14 14:37:11.000000000","message":"when using the iptables firewall driver","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":8655,"name":"Jakub Libosvar","email":"libosvar@redhat.com","username":"jlibosva"},"change_message_id":"ef6d0053003852b004009cc64f63ab4562a20ada","unresolved":false,"context_lines":[{"line_number":107,"context_line":""},{"line_number":108,"context_line":"In the current implementation there\u0027s a LinuxBridge to which every"},{"line_number":109,"context_line":"VM is connected that is needed to implement security groups (when"},{"line_number":110,"context_line":"OVS Firewall driver is not used). This bridge is also in charge"},{"line_number":111,"context_line":"of remapping the traffic between the VM-internal and hypervisor-local"},{"line_number":112,"context_line":"network domains. When a trunk port is created the wiring is the"},{"line_number":113,"context_line":"same as every other port: the VM interface is plugged into the"},{"line_number":114,"context_line":"LinuxBridge and the LinuxBridge is connected to br-int. When a"},{"line_number":115,"context_line":"subport is associated with the trunk, the OVS agent defines"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a122d0e_344b2a2d","line":112,"range":{"start_line":110,"start_character":34,"end_line":112,"end_character":16},"updated":"2016-05-04 12:48:04.000000000","message":"If you mean local vlan mapping then it\u0027s done on integration bridge, not on linux bridges.","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":4656,"name":"Sean M. Collins","email":"sean@coreitpro.com","username":"scollins"},"change_message_id":"333cd69cb13ce39e8f76cb572fa3bb36ed405368","unresolved":false,"context_lines":[{"line_number":111,"context_line":"of remapping the traffic between the VM-internal and hypervisor-local"},{"line_number":112,"context_line":"network domains. When a trunk port is created the wiring is the"},{"line_number":113,"context_line":"same as every other port: the VM interface is plugged into the"},{"line_number":114,"context_line":"LinuxBridge and the LinuxBridge is connected to br-int. When a"},{"line_number":115,"context_line":"subport is associated with the trunk, the OVS agent defines"},{"line_number":116,"context_line":"a vlan subinterface for the LinuxBridge, whose VLAN correspond"},{"line_number":117,"context_line":"to the VID defined for the subport. This will create a new bridge"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a18252c_fedf9137","line":114,"updated":"2016-04-14 14:37:11.000000000","message":"linux bridge","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":4656,"name":"Sean M. Collins","email":"sean@coreitpro.com","username":"scollins"},"change_message_id":"333cd69cb13ce39e8f76cb572fa3bb36ed405368","unresolved":false,"context_lines":[{"line_number":113,"context_line":"same as every other port: the VM interface is plugged into the"},{"line_number":114,"context_line":"LinuxBridge and the LinuxBridge is connected to br-int. When a"},{"line_number":115,"context_line":"subport is associated with the trunk, the OVS agent defines"},{"line_number":116,"context_line":"a vlan subinterface for the LinuxBridge, whose VLAN correspond"},{"line_number":117,"context_line":"to the VID defined for the subport. This will create a new bridge"},{"line_number":118,"context_line":"LB.vlan1, assuming vlan1 is the one associated with the subport."},{"line_number":119,"context_line":"This bridge is then connected to br-int through a veth pair that"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a18252c_5ee965e5","line":116,"updated":"2016-04-14 14:37:11.000000000","message":"linux bridge","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":21284,"name":"Pavel Gluschak (scsnow)","email":"pglushchak@virtuozzo.com","username":"scsnow"},"change_message_id":"659befc984ad9c6b9624edb9d33e1b755f197de7","unresolved":false,"context_lines":[{"line_number":114,"context_line":"LinuxBridge and the LinuxBridge is connected to br-int. When a"},{"line_number":115,"context_line":"subport is associated with the trunk, the OVS agent defines"},{"line_number":116,"context_line":"a vlan subinterface for the LinuxBridge, whose VLAN correspond"},{"line_number":117,"context_line":"to the VID defined for the subport. This will create a new bridge"},{"line_number":118,"context_line":"LB.vlan1, assuming vlan1 is the one associated with the subport."},{"line_number":119,"context_line":"This bridge is then connected to br-int through a veth pair that"},{"line_number":120,"context_line":"will tag/untag the packets: the traffic coming from the VM will"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a18252c_a91849d4","line":117,"range":{"start_line":117,"start_character":36,"end_line":117,"end_character":65},"updated":"2016-04-14 13:09:29.000000000","message":"Last sentence states, that you add VLAN subinterface for qbr: ip link add link qbr name qbr.100 type vlan id 100. But this won\u0027t create a new bridge. You cannot add veth interfaces into qbr.100. Can you please clarify how it\u0027s supposed to work?","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":21284,"name":"Pavel Gluschak (scsnow)","email":"pglushchak@virtuozzo.com","username":"scsnow"},"change_message_id":"c55a060113e53c33175d10586efc66152357528c","unresolved":false,"context_lines":[{"line_number":114,"context_line":"LinuxBridge and the LinuxBridge is connected to br-int. When a"},{"line_number":115,"context_line":"subport is associated with the trunk, the OVS agent defines"},{"line_number":116,"context_line":"a vlan subinterface for the LinuxBridge, whose VLAN correspond"},{"line_number":117,"context_line":"to the VID defined for the subport. This will create a new bridge"},{"line_number":118,"context_line":"LB.vlan1, assuming vlan1 is the one associated with the subport."},{"line_number":119,"context_line":"This bridge is then connected to br-int through a veth pair that"},{"line_number":120,"context_line":"will tag/untag the packets: the traffic coming from the VM will"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a122d0e_9eae6f96","line":117,"range":{"start_line":117,"start_character":36,"end_line":117,"end_character":65},"in_reply_to":"1a122d0e_7b8a851c","updated":"2016-04-19 16:25:59.000000000","message":"@Ilya\nI suppose, that libvirt wouldn\u0027t be involved here, cause vlan attr is only used in conjunction with ovs network type. Per my understanding proposal with per port br-trunk ovs was refused.\n@Rossella\nI\u0027m also interested in this blueprint. Who is stack holder? Are there any design discussions in IRC or mailing lists? Could you please get me in the loop?","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":21273,"name":"Ilya Chukhnakov","email":"Ilya.chukhnakov@gmail.com","username":"ichukhnakov"},"change_message_id":"90742f5c23176aca2df3a3c8d9d2b75c7e5e9f04","unresolved":false,"context_lines":[{"line_number":114,"context_line":"LinuxBridge and the LinuxBridge is connected to br-int. When a"},{"line_number":115,"context_line":"subport is associated with the trunk, the OVS agent defines"},{"line_number":116,"context_line":"a vlan subinterface for the LinuxBridge, whose VLAN correspond"},{"line_number":117,"context_line":"to the VID defined for the subport. This will create a new bridge"},{"line_number":118,"context_line":"LB.vlan1, assuming vlan1 is the one associated with the subport."},{"line_number":119,"context_line":"This bridge is then connected to br-int through a veth pair that"},{"line_number":120,"context_line":"will tag/untag the packets: the traffic coming from the VM will"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a122d0e_7b8a851c","line":117,"range":{"start_line":117,"start_character":36,"end_line":117,"end_character":65},"in_reply_to":"1a122d0e_d7e0dc98","updated":"2016-04-19 16:13:01.000000000","message":"@Rossella, could you please also clarify what modifications would be required for the \u0027trunk\u0027 port (the one that is managed by Nova/libvirt). Do we use libvirt for that (like this [1]?, would that require changes in Nova)? Do we enable all vlans on trunk port or only those that have corresponding subports?\n\n[1] https://libvirt.org/formatnetwork.html#elementVlanTag","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":6788,"name":"Rossella Sblendido","email":"rsblendido@suse.com","username":"rossella-o"},"change_message_id":"5929c68e93d2c33c11fa06ecd256772e25a14ba6","unresolved":false,"context_lines":[{"line_number":114,"context_line":"LinuxBridge and the LinuxBridge is connected to br-int. When a"},{"line_number":115,"context_line":"subport is associated with the trunk, the OVS agent defines"},{"line_number":116,"context_line":"a vlan subinterface for the LinuxBridge, whose VLAN correspond"},{"line_number":117,"context_line":"to the VID defined for the subport. This will create a new bridge"},{"line_number":118,"context_line":"LB.vlan1, assuming vlan1 is the one associated with the subport."},{"line_number":119,"context_line":"This bridge is then connected to br-int through a veth pair that"},{"line_number":120,"context_line":"will tag/untag the packets: the traffic coming from the VM will"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a122d0e_d7e0dc98","line":117,"range":{"start_line":117,"start_character":36,"end_line":117,"end_character":65},"in_reply_to":"5a18252c_a91849d4","updated":"2016-04-19 14:40:20.000000000","message":"I used:\n\nvconfig add qbr 100\n\nthis will define a sub-interface on qbr. It\u0027s not really a new bridge, it\u0027s a sub-interface of the bridge. It will get all the traffic tagged with the specified vlan that flows through the bridge. i will explain better in next PS","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":16800,"name":"Rawlin Peters","email":"rawlin.peters@hpe.com","username":"rawlin"},"change_message_id":"3fb1ad36a13f9f2c27d87b161b703548e3a4d34b","unresolved":false,"context_lines":[{"line_number":116,"context_line":"a vlan subinterface for the LinuxBridge, whose VLAN correspond"},{"line_number":117,"context_line":"to the VID defined for the subport. This will create a new bridge"},{"line_number":118,"context_line":"LB.vlan1, assuming vlan1 is the one associated with the subport."},{"line_number":119,"context_line":"This bridge is then connected to br-int through a veth pair that"},{"line_number":120,"context_line":"will tag/untag the packets: the traffic coming from the VM will"},{"line_number":121,"context_line":"be tagged using the internal vlan ID corresponding to the network"},{"line_number":122,"context_line":"of the subport, traffic coming from the outside will be tagged"},{"line_number":123,"context_line":"used the vlan ID assigned to the subport."},{"line_number":124,"context_line":""},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"::"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a122d0e_afa76da5","line":123,"range":{"start_line":119,"start_character":40,"end_line":123,"end_character":41},"updated":"2016-04-20 21:11:59.000000000","message":"This part is a bit unclear. The veth pair will tag/untag the packets and not br-int?\n\nIf the VM has the interface eth0.100, traffic on that interface will come out of the tap device with vid 100. That already-tagged traffic will then have its vid modified to the internal vlan ID corresponding to the network of the subport?\n\nOr, does qbr.100 effectively strip the vlan tag before it is sent out on the qvb interface?\n\nAlso, I don\u0027t think the current qbr naming scheme will support adding vlan interfaces to it like so (qbr94c90168-b5.100):\n\n$ sudo ip link add link qbr94c90168-b5 name qbr94c90168-b5.100 type vlan id 100\nError: argument \"qbr94c90168-b5.100\" is wrong: \"name\" too long\n\nIt only supports one more character added to the name \u0027qbr94c90168-b5\u0027.\n\nUsing vconfig will create a name like vlan100@qbr94c90168-b5 by default, but if the hypervisor already uses vlan interfaces for physical networks, i.e. vlan100@eth0, then there will be a naming clash. So there needs to be an uncommon naming scheme used for the qbr vlan interfaces.\n\nThe picture below makes it seem like each LB and LB.vlanX has its own veth pair plugged into br-int. Is that going to be the case?\n\nIs there any way to avoid using the qbr for this purpose? Can\u0027t we just untag/tag the traffic within br-int?","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"c644d5569741088e8d6ddd699991348ea8227905","unresolved":false,"context_lines":[{"line_number":120,"context_line":"will tag/untag the packets: the traffic coming from the VM will"},{"line_number":121,"context_line":"be tagged using the internal vlan ID corresponding to the network"},{"line_number":122,"context_line":"of the subport, traffic coming from the outside will be tagged"},{"line_number":123,"context_line":"used the vlan ID assigned to the subport."},{"line_number":124,"context_line":""},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"::"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a122d0e_d16e8895","line":123,"updated":"2016-04-22 03:52:50.000000000","message":"untagging in br-int is too late. we need to ensure that security groups per sub-port are correctly enforced for each sub-port. So the untagging needs to occur in a manner that allows our iptables rules to distinguish between sub-ports.\n\nWRT to the name issue, we already have code that hashes and truncates when the name gets too long, so that shouldn\u0027t be an issue","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":16800,"name":"Rawlin Peters","email":"rawlin.peters@hpe.com","username":"rawlin"},"change_message_id":"3c1505662ecc54e1646ac3c9c89256556fc6ea07","unresolved":false,"context_lines":[{"line_number":120,"context_line":"will tag/untag the packets: the traffic coming from the VM will"},{"line_number":121,"context_line":"be tagged using the internal vlan ID corresponding to the network"},{"line_number":122,"context_line":"of the subport, traffic coming from the outside will be tagged"},{"line_number":123,"context_line":"used the vlan ID assigned to the subport."},{"line_number":124,"context_line":""},{"line_number":125,"context_line":""},{"line_number":126,"context_line":"::"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a122d0e_93498ad3","line":123,"in_reply_to":"1a122d0e_d16e8895","updated":"2016-04-22 23:43:58.000000000","message":"Ok, thanks for clearing that up. I thought it had something to do with applying the secgroup rules.","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":14605,"name":"vikram.choudhary","email":"vikschw@gmail.com","username":"vikram.choudhary"},"change_message_id":"07179881cea8cf059710a34131faecaf70e7d8a0","unresolved":false,"context_lines":[{"line_number":140,"context_line":"           |               |              |"},{"line_number":141,"context_line":"     +-----+---------------+--------------+----+"},{"line_number":142,"context_line":"     |                                         |"},{"line_number":143,"context_line":"     |                 int                     |"},{"line_number":144,"context_line":"     |                                         |"},{"line_number":145,"context_line":"     +---+---------------------------------+---+"},{"line_number":146,"context_line":"         |                                 |"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a122d0e_a6764b3c","line":143,"updated":"2016-04-15 14:19:11.000000000","message":"I believe you mean br-int here.","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"49377bf1e6d45715086a9e83f0167c12591d9b88","unresolved":false,"context_lines":[{"line_number":152,"context_line":"     +-------+                         +-------+"},{"line_number":153,"context_line":""},{"line_number":154,"context_line":""},{"line_number":155,"context_line":"Upgrade should be no concern, since old ports will keep working the same"},{"line_number":156,"context_line":"way as before."},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"Future Work"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a122d0e_9cbd006b","line":155,"updated":"2016-04-19 00:49:29.000000000","message":"so if I look at:\n\nhttps://review.openstack.org/#/c/273954/2..3/doc/source/devref/openvswitch_agent.rst\n\nI gather you\u0027re going for formerly known as option [1]?","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":6788,"name":"Rossella Sblendido","email":"rsblendido@suse.com","username":"rossella-o"},"change_message_id":"5929c68e93d2c33c11fa06ecd256772e25a14ba6","unresolved":false,"context_lines":[{"line_number":152,"context_line":"     +-------+                         +-------+"},{"line_number":153,"context_line":""},{"line_number":154,"context_line":""},{"line_number":155,"context_line":"Upgrade should be no concern, since old ports will keep working the same"},{"line_number":156,"context_line":"way as before."},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"Future Work"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a122d0e_ac4d1740","line":155,"in_reply_to":"1a122d0e_9cbd006b","updated":"2016-04-19 14:40:20.000000000","message":"it\u0027s not option [1], there\u0027s no exact correspondence in the last PS. What I mean here is that for \"old\" ports the linux bridge won\u0027t be modified, no vlan subinterface will be added. I will clarify in the next PS. I can\u0027t imagine anything that would prevent upgrade from working but this should be tested.","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"9be9ebab88f750e1a9f3275562e90634d836cb41","unresolved":false,"context_lines":[{"line_number":159,"context_line":"+++++++++++"},{"line_number":160,"context_line":""},{"line_number":161,"context_line":"The OVS Firewall driver removed the need of a Linuxbridge to implement"},{"line_number":162,"context_line":"security group. The LinuxBridge is still needed for this feature but we"},{"line_number":163,"context_line":"plan to provide a pure OVS implementation in the future, where the traffic"},{"line_number":164,"context_line":"will be tagged and untagged by an OVS bridge. The type of bridge will be"},{"line_number":165,"context_line":"configurable. Using OVS Firewall driver and OVS bridge for trunk ports"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a18252c_d8cf7a7d","line":162,"range":{"start_line":162,"start_character":16,"end_line":162,"end_character":64},"updated":"2016-04-13 20:30:59.000000000","message":"Does this mean that this feature is incompatible with the native OVS driver for security groups?  I hope not.  If not, will we have tests that test this configuration (i.e. SG in OVS but VLAN tagging outside of OVS)?\n\nI also hope that we can get tagging in OVS sooner than later.","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"c644d5569741088e8d6ddd699991348ea8227905","unresolved":false,"context_lines":[{"line_number":159,"context_line":"+++++++++++"},{"line_number":160,"context_line":""},{"line_number":161,"context_line":"The OVS Firewall driver removed the need of a Linuxbridge to implement"},{"line_number":162,"context_line":"security group. The LinuxBridge is still needed for this feature but we"},{"line_number":163,"context_line":"plan to provide a pure OVS implementation in the future, where the traffic"},{"line_number":164,"context_line":"will be tagged and untagged by an OVS bridge. The type of bridge will be"},{"line_number":165,"context_line":"configurable. Using OVS Firewall driver and OVS bridge for trunk ports"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a122d0e_316c1c9c","line":162,"updated":"2016-04-22 03:52:50.000000000","message":"If we can use the vlan-type devices as @Ilya suggests, that will make the implementation the same for OVS native firewall driver and the iptables driver because from the perspective of each it just looks like a completely independent tap interface that can be handled just like a normal port.","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":8655,"name":"Jakub Libosvar","email":"libosvar@redhat.com","username":"jlibosva"},"change_message_id":"ef6d0053003852b004009cc64f63ab4562a20ada","unresolved":false,"context_lines":[{"line_number":159,"context_line":"+++++++++++"},{"line_number":160,"context_line":""},{"line_number":161,"context_line":"The OVS Firewall driver removed the need of a Linuxbridge to implement"},{"line_number":162,"context_line":"security group. The LinuxBridge is still needed for this feature but we"},{"line_number":163,"context_line":"plan to provide a pure OVS implementation in the future, where the traffic"},{"line_number":164,"context_line":"will be tagged and untagged by an OVS bridge. The type of bridge will be"},{"line_number":165,"context_line":"configurable. Using OVS Firewall driver and OVS bridge for trunk ports"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a122d0e_8b877c11","line":162,"in_reply_to":"1a122d0e_316c1c9c","updated":"2016-05-04 12:48:04.000000000","message":"I\u0027d just state here that ovs firewall works with qbr in between br-int and instance\u0027s tap. So theoretically this approach should work.\n\n@Ilya: Hopefully the work could go to os-vif library.","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":21273,"name":"Ilya Chukhnakov","email":"Ilya.chukhnakov@gmail.com","username":"ichukhnakov"},"change_message_id":"eab0dc2885b47739d5cd67fda88c8868b722975b","unresolved":false,"context_lines":[{"line_number":159,"context_line":"+++++++++++"},{"line_number":160,"context_line":""},{"line_number":161,"context_line":"The OVS Firewall driver removed the need of a Linuxbridge to implement"},{"line_number":162,"context_line":"security group. The LinuxBridge is still needed for this feature but we"},{"line_number":163,"context_line":"plan to provide a pure OVS implementation in the future, where the traffic"},{"line_number":164,"context_line":"will be tagged and untagged by an OVS bridge. The type of bridge will be"},{"line_number":165,"context_line":"configurable. Using OVS Firewall driver and OVS bridge for trunk ports"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a122d0e_8b49818e","line":162,"range":{"start_line":162,"start_character":16,"end_line":162,"end_character":64},"in_reply_to":"1a122d0e_3586e3b9","updated":"2016-04-16 01:06:50.000000000","message":"As I see it, implementing vlan@tap in Nova could reuse some already existing code (bridge \u0026 filtering). But as far as I understand it, getting Neutron-specific code merged in Nova could be problematic. So I\u0027m not sure what approach would be preferred.\n\nIf the Linux bridge would be used for the native OVS Firewall case (or if filtering is not used at all?), do we change the vif_type passed to VIF driver from \u0027ovs_bridge\u0027 to something else (\u0027bridge\u0027?)?","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":6788,"name":"Rossella Sblendido","email":"rsblendido@suse.com","username":"rossella-o"},"change_message_id":"5929c68e93d2c33c11fa06ecd256772e25a14ba6","unresolved":false,"context_lines":[{"line_number":159,"context_line":"+++++++++++"},{"line_number":160,"context_line":""},{"line_number":161,"context_line":"The OVS Firewall driver removed the need of a Linuxbridge to implement"},{"line_number":162,"context_line":"security group. The LinuxBridge is still needed for this feature but we"},{"line_number":163,"context_line":"plan to provide a pure OVS implementation in the future, where the traffic"},{"line_number":164,"context_line":"will be tagged and untagged by an OVS bridge. The type of bridge will be"},{"line_number":165,"context_line":"configurable. Using OVS Firewall driver and OVS bridge for trunk ports"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a122d0e_60d5bb1a","line":162,"range":{"start_line":162,"start_character":16,"end_line":162,"end_character":64},"in_reply_to":"1a122d0e_8b49818e","updated":"2016-04-19 14:40:20.000000000","message":"@Pavel Neutron will take care of the subinterfaces","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":16800,"name":"Rawlin Peters","email":"rawlin.peters@hpe.com","username":"rawlin"},"change_message_id":"9210f1e3fd3f122e595fb9640d1051b8240c17d2","unresolved":false,"context_lines":[{"line_number":159,"context_line":"+++++++++++"},{"line_number":160,"context_line":""},{"line_number":161,"context_line":"The OVS Firewall driver removed the need of a Linuxbridge to implement"},{"line_number":162,"context_line":"security group. The LinuxBridge is still needed for this feature but we"},{"line_number":163,"context_line":"plan to provide a pure OVS implementation in the future, where the traffic"},{"line_number":164,"context_line":"will be tagged and untagged by an OVS bridge. The type of bridge will be"},{"line_number":165,"context_line":"configurable. Using OVS Firewall driver and OVS bridge for trunk ports"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a122d0e_4f43396c","line":162,"range":{"start_line":162,"start_character":16,"end_line":162,"end_character":64},"in_reply_to":"3a1531f4_77e7ca40","updated":"2016-04-20 21:15:34.000000000","message":"+1 eliminating the qbr bridge altogether would be best.","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":21284,"name":"Pavel Gluschak (scsnow)","email":"pglushchak@virtuozzo.com","username":"scsnow"},"change_message_id":"e666c2dc8e783317c84ab3ebb621399290127131","unresolved":false,"context_lines":[{"line_number":159,"context_line":"+++++++++++"},{"line_number":160,"context_line":""},{"line_number":161,"context_line":"The OVS Firewall driver removed the need of a Linuxbridge to implement"},{"line_number":162,"context_line":"security group. The LinuxBridge is still needed for this feature but we"},{"line_number":163,"context_line":"plan to provide a pure OVS implementation in the future, where the traffic"},{"line_number":164,"context_line":"will be tagged and untagged by an OVS bridge. The type of bridge will be"},{"line_number":165,"context_line":"configurable. Using OVS Firewall driver and OVS bridge for trunk ports"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a122d0e_3586e3b9","line":162,"range":{"start_line":162,"start_character":16,"end_line":162,"end_character":64},"in_reply_to":"3a1531f4_77e7ca40","updated":"2016-04-15 13:44:56.000000000","message":"Currently linux bridge qbr and veth qvb-qvo is managed by nova vif code. Is it expected to do this in the same way with tap vlan subinterfaces and additional linux bridges required for this approach?","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":21273,"name":"Ilya Chukhnakov","email":"Ilya.chukhnakov@gmail.com","username":"ichukhnakov"},"change_message_id":"71ac1270ef7d321097f5389c7a4a3d1d656ccc4a","unresolved":false,"context_lines":[{"line_number":159,"context_line":"+++++++++++"},{"line_number":160,"context_line":""},{"line_number":161,"context_line":"The OVS Firewall driver removed the need of a Linuxbridge to implement"},{"line_number":162,"context_line":"security group. The LinuxBridge is still needed for this feature but we"},{"line_number":163,"context_line":"plan to provide a pure OVS implementation in the future, where the traffic"},{"line_number":164,"context_line":"will be tagged and untagged by an OVS bridge. The type of bridge will be"},{"line_number":165,"context_line":"configurable. Using OVS Firewall driver and OVS bridge for trunk ports"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3a1531f4_77e7ca40","line":162,"range":{"start_line":162,"start_character":16,"end_line":162,"end_character":64},"in_reply_to":"5a18252c_8238d23e","updated":"2016-04-15 08:52:27.000000000","message":"I suggest that instead of connecting subport Linux bridges to trunk bridge with veth, we use vlan-type devices instead (see http://paste.openstack.org/show/494157/). That way the Linux bridge would not be required when OVS firewall driver is used.","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":6788,"name":"Rossella Sblendido","email":"rsblendido@suse.com","username":"rossella-o"},"change_message_id":"953ad0414a5ab60119e5bd6ca7717b8b2c313f35","unresolved":false,"context_lines":[{"line_number":159,"context_line":"+++++++++++"},{"line_number":160,"context_line":""},{"line_number":161,"context_line":"The OVS Firewall driver removed the need of a Linuxbridge to implement"},{"line_number":162,"context_line":"security group. The LinuxBridge is still needed for this feature but we"},{"line_number":163,"context_line":"plan to provide a pure OVS implementation in the future, where the traffic"},{"line_number":164,"context_line":"will be tagged and untagged by an OVS bridge. The type of bridge will be"},{"line_number":165,"context_line":"configurable. Using OVS Firewall driver and OVS bridge for trunk ports"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5a18252c_8238d23e","line":162,"range":{"start_line":162,"start_character":16,"end_line":162,"end_character":64},"in_reply_to":"5a18252c_d8cf7a7d","updated":"2016-04-14 10:43:21.000000000","message":"It won\u0027t be incompatible with OVS firewall driver even if some code change is probably needed to make them work nicely together. Also the LinuxBridge will still be needed.\nAnother possibility is to go with the pure OVS implementation straight away and have a more complex architecture when OVS firewall driver is not used (1 LB and 1 OVS extra bridge)...not sure what\u0027s best.","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"eaa1475c92ce37c16a5328fce6f62120d54fe636","unresolved":false,"context_lines":[{"line_number":163,"context_line":"plan to provide a pure OVS implementation in the future, where the traffic"},{"line_number":164,"context_line":"will be tagged and untagged by an OVS bridge. The type of bridge will be"},{"line_number":165,"context_line":"configurable. Using OVS Firewall driver and OVS bridge for trunk ports"},{"line_number":166,"context_line":"will ensure better performance."},{"line_number":167,"context_line":""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"Further Reading"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a122d0e_f82da4fe","line":166,"updated":"2016-04-21 01:16:40.000000000","message":"I would like us to consider the possibility of adopting the OVS firewall driver right off the bat, especially if it ultimately it leads to a simplified design. Was this ruled out completely? I see no compelling reason why we\u0027d support both LB and OVS firewall drivers from Newton onwards.\n\nThe question we should ask ourselves is: why would we choose to implement vlan trunking in configurations where the iptables is used only to propose an alternative later on? That might turn out to be an upgrade nightmare. We can\u0027t have it all right now (for instance the ovs firewall doesn\u0027t work with dpdk), and the use of one driver over the other determines the trade-off we have to make. We should capture these here so that any decision we make is well documented.\n\nFinally, I\u0027d like to suggest to explore the possibility of implementing trunk ports without considering the fact that these ports may be already existing, and plugged into VM\u0027s (ie. something that would be happen if you did nova boot first and then neutron trunk create second); in other words we should give ourselves the opportunity to implement the wiring/network isolation for these ports in a way that is not necessarily tied to the \u0027old\u0027 school ovs agent.  If this means less code reuse, so be it, though we\u0027d need to keep in mind what it means as far as nova vif plugging goes.","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"c644d5569741088e8d6ddd699991348ea8227905","unresolved":false,"context_lines":[{"line_number":163,"context_line":"plan to provide a pure OVS implementation in the future, where the traffic"},{"line_number":164,"context_line":"will be tagged and untagged by an OVS bridge. The type of bridge will be"},{"line_number":165,"context_line":"configurable. Using OVS Firewall driver and OVS bridge for trunk ports"},{"line_number":166,"context_line":"will ensure better performance."},{"line_number":167,"context_line":""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"Further Reading"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a122d0e_1169208c","line":166,"updated":"2016-04-22 03:52:50.000000000","message":"If we use the VLAN type interfaces, all of this tight coupling basically goes away since the VLANs are demultiplexed before anything reaches the bridges.\n\nip link add link tap12345678 name sub74123844 type vlan id 1\n\nThis would create the sub-interface with the prefix \u0027sub\u0027 and then we can just treat it completely like an independent port at the point and wire it up to its own Linux bridge in the iptables case, plug it into br-int in the OVS firewall case, and plug it into the network bridge in the Linux Bridge agent case.\n\nIf our implementation depends on the OVS firewall driver, it seems to me like we\u0027ve failed to keep everything logically distinct and it will make things difficult to maintain when we need to change the flow structure/whatever.","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"9dcc4d00234794462194fb317b49c1b758d0c9bf","unresolved":false,"context_lines":[{"line_number":163,"context_line":"plan to provide a pure OVS implementation in the future, where the traffic"},{"line_number":164,"context_line":"will be tagged and untagged by an OVS bridge. The type of bridge will be"},{"line_number":165,"context_line":"configurable. Using OVS Firewall driver and OVS bridge for trunk ports"},{"line_number":166,"context_line":"will ensure better performance."},{"line_number":167,"context_line":""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"Further Reading"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a122d0e_70078e1d","line":166,"in_reply_to":"1a122d0e_1169208c","updated":"2016-04-22 17:33:36.000000000","message":"What I meant is: let\u0027s assume that we can implement this feature in the absence of the bridge used to provide iptables rules. I agree we should keep things logically independent, but you need to know where to plug in order for traffic to flow correctly.","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":6788,"name":"Rossella Sblendido","email":"rsblendido@suse.com","username":"rossella-o"},"change_message_id":"d619972524d22ff17ceb6b2ce643c12b1d355889","unresolved":false,"context_lines":[{"line_number":163,"context_line":"plan to provide a pure OVS implementation in the future, where the traffic"},{"line_number":164,"context_line":"will be tagged and untagged by an OVS bridge. The type of bridge will be"},{"line_number":165,"context_line":"configurable. Using OVS Firewall driver and OVS bridge for trunk ports"},{"line_number":166,"context_line":"will ensure better performance."},{"line_number":167,"context_line":""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"Further Reading"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a122d0e_f39db00b","line":166,"in_reply_to":"1a122d0e_3e8c12d9","updated":"2016-04-21 12:26:47.000000000","message":"I\u0027d like to consider another option that came up brainstorming with Armando. If we assume the following: \n1) OVS firewall is a prerequisite for supporting trunk ports\n2) old ports cannot be converted into trunk ports\n\nWe can have a single OVS bridge per host that handles the traffic for the trunk ports. Trunk ports will be plugged by Nova into this bridge, let\u0027s call it br-trunk. br-trunk will apply firewall rules and will have the flows to mux/demux the traffic. Specifically:\n* inbound packets, the local vlan id is converted into the segmentation id\n* outbound packets the segmentation id is converted into the local vlan id\n\nbr-trunk will be connected to br-int so that after the proper vlan modifications the traffic will flow as usual.\n\nThis way we won\u0027t affect legacy ports since the handling of trunk will be completely separated and we have a model that is simpler. Opinions?","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":8788,"name":"Miguel Angel Ajo","email":"mangelajo@redhat.com","username":"mangelajo"},"change_message_id":"497d11bc4dddce8af2125683871dedd8a4be58a9","unresolved":false,"context_lines":[{"line_number":163,"context_line":"plan to provide a pure OVS implementation in the future, where the traffic"},{"line_number":164,"context_line":"will be tagged and untagged by an OVS bridge. The type of bridge will be"},{"line_number":165,"context_line":"configurable. Using OVS Firewall driver and OVS bridge for trunk ports"},{"line_number":166,"context_line":"will ensure better performance."},{"line_number":167,"context_line":""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"Further Reading"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a122d0e_3623f206","line":166,"in_reply_to":"1a122d0e_56130e5c","updated":"2016-05-05 14:06:56.000000000","message":"This conversation makes me think that we must put effort on properly refactoring the openflow pipeline of our agent before tackling new features in. Otherwise we make things more complicated than they should, and we end up making things right 2 cycles later, but inserting an upgrade path and two different solutions to maintain.\n\nPlease, take me with a grain of salt, I know the trunk port feature has been waiting for a long time, and It\u0027s not my intention to slow it down.","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":16800,"name":"Rawlin Peters","email":"rawlin.peters@hpe.com","username":"rawlin"},"change_message_id":"da58c48e773d9d38a30c71aad75d936a20229cb2","unresolved":false,"context_lines":[{"line_number":163,"context_line":"plan to provide a pure OVS implementation in the future, where the traffic"},{"line_number":164,"context_line":"will be tagged and untagged by an OVS bridge. The type of bridge will be"},{"line_number":165,"context_line":"configurable. Using OVS Firewall driver and OVS bridge for trunk ports"},{"line_number":166,"context_line":"will ensure better performance."},{"line_number":167,"context_line":""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"Further Reading"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a122d0e_f14a0d82","line":166,"in_reply_to":"1a122d0e_70078e1d","updated":"2016-04-27 23:42:22.000000000","message":"I like the idea of using vlan-type devices (i.e. vlan@tap) as subports. The fact that they can be handled essentially as a regular port makes this the most natural solution with the least impact to other functionality IMO.\n\nThe only reason to use an OVS bridge like br-trunk would be to swap the local and internal vlan tags for subports, right? But when using vlan-type devices as subports, the frames coming into br-int would be untagged and can be tagged w/ the internal vlan id like any other port.","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":8655,"name":"Jakub Libosvar","email":"libosvar@redhat.com","username":"jlibosva"},"change_message_id":"ef6d0053003852b004009cc64f63ab4562a20ada","unresolved":false,"context_lines":[{"line_number":163,"context_line":"plan to provide a pure OVS implementation in the future, where the traffic"},{"line_number":164,"context_line":"will be tagged and untagged by an OVS bridge. The type of bridge will be"},{"line_number":165,"context_line":"configurable. Using OVS Firewall driver and OVS bridge for trunk ports"},{"line_number":166,"context_line":"will ensure better performance."},{"line_number":167,"context_line":""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"Further Reading"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a122d0e_4b9f245f","line":166,"in_reply_to":"1a122d0e_8e978fea","updated":"2016-05-04 12:48:04.000000000","message":"+1 to what Armando said.","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"c4481376343c0c9734e2a4c9b9eb6cb10270d7f4","unresolved":false,"context_lines":[{"line_number":163,"context_line":"plan to provide a pure OVS implementation in the future, where the traffic"},{"line_number":164,"context_line":"will be tagged and untagged by an OVS bridge. The type of bridge will be"},{"line_number":165,"context_line":"configurable. Using OVS Firewall driver and OVS bridge for trunk ports"},{"line_number":166,"context_line":"will ensure better performance."},{"line_number":167,"context_line":""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"Further Reading"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a122d0e_a3952a41","line":166,"in_reply_to":"1a122d0e_8e978fea","updated":"2016-05-04 19:14:24.000000000","message":"@Ajo: a full openflow implementation would imply a complete rewrite of the agent, plus an upgrade nightmare. I\u0027d rather consider it the last resort if I can help it. \n\nTo me another sticking point is acceleration in ovs, ie. dpdk, and figure out also which approach can be compatible with dpdk in the long term.\n\nRossella, I, Carl, Bence and Kevin had some exchange of ideas on how to revisit this patch with the intention of finalizing a design proposal. Hopefully we\u0027ll get them shared here once we\u0027re all fully recovered from last week\u0027s trip.","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":8788,"name":"Miguel Angel Ajo","email":"mangelajo@redhat.com","username":"mangelajo"},"change_message_id":"66e235d191bb0cbf1d8e6813a5dbf7194785677b","unresolved":false,"context_lines":[{"line_number":163,"context_line":"plan to provide a pure OVS implementation in the future, where the traffic"},{"line_number":164,"context_line":"will be tagged and untagged by an OVS bridge. The type of bridge will be"},{"line_number":165,"context_line":"configurable. Using OVS Firewall driver and OVS bridge for trunk ports"},{"line_number":166,"context_line":"will ensure better performance."},{"line_number":167,"context_line":""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"Further Reading"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a122d0e_56130e5c","line":166,"in_reply_to":"1a122d0e_a3952a41","updated":"2016-05-05 14:01:22.000000000","message":"@armax, I\u0027ve been thinking about it for quite q few time, and I think I have a reasonable way of modelling our flows in an extensible manner without huge a huge rewrite of the agent, allowing extension interoperability.\n\nGood point about DPDK\n\n@armax, about the upgrade nightmare, can you clarify?, if you mean, moving hybrid-plugs to non hybrid plugs with fw, the latest patch from @kevin would allow us to start ovs_fw hosts, and migrate instances to those hosts, since the deployment could live with the two types (https://review.openstack.org/#/c/311814/ )\n\n\nPlease bear in mind that using linux system interfaces to encapsulate/decapsulate traffic would lead to lower performance, and defeats a bit the purpose of traffic acceleration.","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":8788,"name":"Miguel Angel Ajo","email":"mangelajo@redhat.com","username":"mangelajo"},"change_message_id":"d45588e505c5181308008f0fcf7c4f7f81e879bd","unresolved":false,"context_lines":[{"line_number":163,"context_line":"plan to provide a pure OVS implementation in the future, where the traffic"},{"line_number":164,"context_line":"will be tagged and untagged by an OVS bridge. The type of bridge will be"},{"line_number":165,"context_line":"configurable. Using OVS Firewall driver and OVS bridge for trunk ports"},{"line_number":166,"context_line":"will ensure better performance."},{"line_number":167,"context_line":""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"Further Reading"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a122d0e_8e978fea","line":166,"in_reply_to":"1a122d0e_bbde100e","updated":"2016-05-04 11:29:44.000000000","message":"+1 to doing a full-openflow implementation. This is related to the design I\u0027m proposing here:\n\nhttps://bugs.launchpad.net/neutron/+bug/1577791\n\nWe could even come to the point were we infer logical ports out of physical openflow ports, by extending the in_port into a register, where the last portion of bits is reserved for the sub-port (we decapsulate the vlan tag, and add the subport part), and therefore the firewall is able to act per sub-port.","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":21284,"name":"Pavel Gluschak (scsnow)","email":"pglushchak@virtuozzo.com","username":"scsnow"},"change_message_id":"ccc7d4941a8271ef500773916e2379fd13f0ef33","unresolved":false,"context_lines":[{"line_number":163,"context_line":"plan to provide a pure OVS implementation in the future, where the traffic"},{"line_number":164,"context_line":"will be tagged and untagged by an OVS bridge. The type of bridge will be"},{"line_number":165,"context_line":"configurable. Using OVS Firewall driver and OVS bridge for trunk ports"},{"line_number":166,"context_line":"will ensure better performance."},{"line_number":167,"context_line":""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"Further Reading"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a122d0e_3e8c12d9","line":166,"in_reply_to":"1a122d0e_c0d5411c","updated":"2016-04-21 10:51:29.000000000","message":"(D) I was thinking about the same as (A) but having a single patch between br-trunk and br-int. In this case br-trunk should be responsible for converting subport vid into internal per-network br-int vid.","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":21284,"name":"Pavel Gluschak (scsnow)","email":"pglushchak@virtuozzo.com","username":"scsnow"},"change_message_id":"39cebf3218a8a16d0808547b74ea4ad44f1b44bd","unresolved":false,"context_lines":[{"line_number":163,"context_line":"plan to provide a pure OVS implementation in the future, where the traffic"},{"line_number":164,"context_line":"will be tagged and untagged by an OVS bridge. The type of bridge will be"},{"line_number":165,"context_line":"configurable. Using OVS Firewall driver and OVS bridge for trunk ports"},{"line_number":166,"context_line":"will ensure better performance."},{"line_number":167,"context_line":""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"Further Reading"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a122d0e_bbde100e","line":166,"in_reply_to":"1a122d0e_f14a0d82","updated":"2016-05-04 09:15:20.000000000","message":"tap interfaces are created by libvirt when instance starts. So as soon as tap interface does not exist we cannot add vlan interfaces. Is it feasible from neutron side to handle subinterfaces when instance is already started?","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":21273,"name":"Ilya Chukhnakov","email":"Ilya.chukhnakov@gmail.com","username":"ichukhnakov"},"change_message_id":"2137ed50b782ec8ad2c254673e63c8f1eed5a088","unresolved":false,"context_lines":[{"line_number":163,"context_line":"plan to provide a pure OVS implementation in the future, where the traffic"},{"line_number":164,"context_line":"will be tagged and untagged by an OVS bridge. The type of bridge will be"},{"line_number":165,"context_line":"configurable. Using OVS Firewall driver and OVS bridge for trunk ports"},{"line_number":166,"context_line":"will ensure better performance."},{"line_number":167,"context_line":""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"Further Reading"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a122d0e_27c0827c","line":166,"in_reply_to":"1a122d0e_f39db00b","updated":"2016-04-21 13:12:39.000000000","message":"Could you please provide a sample flow to show how remapping local-vlan and segmentation-id would work for packets coming from/to VM?\n\nHow would packets be tagged inside br-trunk, would br-trunk use the same local vlan id as br-int does?","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":16800,"name":"Rawlin Peters","email":"rawlin.peters@hpe.com","username":"rawlin"},"change_message_id":"6df8e0029fc7ade2ae8e55b9735daa5000e66f7d","unresolved":false,"context_lines":[{"line_number":163,"context_line":"plan to provide a pure OVS implementation in the future, where the traffic"},{"line_number":164,"context_line":"will be tagged and untagged by an OVS bridge. The type of bridge will be"},{"line_number":165,"context_line":"configurable. Using OVS Firewall driver and OVS bridge for trunk ports"},{"line_number":166,"context_line":"will ensure better performance."},{"line_number":167,"context_line":""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"Further Reading"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a122d0e_596e3197","line":166,"in_reply_to":"1a122d0e_f39db00b","updated":"2016-04-21 17:23:30.000000000","message":"In this case, would a subport not actually have a vif, be it a vlan subinterface or not? So when adding a subport to a trunk, only flows in br-trunk are added/modified?\n\nIs the reason we can\u0027t re-use br-int to mux/demux the tagged traffic from the VM because of the OVS firewall driver?\n\nShould we be worried that there may be tradeoff between bandwidth/latency and being able to reduce the # of vifs in a guest/host? I.e. if adding another bridge into the datapath (br-trunk) is less performant (bw/latency) than not using trunks/subports, would that cause operators to forgo using this new feature?","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":21273,"name":"Ilya Chukhnakov","email":"Ilya.chukhnakov@gmail.com","username":"ichukhnakov"},"change_message_id":"802c7cb22a3f4a39ae13979c03dad7dbdc5ddef4","unresolved":false,"context_lines":[{"line_number":163,"context_line":"plan to provide a pure OVS implementation in the future, where the traffic"},{"line_number":164,"context_line":"will be tagged and untagged by an OVS bridge. The type of bridge will be"},{"line_number":165,"context_line":"configurable. Using OVS Firewall driver and OVS bridge for trunk ports"},{"line_number":166,"context_line":"will ensure better performance."},{"line_number":167,"context_line":""},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"Further Reading"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1a122d0e_c0d5411c","line":166,"in_reply_to":"1a122d0e_f82da4fe","updated":"2016-04-21 10:08:39.000000000","message":"+1 on that.\n\nAs far as I understand, we have the following options for the implementation in that case:\n\n(A) Per-trunk OVS bridge with per-vlan veth-pair to connect it to br-int. This is what the blueprint suggests AFAIK.\n\n(B) Single trunk port with complex OpenFlow rules to remap vlans between local and in-vm vlans. Can someone confirm this is technically possible? Would it not require egress table support in OVS [1]? This would probably be the best choice, if possible.\n\n(C) vlan@tap, i.e. as soon as the trunk port is plugged into br-int, l2 agent creates subports (as vlan-type devices) and plugs them into br-int (after that they would be handled similar to regular ports). This would also support converting an already online port to trunk (and hotplugging ofc).\n\n(D) any other suggestions?\n\n[1] http://openvswitch.org/support/dist-docs/OPENFLOW-1.1+.md.html","commit_id":"a7de28adf8e780f5a022dc1f1df38a0da965478a"},{"author":{"_account_id":16800,"name":"Rawlin Peters","email":"rawlin.peters@hpe.com","username":"rawlin"},"change_message_id":"c19354e3e983108fc0f075525329234737428feb","unresolved":false,"context_lines":[{"line_number":140,"context_line":"  latter is about making the platform use the vlan tag associated"},{"line_number":141,"context_line":"  to packet to determine where the packet needs to go. Ideally,"},{"line_number":142,"context_line":"  a design choice to satisfy the awareness use case will not have"},{"line_number":143,"context_line":"  a negative impact for solving the transparency use case."},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"It is clear by now that an acceptable solution will have to be"},{"line_number":146,"context_line":"assessed with these issues in mind. The potential solutions worth"}],"source_content_type":"text/x-rst","patch_set":5,"id":"dab17558_6cfed26c","line":143,"updated":"2016-05-06 18:06:11.000000000","message":"Just to be clear, is the general consensus that vlan-awareness and vlan-transparency are mutually-exclusive features? Can we demux vlan-tagged traffic from the VM to direct it to a particular neutron network, while being vlan-transparent at the same time?","commit_id":"cba8e4046be95cf33f54de4636217492afec1514"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"eab990f7d5fc5b3798e156c2ee6c2a92a2191642","unresolved":false,"context_lines":[{"line_number":140,"context_line":"  latter is about making the platform use the vlan tag associated"},{"line_number":141,"context_line":"  to packet to determine where the packet needs to go. Ideally,"},{"line_number":142,"context_line":"  a design choice to satisfy the awareness use case will not have"},{"line_number":143,"context_line":"  a negative impact for solving the transparency use case."},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"It is clear by now that an acceptable solution will have to be"},{"line_number":146,"context_line":"assessed with these issues in mind. The potential solutions worth"}],"source_content_type":"text/x-rst","patch_set":5,"id":"dab17558_e5e2d59e","line":143,"in_reply_to":"dab17558_6cfed26c","updated":"2016-05-06 18:32:25.000000000","message":"Yes, that\u0027s outlined in both specs iirc: in other words you can\u0027t have a trunk whose ports are sitting on a transparent network, if that\u0027s what you\u0027re implying.","commit_id":"cba8e4046be95cf33f54de4636217492afec1514"},{"author":{"_account_id":16800,"name":"Rawlin Peters","email":"rawlin.peters@hpe.com","username":"rawlin"},"change_message_id":"9a6afc49344608699caeab5c57302cd070d5ea8b","unresolved":false,"context_lines":[{"line_number":140,"context_line":"  latter is about making the platform use the vlan tag associated"},{"line_number":141,"context_line":"  to packet to determine where the packet needs to go. Ideally,"},{"line_number":142,"context_line":"  a design choice to satisfy the awareness use case will not have"},{"line_number":143,"context_line":"  a negative impact for solving the transparency use case."},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"It is clear by now that an acceptable solution will have to be"},{"line_number":146,"context_line":"assessed with these issues in mind. The potential solutions worth"}],"source_content_type":"text/x-rst","patch_set":5,"id":"dab17558_fb49d6d1","line":143,"in_reply_to":"dab17558_e5e2d59e","updated":"2016-05-06 19:39:45.000000000","message":"Yes, that is what I was implying. I took another look at the vlan-aware-vms spec:\n\n\u003e Until OVS supports QinQ, an OVS based Neutron backend cannot support having a subport attached to a “vlan_transparent” network. That would require the abilty to transport VLAN tagged traffic over the VLAN tagged subport interface (nested VLANs), which is not yet possible.\n\nThis kind of makes it sound like vlan-transparency could be supported once QinQ is supported in OVS, but I\u0027m not sure how that would actually play out inside the guest VM...I guess they would have to have nested vlan interfaces? Then neutron would just have to demux the outer vlan and pass along the inner-vlan as-is, which I suppose is a possibility for OVS given QinQ support.","commit_id":"cba8e4046be95cf33f54de4636217492afec1514"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"89fbafc8bef58ca84ddafb218a4a6f0e691df47a","unresolved":false,"context_lines":[{"line_number":150,"context_line":"  demux the traffix before it hits the integration bridge where"},{"line_number":151,"context_line":"  the traffic will get isolated and sent off to the right"},{"line_number":152,"context_line":"  destination. This solution is `proven \u003chttps://etherpad.openstack.org/p/vlan@tap_experiment\u003e`_"},{"line_number":153,"context_line":"  to work (credit to Rawlin Peters) and has the following design"},{"line_number":154,"context_line":"  implications:"},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"  * Design complexity: this requires relative small changes"}],"source_content_type":"text/x-rst","patch_set":5,"id":"dab17558_cf26c767","line":153,"updated":"2016-05-06 21:36:08.000000000","message":"I should add `proven to work for the iptables firewall`, we should still verify how these behave in presence of the native firewall.","commit_id":"cba8e4046be95cf33f54de4636217492afec1514"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"3c39e949df932da4d3fef61ee2e912c2b312a8e8","unresolved":false,"context_lines":[{"line_number":225,"context_line":""},{"line_number":226,"context_line":"#TODO(armax): rephrase the next paragraphs based on this rationale."},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"Bridge Management with Trunk Ports"},{"line_number":229,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":230,"context_line":""},{"line_number":231,"context_line":"In the current implementation there\u0027s a LinuxBridge to which every"}],"source_content_type":"text/x-rst","patch_set":5,"id":"dab17558_1cbae6e1","line":228,"range":{"start_line":228,"start_character":0,"end_line":228,"end_character":34},"updated":"2016-05-06 12:13:07.000000000","message":"This section is now out of sync with the previous parts.","commit_id":"cba8e4046be95cf33f54de4636217492afec1514"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"5685c92a96fc6352872b1c3d319f7d382c560dc9","unresolved":false,"context_lines":[{"line_number":225,"context_line":""},{"line_number":226,"context_line":"#TODO(armax): rephrase the next paragraphs based on this rationale."},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"Bridge Management with Trunk Ports"},{"line_number":229,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":230,"context_line":""},{"line_number":231,"context_line":"In the current implementation there\u0027s a LinuxBridge to which every"}],"source_content_type":"text/x-rst","patch_set":5,"id":"dab17558_5c2c654a","line":228,"range":{"start_line":228,"start_character":0,"end_line":228,"end_character":34},"in_reply_to":"dab17558_1cbae6e1","updated":"2016-05-06 15:31:29.000000000","message":"hence the todo on line 226","commit_id":"cba8e4046be95cf33f54de4636217492afec1514"},{"author":{"_account_id":8788,"name":"Miguel Angel Ajo","email":"mangelajo@redhat.com","username":"mangelajo"},"change_message_id":"69b95d9ccb99ab98bf7d6828a9c008500b505c29","unresolved":false,"context_lines":[{"line_number":131,"context_line":"  supports: Open vSwitch and Linux Bridge."},{"line_number":132,"context_line":"* Performance penalty: no solution is appealing enough if"},{"line_number":133,"context_line":"  it is unable to satisfy the stringent requirement of high"},{"line_number":134,"context_line":"  packat throughput, at least in the long term."},{"line_number":135,"context_line":"* Feature compatibility: VLAN `transparency \u003chttp://specs.openstack.org/openstack/neutron-specs/specs/kilo/nfv-vlan-trunks.html\u003e`_"},{"line_number":136,"context_line":"  is for better or for worse intertwined with vlan awareness."},{"line_number":137,"context_line":"  The former is about making the platform not interfere with the"}],"source_content_type":"text/x-rst","patch_set":6,"id":"dab17558_d13e4ed9","line":134,"range":{"start_line":134,"start_character":2,"end_line":134,"end_character":8},"updated":"2016-05-09 09:42:30.000000000","message":"packet","commit_id":"bfc005499bd5bddc8cbc2c61ce20c7195089388d"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"61dfe265a974b9b64bf80ee1497640765f90867b","unresolved":false,"context_lines":[{"line_number":131,"context_line":"  supports: Open vSwitch and Linux Bridge."},{"line_number":132,"context_line":"* Performance penalty: no solution is appealing enough if"},{"line_number":133,"context_line":"  it is unable to satisfy the stringent requirement of high"},{"line_number":134,"context_line":"  packat throughput, at least in the long term."},{"line_number":135,"context_line":"* Feature compatibility: VLAN `transparency \u003chttp://specs.openstack.org/openstack/neutron-specs/specs/kilo/nfv-vlan-trunks.html\u003e`_"},{"line_number":136,"context_line":"  is for better or for worse intertwined with vlan awareness."},{"line_number":137,"context_line":"  The former is about making the platform not interfere with the"}],"source_content_type":"text/x-rst","patch_set":6,"id":"dab17558_324b3789","line":134,"range":{"start_line":134,"start_character":2,"end_line":134,"end_character":8},"in_reply_to":"dab17558_d13e4ed9","updated":"2016-05-10 01:39:56.000000000","message":"Done","commit_id":"bfc005499bd5bddc8cbc2c61ce20c7195089388d"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"c0b248523f66bf97140a8f27aca46af6cb6a42be","unresolved":false,"context_lines":[{"line_number":142,"context_line":"  a design choice to satisfy the awareness use case will not have"},{"line_number":143,"context_line":"  a negative impact for solving the transparency use case. Having"},{"line_number":144,"context_line":"  said that, the two features are still meant to be mutually"},{"line_number":145,"context_line":"  exclusive in their application, in that we would be unable to"},{"line_number":146,"context_line":"  plug subports into networks whose vlan-transparency flag is"},{"line_number":147,"context_line":"  set to True."},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"It is clear by now that an acceptable solution will have to be"},{"line_number":150,"context_line":"assessed with these issues in mind. The potential solutions worth"}],"source_content_type":"text/x-rst","patch_set":6,"id":"dab17558_71382fa1","line":147,"range":{"start_line":145,"start_character":42,"end_line":147,"end_character":14},"updated":"2016-05-09 16:43:09.000000000","message":"I don\u0027t think this is true as written but I think I know what you mean.\n\nI would expect to be able to plug a subport in to a network marked transparent *but* I wouldn\u0027t expect my vlan tags to make it to that network.  I would expect that my packets tagged for that network in a vlan aware way would arrive with the vlan tagged removed.\n\nIOW, If I\u0027m using vlan aware with subports I won\u0027t be able to tag packets in a way that the tags reach the vlan transparent network.  They are mutually exclusive in the sense that if my VM is tagging packets, those tags will either all be de-multiplexed in to subports by the vlan aware data path *or* may all be preserved and carried over a vlan transparent network.  There is no way to have some tags targeted at one and other tags targeted at another from the same VM.\n\nI hope that made sense.","commit_id":"bfc005499bd5bddc8cbc2c61ce20c7195089388d"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"61dfe265a974b9b64bf80ee1497640765f90867b","unresolved":false,"context_lines":[{"line_number":142,"context_line":"  a design choice to satisfy the awareness use case will not have"},{"line_number":143,"context_line":"  a negative impact for solving the transparency use case. Having"},{"line_number":144,"context_line":"  said that, the two features are still meant to be mutually"},{"line_number":145,"context_line":"  exclusive in their application, in that we would be unable to"},{"line_number":146,"context_line":"  plug subports into networks whose vlan-transparency flag is"},{"line_number":147,"context_line":"  set to True."},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"It is clear by now that an acceptable solution will have to be"},{"line_number":150,"context_line":"assessed with these issues in mind. The potential solutions worth"}],"source_content_type":"text/x-rst","patch_set":6,"id":"dab17558_121c3376","line":147,"range":{"start_line":145,"start_character":42,"end_line":147,"end_character":14},"in_reply_to":"dab17558_24f4a384","updated":"2016-05-10 01:39:56.000000000","message":"@Rawlin: we can get as technical as we need to be :)","commit_id":"bfc005499bd5bddc8cbc2c61ce20c7195089388d"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"61dfe265a974b9b64bf80ee1497640765f90867b","unresolved":false,"context_lines":[{"line_number":142,"context_line":"  a design choice to satisfy the awareness use case will not have"},{"line_number":143,"context_line":"  a negative impact for solving the transparency use case. Having"},{"line_number":144,"context_line":"  said that, the two features are still meant to be mutually"},{"line_number":145,"context_line":"  exclusive in their application, in that we would be unable to"},{"line_number":146,"context_line":"  plug subports into networks whose vlan-transparency flag is"},{"line_number":147,"context_line":"  set to True."},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"It is clear by now that an acceptable solution will have to be"},{"line_number":150,"context_line":"assessed with these issues in mind. The potential solutions worth"}],"source_content_type":"text/x-rst","patch_set":6,"id":"dab17558_723c9fe2","line":147,"range":{"start_line":145,"start_character":42,"end_line":147,"end_character":14},"in_reply_to":"dab17558_71382fa1","updated":"2016-05-10 01:39:56.000000000","message":"@Carl: what I meant is that because of the known mutual exclusivity we should prevent the plugging to avoid a silent data plane failure.","commit_id":"bfc005499bd5bddc8cbc2c61ce20c7195089388d"},{"author":{"_account_id":16800,"name":"Rawlin Peters","email":"rawlin.peters@hpe.com","username":"rawlin"},"change_message_id":"0a8c7458fb6000e2f8bb69ee0ddd4ef897759439","unresolved":false,"context_lines":[{"line_number":142,"context_line":"  a design choice to satisfy the awareness use case will not have"},{"line_number":143,"context_line":"  a negative impact for solving the transparency use case. Having"},{"line_number":144,"context_line":"  said that, the two features are still meant to be mutually"},{"line_number":145,"context_line":"  exclusive in their application, in that we would be unable to"},{"line_number":146,"context_line":"  plug subports into networks whose vlan-transparency flag is"},{"line_number":147,"context_line":"  set to True."},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"It is clear by now that an acceptable solution will have to be"},{"line_number":150,"context_line":"assessed with these issues in mind. The potential solutions worth"}],"source_content_type":"text/x-rst","patch_set":6,"id":"dab17558_24f4a384","line":147,"range":{"start_line":145,"start_character":42,"end_line":147,"end_character":14},"in_reply_to":"dab17558_71382fa1","updated":"2016-05-09 17:28:03.000000000","message":"At the risk of getting too overly technical here, I think that if QinQ support is added to OVS and the OVS agent is modified to support it as well, we could have the following scenario:\n- guest VM 1 has subport on vlan 123 that is connected to network A (which is considered vlan-transparent). That interface is eth0.123.\n- guest VM creates a nested vlan 456 interface on eth0.123, eth0.123.456 (basically following the steps here: http://www.microhowto.info/howto/configure_an_ethernet_interface_as_a_qinq_vlan_trunk.html)\n- traffic sent to the eth0.123.456 interface hits the tap device on the host and is demuxed to the vlan123@tap interface that is hooked into br-int.\n- br-int sees the vlan 456 tag, and tacks on an outer vlan tag for the local vlan id for network A\n- before leaving br-int, the local vlan tag is removed, leaving only the inner 456 tag.\n- the 456 traffic is destined for VM 2, which isn\u0027t using subports, so VM 2 has an eth0.456 interface (eth0 being a regular port on network A).\n\nSo yes, when sending non-nested vlan traffic, I don\u0027t believe it\u0027s possible to have subports on a vlan-transparent network (because the outermost vlan needs to be demuxed). But if a guest VM is using nested vlan interfaces, I think it should be possible to support vlan-aware-vms with vlan-transparent subports. The outer vlan will be demuxed, but the inner vlan is passed transparently.","commit_id":"bfc005499bd5bddc8cbc2c61ce20c7195089388d"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"c0b248523f66bf97140a8f27aca46af6cb6a42be","unresolved":false,"context_lines":[{"line_number":150,"context_line":"assessed with these issues in mind. The potential solutions worth"},{"line_number":151,"context_line":"enumerating are:"},{"line_number":152,"context_line":""},{"line_number":153,"context_line":"* VLAN interfaces: in layman\u0027s terms, this interfaces allow to"},{"line_number":154,"context_line":"  demux the traffix before it hits the integration bridge where"},{"line_number":155,"context_line":"  the traffic will get isolated and sent off to the right"},{"line_number":156,"context_line":"  destination. This solution is `proven \u003chttps://etherpad.openstack.org/p/vlan@tap_experiment\u003e`_"}],"source_content_type":"text/x-rst","patch_set":6,"id":"dab17558_f14c1f44","line":153,"range":{"start_line":153,"start_character":38,"end_line":153,"end_character":42},"updated":"2016-05-09 16:43:09.000000000","message":"*these","commit_id":"bfc005499bd5bddc8cbc2c61ce20c7195089388d"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"61dfe265a974b9b64bf80ee1497640765f90867b","unresolved":false,"context_lines":[{"line_number":150,"context_line":"assessed with these issues in mind. The potential solutions worth"},{"line_number":151,"context_line":"enumerating are:"},{"line_number":152,"context_line":""},{"line_number":153,"context_line":"* VLAN interfaces: in layman\u0027s terms, this interfaces allow to"},{"line_number":154,"context_line":"  demux the traffix before it hits the integration bridge where"},{"line_number":155,"context_line":"  the traffic will get isolated and sent off to the right"},{"line_number":156,"context_line":"  destination. This solution is `proven \u003chttps://etherpad.openstack.org/p/vlan@tap_experiment\u003e`_"}],"source_content_type":"text/x-rst","patch_set":6,"id":"dab17558_7213ff66","line":153,"range":{"start_line":153,"start_character":38,"end_line":153,"end_character":42},"in_reply_to":"dab17558_f14c1f44","updated":"2016-05-10 01:39:56.000000000","message":"Done","commit_id":"bfc005499bd5bddc8cbc2c61ce20c7195089388d"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"c0b248523f66bf97140a8f27aca46af6cb6a42be","unresolved":false,"context_lines":[{"line_number":156,"context_line":"  destination. This solution is `proven \u003chttps://etherpad.openstack.org/p/vlan@tap_experiment\u003e`_"},{"line_number":157,"context_line":"  to work at least in the case of iptables-based security rules"},{"line_number":158,"context_line":"  (credit to Rawlin Peters), though more validation is required"},{"line_number":159,"context_line":"  for the ovs native case. This solution has the following design"},{"line_number":160,"context_line":"  implications:"},{"line_number":161,"context_line":""},{"line_number":162,"context_line":"  * Design complexity: this requires relative small changes"}],"source_content_type":"text/x-rst","patch_set":6,"id":"dab17558_911033aa","line":159,"range":{"start_line":159,"start_character":10,"end_line":159,"end_character":25},"updated":"2016-05-09 16:43:09.000000000","message":"My feeling is that this will work.  Hopefully Rawlin will prove me correct soon!","commit_id":"bfc005499bd5bddc8cbc2c61ce20c7195089388d"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"c0b248523f66bf97140a8f27aca46af6cb6a42be","unresolved":false,"context_lines":[{"line_number":169,"context_line":"    for both Open vSwitch and Linux Bridge."},{"line_number":170,"context_line":"  * Performance penalty: using VLAN interfaces means that the"},{"line_number":171,"context_line":"    kernel must be involved. For Open vSwitch, being able to use"},{"line_number":172,"context_line":"    a fast path like DPDK is an open issue (`Kernel NIC interfaces \u003chttp://dpdk.org/doc/guides/prog_guide/kernel_nic_interface.html\u003e`_"},{"line_number":173,"context_line":"    might be worth looking into), however, even if DPDK is not"},{"line_number":174,"context_line":"    feasible, it is unclear what the performance gap is between"},{"line_number":175,"context_line":"    a DPDK capable solution and a kernel based solution with the"}],"source_content_type":"text/x-rst","patch_set":6,"id":"dab17558_91395344","line":172,"range":{"start_line":172,"start_character":45,"end_line":172,"end_character":66},"updated":"2016-05-09 16:43:09.000000000","message":"I looked briefly in to these.  The only way I can imagine using a kernel NIC interface in DPDK with vlan interfaces is to use a linux bridge.  Add a DPDK kernel interface and a vlan interface to the bridge so that they can talk. \n\nVlan interfaces are still kernel interfaces.  I don\u0027t see any analog to the vlan interfaces in DPDK user space.  The way to do vlan interfaces in DPDK is to create a flow rule which implies that we\u0027d need to do something more like the OVS native implementation.","commit_id":"bfc005499bd5bddc8cbc2c61ce20c7195089388d"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"61dfe265a974b9b64bf80ee1497640765f90867b","unresolved":false,"context_lines":[{"line_number":169,"context_line":"    for both Open vSwitch and Linux Bridge."},{"line_number":170,"context_line":"  * Performance penalty: using VLAN interfaces means that the"},{"line_number":171,"context_line":"    kernel must be involved. For Open vSwitch, being able to use"},{"line_number":172,"context_line":"    a fast path like DPDK is an open issue (`Kernel NIC interfaces \u003chttp://dpdk.org/doc/guides/prog_guide/kernel_nic_interface.html\u003e`_"},{"line_number":173,"context_line":"    might be worth looking into), however, even if DPDK is not"},{"line_number":174,"context_line":"    feasible, it is unclear what the performance gap is between"},{"line_number":175,"context_line":"    a DPDK capable solution and a kernel based solution with the"}],"source_content_type":"text/x-rst","patch_set":6,"id":"dab17558_9208232f","line":172,"range":{"start_line":172,"start_character":45,"end_line":172,"end_character":66},"in_reply_to":"dab17558_91395344","updated":"2016-05-10 01:39:56.000000000","message":"ack, that\u0027s my understanding too, even if they did help we\u0027d be leaving money on the table.","commit_id":"bfc005499bd5bddc8cbc2c61ce20c7195089388d"},{"author":{"_account_id":8788,"name":"Miguel Angel Ajo","email":"mangelajo@redhat.com","username":"mangelajo"},"change_message_id":"69b95d9ccb99ab98bf7d6828a9c008500b505c29","unresolved":false,"context_lines":[{"line_number":191,"context_line":"    data path - this in turn has bad performance implications;"},{"line_number":192,"context_line":"    b) a dataplane migration is forced during a release upgrade"},{"line_number":193,"context_line":"    and thus it may cause (potentially unrecoverable) dataplane"},{"line_number":194,"context_line":"    disruption."},{"line_number":195,"context_line":"  * Design reusability: a solution for Linux Bridge will still"},{"line_number":196,"context_line":"    be required to avoid widening the gap between Open vSwitch"},{"line_number":197,"context_line":"    (e.g. OVS has DVR but LB does not)."}],"source_content_type":"text/x-rst","patch_set":6,"id":"dab17558_4ceda1ee","line":194,"updated":"2016-05-09 09:42:30.000000000","message":"This could be solved by online migration of instances from an old host to a new host. Anyway, the connection tracking tables are not migrated, and the existing connections would likely be dropped.","commit_id":"bfc005499bd5bddc8cbc2c61ce20c7195089388d"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"61dfe265a974b9b64bf80ee1497640765f90867b","unresolved":false,"context_lines":[{"line_number":191,"context_line":"    data path - this in turn has bad performance implications;"},{"line_number":192,"context_line":"    b) a dataplane migration is forced during a release upgrade"},{"line_number":193,"context_line":"    and thus it may cause (potentially unrecoverable) dataplane"},{"line_number":194,"context_line":"    disruption."},{"line_number":195,"context_line":"  * Design reusability: a solution for Linux Bridge will still"},{"line_number":196,"context_line":"    be required to avoid widening the gap between Open vSwitch"},{"line_number":197,"context_line":"    (e.g. OVS has DVR but LB does not)."}],"source_content_type":"text/x-rst","patch_set":6,"id":"dab17558_75f489f1","line":194,"in_reply_to":"dab17558_4ceda1ee","updated":"2016-05-10 01:39:56.000000000","message":"I wonder if a scenario where the two types of data plane wiring models may exist side by side where new requests are honored with the new model whilst the old system drains out","commit_id":"bfc005499bd5bddc8cbc2c61ce20c7195089388d"},{"author":{"_account_id":8788,"name":"Miguel Angel Ajo","email":"mangelajo@redhat.com","username":"mangelajo"},"change_message_id":"24afa01b9dece93429b8075c784e9832c0c654cd","unresolved":false,"context_lines":[{"line_number":191,"context_line":"    data path - this in turn has bad performance implications;"},{"line_number":192,"context_line":"    b) a dataplane migration is forced during a release upgrade"},{"line_number":193,"context_line":"    and thus it may cause (potentially unrecoverable) dataplane"},{"line_number":194,"context_line":"    disruption."},{"line_number":195,"context_line":"  * Design reusability: a solution for Linux Bridge will still"},{"line_number":196,"context_line":"    be required to avoid widening the gap between Open vSwitch"},{"line_number":197,"context_line":"    (e.g. OVS has DVR but LB does not)."}],"source_content_type":"text/x-rst","patch_set":6,"id":"dab17558_90336df6","line":194,"in_reply_to":"dab17558_75f489f1","updated":"2016-05-12 09:53:13.000000000","message":"If, during a transition period, the newer solution was aware of the old by inspecting the system, installed the new settings, and removed the old bridges and interfaces, that may work.\n\nAlthough I\u0027m not sure how complex it would be, it\u0027s something doable IMO.","commit_id":"bfc005499bd5bddc8cbc2c61ce20c7195089388d"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"3fe64a164cc56d0fcf5c5e3a8a0efc64a88e1494","unresolved":false,"context_lines":[{"line_number":191,"context_line":"    data path - this in turn has bad performance implications;"},{"line_number":192,"context_line":"    b) a dataplane migration is forced during a release upgrade"},{"line_number":193,"context_line":"    and thus it may cause (potentially unrecoverable) dataplane"},{"line_number":194,"context_line":"    disruption."},{"line_number":195,"context_line":"  * Design reusability: a solution for Linux Bridge will still"},{"line_number":196,"context_line":"    be required to avoid widening the gap between Open vSwitch"},{"line_number":197,"context_line":"    (e.g. OVS has DVR but LB does not)."}],"source_content_type":"text/x-rst","patch_set":6,"id":"dab17558_9311a060","line":194,"in_reply_to":"dab17558_90336df6","updated":"2016-05-12 17:10:31.000000000","message":"Everything is doable. How bullet-proof and optimized you make it is the sticking point.","commit_id":"bfc005499bd5bddc8cbc2c61ce20c7195089388d"},{"author":{"_account_id":8788,"name":"Miguel Angel Ajo","email":"mangelajo@redhat.com","username":"mangelajo"},"change_message_id":"69b95d9ccb99ab98bf7d6828a9c008500b505c29","unresolved":false,"context_lines":[{"line_number":197,"context_line":"    (e.g. OVS has DVR but LB does not)."},{"line_number":198,"context_line":"  * Performance penalty: using Open Flow will allow to leverage"},{"line_number":199,"context_line":"    the user space and fast processing given by DPDK, but at"},{"line_number":200,"context_line":"    a non considerable engineering cost nonetheless."},{"line_number":201,"context_line":"  * Feature compatibility: with the adoption of Open Flow, tenant"},{"line_number":202,"context_line":"    isolation will no longer be provided by means of local vlan"},{"line_number":203,"context_line":"    provisioning, thus making the requirement of QinQ support"}],"source_content_type":"text/x-rst","patch_set":6,"id":"dab17558_ccb7d1f3","line":200,"range":{"start_line":200,"start_character":6,"end_line":200,"end_character":9},"updated":"2016-05-09 09:42:30.000000000","message":"non -\u003e \u0027\u0027","commit_id":"bfc005499bd5bddc8cbc2c61ce20c7195089388d"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"61dfe265a974b9b64bf80ee1497640765f90867b","unresolved":false,"context_lines":[{"line_number":197,"context_line":"    (e.g. OVS has DVR but LB does not)."},{"line_number":198,"context_line":"  * Performance penalty: using Open Flow will allow to leverage"},{"line_number":199,"context_line":"    the user space and fast processing given by DPDK, but at"},{"line_number":200,"context_line":"    a non considerable engineering cost nonetheless."},{"line_number":201,"context_line":"  * Feature compatibility: with the adoption of Open Flow, tenant"},{"line_number":202,"context_line":"    isolation will no longer be provided by means of local vlan"},{"line_number":203,"context_line":"    provisioning, thus making the requirement of QinQ support"}],"source_content_type":"text/x-rst","patch_set":6,"id":"dab17558_55f7c5f4","line":200,"range":{"start_line":200,"start_character":6,"end_line":200,"end_character":9},"in_reply_to":"dab17558_ccb7d1f3","updated":"2016-05-10 01:39:56.000000000","message":"Done","commit_id":"bfc005499bd5bddc8cbc2c61ce20c7195089388d"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"c0b248523f66bf97140a8f27aca46af6cb6a42be","unresolved":false,"context_lines":[{"line_number":220,"context_line":"  boundaries of the Neutron community (for both Open vSwitch and Linux"},{"line_number":221,"context_line":"  Bridge) in order to fullfil both vlan awareness and transparency."},{"line_number":222,"context_line":""},{"line_number":223,"context_line":"To start with, option (A) may be pursued, as it is beneficial for"},{"line_number":224,"context_line":"Linux Bridge nonetheless. A working solution will also give the"},{"line_number":225,"context_line":"opportunity to identify the performance penalty compared to an"},{"line_number":226,"context_line":"accelerated fast-path solution. If the performance gap is of"}],"source_content_type":"text/x-rst","patch_set":6,"id":"dab17558_114ba3b1","line":223,"range":{"start_line":223,"start_character":26,"end_line":223,"end_character":40},"updated":"2016-05-09 16:43:09.000000000","message":"My feeling is that we\u0027re doing this one regardless.  Is that correct?","commit_id":"bfc005499bd5bddc8cbc2c61ce20c7195089388d"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"3fe64a164cc56d0fcf5c5e3a8a0efc64a88e1494","unresolved":false,"context_lines":[{"line_number":220,"context_line":"  boundaries of the Neutron community (for both Open vSwitch and Linux"},{"line_number":221,"context_line":"  Bridge) in order to fullfil both vlan awareness and transparency."},{"line_number":222,"context_line":""},{"line_number":223,"context_line":"To start with, option (A) may be pursued, as it is beneficial for"},{"line_number":224,"context_line":"Linux Bridge nonetheless. A working solution will also give the"},{"line_number":225,"context_line":"opportunity to identify the performance penalty compared to an"},{"line_number":226,"context_line":"accelerated fast-path solution. If the performance gap is of"}],"source_content_type":"text/x-rst","patch_set":6,"id":"dab17558_9656ae04","line":223,"range":{"start_line":223,"start_character":26,"end_line":223,"end_character":40},"in_reply_to":"dab17558_114ba3b1","updated":"2016-05-12 17:10:31.000000000","message":"I am reaching this conclusion, in that it can give us a starting point to test the whole solution end to end. I mean, if we can make this work for LB and get OVS for free, why not?\n\nAs for the other two options, I am still on the fence. The idea of two bridges of option (C) makes me cringe a bit (when we know for a fact that other solutions with a simpler design exists).","commit_id":"bfc005499bd5bddc8cbc2c61ce20c7195089388d"},{"author":{"_account_id":8788,"name":"Miguel Angel Ajo","email":"mangelajo@redhat.com","username":"mangelajo"},"change_message_id":"69b95d9ccb99ab98bf7d6828a9c008500b505c29","unresolved":false,"context_lines":[{"line_number":227,"context_line":"many orders of magnitude, and no other optimization is feasible,"},{"line_number":228,"context_line":"then investing in Option (B) becomes necessary and with it, data"},{"line_number":229,"context_line":"plane migration strategies required for solutions that employ"},{"line_number":230,"context_line":"option (A)."},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"#TODO(armax): rephrase the next paragraphs based on this rationale."},{"line_number":233,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"dab17558_6c77c53a","line":230,"updated":"2016-05-09 09:42:30.000000000","message":"The paragraph makes sense. And the migration strategy can be done by combining new hosts based on the OVS solution, with old hosts based on the initial, solution, plus, instance online migration.","commit_id":"bfc005499bd5bddc8cbc2c61ce20c7195089388d"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"61dfe265a974b9b64bf80ee1497640765f90867b","unresolved":false,"context_lines":[{"line_number":227,"context_line":"many orders of magnitude, and no other optimization is feasible,"},{"line_number":228,"context_line":"then investing in Option (B) becomes necessary and with it, data"},{"line_number":229,"context_line":"plane migration strategies required for solutions that employ"},{"line_number":230,"context_line":"option (A)."},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"#TODO(armax): rephrase the next paragraphs based on this rationale."},{"line_number":233,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"dab17558_75cbe9a5","line":230,"in_reply_to":"dab17558_6c77c53a","updated":"2016-05-10 01:39:56.000000000","message":"see above? How crazy would that be if we allowed both to run side by side preventing us from biting the tough bullet of dealing with an online migration?","commit_id":"bfc005499bd5bddc8cbc2c61ce20c7195089388d"},{"author":{"_account_id":8788,"name":"Miguel Angel Ajo","email":"mangelajo@redhat.com","username":"mangelajo"},"change_message_id":"24afa01b9dece93429b8075c784e9832c0c654cd","unresolved":false,"context_lines":[{"line_number":227,"context_line":"many orders of magnitude, and no other optimization is feasible,"},{"line_number":228,"context_line":"then investing in Option (B) becomes necessary and with it, data"},{"line_number":229,"context_line":"plane migration strategies required for solutions that employ"},{"line_number":230,"context_line":"option (A)."},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"#TODO(armax): rephrase the next paragraphs based on this rationale."},{"line_number":233,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"dab17558_70b52930","line":230,"in_reply_to":"dab17558_75cbe9a5","updated":"2016-05-12 09:53:13.000000000","message":"I\u0027m not sure about side-by-side on the same host. \n\nHow would we indicate that one port uses the old solution, and another port uses the new?.\n\nI see possible the migration from (A) \"old\" to (B) or (C) \"new\" as the agent restarts.","commit_id":"bfc005499bd5bddc8cbc2c61ce20c7195089388d"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"d56165b7e7aa3aa2d27cfb0fe701517062c7cb57","unresolved":false,"context_lines":[{"line_number":143,"context_line":"  a negative impact for solving the transparency use case. Having"},{"line_number":144,"context_line":"  said that, the two features are still meant to be mutually"},{"line_number":145,"context_line":"  exclusive in their application, and plugging subports into"},{"line_number":146,"context_line":"  networks whose vlan-transparency flag is set to True should be"},{"line_number":147,"context_line":"  prevented. In fact, it would be impossible from the platform\u0027s"},{"line_number":148,"context_line":"  point of view discerning which tagged packets are meant to be"},{"line_number":149,"context_line":"  treated \u0027transparently\u0027 and which ones are meant to be used"},{"line_number":150,"context_line":"  for demultiplexing (in order to reach the right destination)."}],"source_content_type":"text/x-rst","patch_set":7,"id":"dab17558_d44c1bca","line":147,"range":{"start_line":146,"start_character":55,"end_line":147,"end_character":11},"updated":"2016-05-10 22:18:06.000000000","message":"Continuing discussion from PS6.  I\u0027m not convinced this should be prevented.  Just because a network can carry vlan transparent traffic doesn\u0027t mean that subports, or any other port, shouldn\u0027t be connected to it.  I think that the user just needs to understand that when the traffic gets to that network, it won\u0027t be tagged and so the transparency property of that network is irrelevant.","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"589773fd6a427b5e47c10bc58fbdc850ce3e88be","unresolved":false,"context_lines":[{"line_number":143,"context_line":"  a negative impact for solving the transparency use case. Having"},{"line_number":144,"context_line":"  said that, the two features are still meant to be mutually"},{"line_number":145,"context_line":"  exclusive in their application, and plugging subports into"},{"line_number":146,"context_line":"  networks whose vlan-transparency flag is set to True should be"},{"line_number":147,"context_line":"  prevented. In fact, it would be impossible from the platform\u0027s"},{"line_number":148,"context_line":"  point of view discerning which tagged packets are meant to be"},{"line_number":149,"context_line":"  treated \u0027transparently\u0027 and which ones are meant to be used"},{"line_number":150,"context_line":"  for demultiplexing (in order to reach the right destination)."}],"source_content_type":"text/x-rst","patch_set":7,"id":"bab6814e_1196b83e","line":147,"range":{"start_line":146,"start_character":55,"end_line":147,"end_character":11},"in_reply_to":"bab6814e_0a6ff32b","updated":"2016-05-20 18:55:10.000000000","message":"I honestly think it will take more work to prevent it than to allow it.  Let\u0027s just make sure the docs have a short description of this scenario and what happens and leave it.  Done.","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":16800,"name":"Rawlin Peters","email":"rawlin.peters@hpe.com","username":"rawlin"},"change_message_id":"8b56b3ad8b611f054151a91322b0a9e553ab4221","unresolved":false,"context_lines":[{"line_number":143,"context_line":"  a negative impact for solving the transparency use case. Having"},{"line_number":144,"context_line":"  said that, the two features are still meant to be mutually"},{"line_number":145,"context_line":"  exclusive in their application, and plugging subports into"},{"line_number":146,"context_line":"  networks whose vlan-transparency flag is set to True should be"},{"line_number":147,"context_line":"  prevented. In fact, it would be impossible from the platform\u0027s"},{"line_number":148,"context_line":"  point of view discerning which tagged packets are meant to be"},{"line_number":149,"context_line":"  treated \u0027transparently\u0027 and which ones are meant to be used"},{"line_number":150,"context_line":"  for demultiplexing (in order to reach the right destination)."}],"source_content_type":"text/x-rst","patch_set":7,"id":"bab6814e_d4d6deef","line":147,"range":{"start_line":146,"start_character":55,"end_line":147,"end_character":11},"in_reply_to":"bab6814e_1196b83e","updated":"2016-05-20 19:21:33.000000000","message":"+1","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":15554,"name":"Bence Romsics","email":"bence.romsics@gmail.com","username":"ebenrom","status":"inactive contributor"},"change_message_id":"e22fc4f0b05b1f54698bc9bfaf4f370e5e9089b2","unresolved":false,"context_lines":[{"line_number":143,"context_line":"  a negative impact for solving the transparency use case. Having"},{"line_number":144,"context_line":"  said that, the two features are still meant to be mutually"},{"line_number":145,"context_line":"  exclusive in their application, and plugging subports into"},{"line_number":146,"context_line":"  networks whose vlan-transparency flag is set to True should be"},{"line_number":147,"context_line":"  prevented. In fact, it would be impossible from the platform\u0027s"},{"line_number":148,"context_line":"  point of view discerning which tagged packets are meant to be"},{"line_number":149,"context_line":"  treated \u0027transparently\u0027 and which ones are meant to be used"},{"line_number":150,"context_line":"  for demultiplexing (in order to reach the right destination)."}],"source_content_type":"text/x-rst","patch_set":7,"id":"bab6814e_0a6ff32b","line":147,"range":{"start_line":146,"start_character":55,"end_line":147,"end_character":11},"in_reply_to":"bab6814e_2a077a1d","updated":"2016-05-19 13:44:53.000000000","message":"Another perspective independent of assumed user experiences:\n\nWhat if we first go for Armando\u0027s suggestion of explicitly rejecting plugging subports to vlan transparent networks (but with some net-yet-implemented error)? Then if and when we get user feedback that somebody actually wants to do this (and understands the limitations) that time we allow it.\n\nIf we do it the other way around and enable plugging subports and then turns out nobody needed it, there\u0027s no way of backing out without breaking backwards compatibility.","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"3f1b7d05f833146a183187b2e832961e320c2de8","unresolved":false,"context_lines":[{"line_number":143,"context_line":"  a negative impact for solving the transparency use case. Having"},{"line_number":144,"context_line":"  said that, the two features are still meant to be mutually"},{"line_number":145,"context_line":"  exclusive in their application, and plugging subports into"},{"line_number":146,"context_line":"  networks whose vlan-transparency flag is set to True should be"},{"line_number":147,"context_line":"  prevented. In fact, it would be impossible from the platform\u0027s"},{"line_number":148,"context_line":"  point of view discerning which tagged packets are meant to be"},{"line_number":149,"context_line":"  treated \u0027transparently\u0027 and which ones are meant to be used"},{"line_number":150,"context_line":"  for demultiplexing (in order to reach the right destination)."}],"source_content_type":"text/x-rst","patch_set":7,"id":"bab6814e_2a077a1d","line":147,"range":{"start_line":146,"start_character":55,"end_line":147,"end_character":11},"in_reply_to":"bab6814e_af441c74","updated":"2016-05-18 23:30:38.000000000","message":"@Carl OK, now I think I get what you\u0027re saying (for real this time!). My comment above still stands. What is the better user experience? As I think about it more I tend to agree with what you\u0027re saying. I think I would be more annoyed that the system doesn\u0027t let me attach a subport to a vlan-transparent network. Basically only the untagged VLAN would get plumbed through the subport in that case? I think I can live with that.","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"cdef10649ff4be9a93c9d63fb9f05b0f4a3e7fbb","unresolved":false,"context_lines":[{"line_number":143,"context_line":"  a negative impact for solving the transparency use case. Having"},{"line_number":144,"context_line":"  said that, the two features are still meant to be mutually"},{"line_number":145,"context_line":"  exclusive in their application, and plugging subports into"},{"line_number":146,"context_line":"  networks whose vlan-transparency flag is set to True should be"},{"line_number":147,"context_line":"  prevented. In fact, it would be impossible from the platform\u0027s"},{"line_number":148,"context_line":"  point of view discerning which tagged packets are meant to be"},{"line_number":149,"context_line":"  treated \u0027transparently\u0027 and which ones are meant to be used"},{"line_number":150,"context_line":"  for demultiplexing (in order to reach the right destination)."}],"source_content_type":"text/x-rst","patch_set":7,"id":"dab17558_daee108a","line":147,"range":{"start_line":146,"start_character":55,"end_line":147,"end_character":11},"in_reply_to":"dab17558_0c7e5d69","updated":"2016-05-16 16:41:55.000000000","message":"@Rawlin, I think you\u0027re missing something.  Plugging a subport in to a vlan transparent network *does not* require QinQ.  A subport does not emit tagged traffic!  It is just like any other port that doesn\u0027t emit tagged traffic.  They can be safely plugged in to a vlan transparent network.  The vlan transparency of the network is irrelevant here.  Do you see the point I\u0027m trying to make?\n\nI don\u0027t think anyone has quite shown an understanding of the point I\u0027m trying to make.","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"0640e096458afe99541d93d2f9a0008eb8f6ab17","unresolved":false,"context_lines":[{"line_number":144,"context_line":"  said that, the two features are still meant to be mutually"},{"line_number":145,"context_line":"  exclusive in their application, and plugging subports into"},{"line_number":146,"context_line":"  networks whose vlan-transparency flag is set to True should be"},{"line_number":147,"context_line":"  prevented. In fact, it would be impossible from the platform\u0027s"},{"line_number":148,"context_line":"  point of view discerning which tagged packets are meant to be"},{"line_number":149,"context_line":"  treated \u0027transparently\u0027 and which ones are meant to be used"},{"line_number":150,"context_line":"  for demultiplexing (in order to reach the right destination)."}],"source_content_type":"text/x-rst","patch_set":7,"id":"dab17558_b7095e97","line":147,"in_reply_to":"dab17558_0c7e5d69","updated":"2016-05-11 22:21:49.000000000","message":"That\u0027s worth considering, but then again, I am less concerned about UX here knowing what\u0027s left to read down there :)","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"20d5f68bdc0c45e9d368742aaaaf9bb96d4d363f","unresolved":false,"context_lines":[{"line_number":143,"context_line":"  a negative impact for solving the transparency use case. Having"},{"line_number":144,"context_line":"  said that, the two features are still meant to be mutually"},{"line_number":145,"context_line":"  exclusive in their application, and plugging subports into"},{"line_number":146,"context_line":"  networks whose vlan-transparency flag is set to True should be"},{"line_number":147,"context_line":"  prevented. In fact, it would be impossible from the platform\u0027s"},{"line_number":148,"context_line":"  point of view discerning which tagged packets are meant to be"},{"line_number":149,"context_line":"  treated \u0027transparently\u0027 and which ones are meant to be used"},{"line_number":150,"context_line":"  for demultiplexing (in order to reach the right destination)."}],"source_content_type":"text/x-rst","patch_set":7,"id":"dab17558_f042150e","line":147,"range":{"start_line":146,"start_character":55,"end_line":147,"end_character":11},"in_reply_to":"dab17558_1506ab1b","updated":"2016-05-16 17:09:14.000000000","message":"@Carl The question I would ask is what has a better user experience: blocking users from creating trunk ports on a vlan transparent network altogether, or letting them do it and open the door to misconfiguration that could cause confusion and angst?\n\nI agree that there is no technical reason not to allow this as you\u0027re suggesting. However, let\u0027s frame this point in terms of user experience. I\u0027m not sure I have an answer. On the one hand, I\u0027m someone who views myself as a power user in this space and I don\u0027t like these kinds of restrictions when I\u0027m confident in my ability to work with something. But if I don\u0027t fully understand something, I\u0027d really like the system to not give me enough rope to hang myself. This could go both ways. I tend to think that admins will be power users, but your average tenant using this feature may not be. My perception could be wrong though.","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":16800,"name":"Rawlin Peters","email":"rawlin.peters@hpe.com","username":"rawlin"},"change_message_id":"97300dc91e32f5a6af8acd310643ce66a3798f75","unresolved":false,"context_lines":[{"line_number":143,"context_line":"  a negative impact for solving the transparency use case. Having"},{"line_number":144,"context_line":"  said that, the two features are still meant to be mutually"},{"line_number":145,"context_line":"  exclusive in their application, and plugging subports into"},{"line_number":146,"context_line":"  networks whose vlan-transparency flag is set to True should be"},{"line_number":147,"context_line":"  prevented. In fact, it would be impossible from the platform\u0027s"},{"line_number":148,"context_line":"  point of view discerning which tagged packets are meant to be"},{"line_number":149,"context_line":"  treated \u0027transparently\u0027 and which ones are meant to be used"},{"line_number":150,"context_line":"  for demultiplexing (in order to reach the right destination)."}],"source_content_type":"text/x-rst","patch_set":7,"id":"dab17558_508a01c0","line":147,"range":{"start_line":146,"start_character":55,"end_line":147,"end_character":11},"in_reply_to":"dab17558_1506ab1b","updated":"2016-05-16 17:18:48.000000000","message":"@Carl ok I think I\u0027m getting to your point. Vlan-transparent networks don\u0027t only pass vlan-tagged traffic, but they also pass untagged traffic. Subports, which pass untagged traffic, should not be prohibited on vlan-transparent networks. That would break the user\u0027s expectation. But if a VM wants to use subports and also pass vlan-tagged traffic on those subports to other VMs, that VM will have to configure nested vlan interfaces (i.e. eth0.1.100) such that the outer vlan (1) is demuxed but the inner vlan (100) is passed along transparently.","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"e783a6ffe7756c601b42c8e73cd0f7897bb33af5","unresolved":false,"context_lines":[{"line_number":143,"context_line":"  a negative impact for solving the transparency use case. Having"},{"line_number":144,"context_line":"  said that, the two features are still meant to be mutually"},{"line_number":145,"context_line":"  exclusive in their application, and plugging subports into"},{"line_number":146,"context_line":"  networks whose vlan-transparency flag is set to True should be"},{"line_number":147,"context_line":"  prevented. In fact, it would be impossible from the platform\u0027s"},{"line_number":148,"context_line":"  point of view discerning which tagged packets are meant to be"},{"line_number":149,"context_line":"  treated \u0027transparently\u0027 and which ones are meant to be used"},{"line_number":150,"context_line":"  for demultiplexing (in order to reach the right destination)."}],"source_content_type":"text/x-rst","patch_set":7,"id":"dab17558_c14a6954","line":147,"range":{"start_line":146,"start_character":55,"end_line":147,"end_character":11},"in_reply_to":"dab17558_496fc5fb","updated":"2016-05-11 17:42:36.000000000","message":"My expectation as a user would be that a subport could connect to any network that any other port not carrying tagged traffic could connect to.  This includes vlan transparent networks.  So, you\u0027d be breaking my expectation by preventing it.  But, you\u0027re welcome to collect some more opinions.\n\nI\u0027d even say that if a user expected it to be prevented, the user doesn\u0027t understand what the subport is.","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"02a2e1c9aef231205fc5cf275d59bf2feaa03619","unresolved":false,"context_lines":[{"line_number":143,"context_line":"  a negative impact for solving the transparency use case. Having"},{"line_number":144,"context_line":"  said that, the two features are still meant to be mutually"},{"line_number":145,"context_line":"  exclusive in their application, and plugging subports into"},{"line_number":146,"context_line":"  networks whose vlan-transparency flag is set to True should be"},{"line_number":147,"context_line":"  prevented. In fact, it would be impossible from the platform\u0027s"},{"line_number":148,"context_line":"  point of view discerning which tagged packets are meant to be"},{"line_number":149,"context_line":"  treated \u0027transparently\u0027 and which ones are meant to be used"},{"line_number":150,"context_line":"  for demultiplexing (in order to reach the right destination)."}],"source_content_type":"text/x-rst","patch_set":7,"id":"bab6814e_4a52be14","line":147,"range":{"start_line":146,"start_character":55,"end_line":147,"end_character":11},"in_reply_to":"dab17558_508a01c0","updated":"2016-05-18 23:00:40.000000000","message":"@Rawlin, I think you\u0027ve got it!  I\u0027m not suggesting we allow the nested vlan scenario.  I\u0027m just suggesting we allow the untagged subport to plug in.","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":16800,"name":"Rawlin Peters","email":"rawlin.peters@hpe.com","username":"rawlin"},"change_message_id":"4a6f100d0fdb98f15d9131ca6e4758c4fd3719ef","unresolved":false,"context_lines":[{"line_number":143,"context_line":"  a negative impact for solving the transparency use case. Having"},{"line_number":144,"context_line":"  said that, the two features are still meant to be mutually"},{"line_number":145,"context_line":"  exclusive in their application, and plugging subports into"},{"line_number":146,"context_line":"  networks whose vlan-transparency flag is set to True should be"},{"line_number":147,"context_line":"  prevented. In fact, it would be impossible from the platform\u0027s"},{"line_number":148,"context_line":"  point of view discerning which tagged packets are meant to be"},{"line_number":149,"context_line":"  treated \u0027transparently\u0027 and which ones are meant to be used"},{"line_number":150,"context_line":"  for demultiplexing (in order to reach the right destination)."}],"source_content_type":"text/x-rst","patch_set":7,"id":"dab17558_0c7e5d69","line":147,"range":{"start_line":146,"start_character":55,"end_line":147,"end_character":11},"in_reply_to":"dab17558_c14a6954","updated":"2016-05-11 21:41:15.000000000","message":"Perhaps when a user tries create a subport on a vlan-transparent network, the command should fail with something like \"if you\u0027re sure you want to add a subport on a vlan-transparent network (this requires QinQ in the guest VM), please use --force-vlan-transparent-subport\" ...just an idea.\n\nThat way the user knows that both features could work together, it would just require some extra support in the guest. And they won\u0027t accidentally create a vlan-transparent subport by accident.","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"42cd35828c30064219fc0f410cb08eb29471048d","unresolved":false,"context_lines":[{"line_number":143,"context_line":"  a negative impact for solving the transparency use case. Having"},{"line_number":144,"context_line":"  said that, the two features are still meant to be mutually"},{"line_number":145,"context_line":"  exclusive in their application, and plugging subports into"},{"line_number":146,"context_line":"  networks whose vlan-transparency flag is set to True should be"},{"line_number":147,"context_line":"  prevented. In fact, it would be impossible from the platform\u0027s"},{"line_number":148,"context_line":"  point of view discerning which tagged packets are meant to be"},{"line_number":149,"context_line":"  treated \u0027transparently\u0027 and which ones are meant to be used"},{"line_number":150,"context_line":"  for demultiplexing (in order to reach the right destination)."}],"source_content_type":"text/x-rst","patch_set":7,"id":"dab17558_496fc5fb","line":147,"range":{"start_line":146,"start_character":55,"end_line":147,"end_character":11},"in_reply_to":"dab17558_d44c1bca","updated":"2016-05-11 17:35:48.000000000","message":"I am only concerned that this may lead to poor user experience where user expectations are not met. Either way, this is relatively easy to solve based on field feedback.","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"c907c8ff6084311605b935d1e2bfc2544ea6edb3","unresolved":false,"context_lines":[{"line_number":143,"context_line":"  a negative impact for solving the transparency use case. Having"},{"line_number":144,"context_line":"  said that, the two features are still meant to be mutually"},{"line_number":145,"context_line":"  exclusive in their application, and plugging subports into"},{"line_number":146,"context_line":"  networks whose vlan-transparency flag is set to True should be"},{"line_number":147,"context_line":"  prevented. In fact, it would be impossible from the platform\u0027s"},{"line_number":148,"context_line":"  point of view discerning which tagged packets are meant to be"},{"line_number":149,"context_line":"  treated \u0027transparently\u0027 and which ones are meant to be used"},{"line_number":150,"context_line":"  for demultiplexing (in order to reach the right destination)."}],"source_content_type":"text/x-rst","patch_set":7,"id":"dab17558_1506ab1b","line":147,"range":{"start_line":146,"start_character":55,"end_line":147,"end_character":11},"in_reply_to":"dab17558_daee108a","updated":"2016-05-16 16:45:32.000000000","message":"I should make one adjustment to what I said to be clearer.  The subport doesn\u0027t emit tagged traffic but it also can\u0027t receive tagged traffic.  It can only received untagged traffic.  But, that\u0027s still true for any other regular old VM port that I can plug in to a vlan transparent network where the VM does not correctly received tagged traffic.","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"02a2e1c9aef231205fc5cf275d59bf2feaa03619","unresolved":false,"context_lines":[{"line_number":143,"context_line":"  a negative impact for solving the transparency use case. Having"},{"line_number":144,"context_line":"  said that, the two features are still meant to be mutually"},{"line_number":145,"context_line":"  exclusive in their application, and plugging subports into"},{"line_number":146,"context_line":"  networks whose vlan-transparency flag is set to True should be"},{"line_number":147,"context_line":"  prevented. In fact, it would be impossible from the platform\u0027s"},{"line_number":148,"context_line":"  point of view discerning which tagged packets are meant to be"},{"line_number":149,"context_line":"  treated \u0027transparently\u0027 and which ones are meant to be used"},{"line_number":150,"context_line":"  for demultiplexing (in order to reach the right destination)."}],"source_content_type":"text/x-rst","patch_set":7,"id":"bab6814e_af441c74","line":147,"range":{"start_line":146,"start_character":55,"end_line":147,"end_character":11},"in_reply_to":"dab17558_f042150e","updated":"2016-05-18 23:00:40.000000000","message":"@Ryan  Not trunk ports.  Subports!  I\u0027m on the fence for trunk ports.  I agree that is more confusing.  I probably would lean towards not preventing it.\n\nUsers may not care about the transparent nature of an existing network.  They just want to plug in to it.","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"67ac827c905845a48ea849c996c3c7296627b84f","unresolved":false,"context_lines":[{"line_number":157,"context_line":"enumerating are:"},{"line_number":158,"context_line":""},{"line_number":159,"context_line":"* VLAN interfaces: in layman\u0027s terms, these interfaces allow to"},{"line_number":160,"context_line":"  demux the traffix before it hits the integration bridge where"},{"line_number":161,"context_line":"  the traffic will get isolated and sent off to the right"},{"line_number":162,"context_line":"  destination. This solution is `proven \u003chttps://etherpad.openstack.org/p/vlan@tap_experiment\u003e`_"},{"line_number":163,"context_line":"  to work at least in the case of iptables-based security rules"}],"source_content_type":"text/x-rst","patch_set":7,"id":"dab17558_4b5d2f78","line":160,"range":{"start_line":160,"start_character":12,"end_line":160,"end_character":19},"updated":"2016-05-10 20:07:34.000000000","message":"traffic","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"42cd35828c30064219fc0f410cb08eb29471048d","unresolved":false,"context_lines":[{"line_number":157,"context_line":"enumerating are:"},{"line_number":158,"context_line":""},{"line_number":159,"context_line":"* VLAN interfaces: in layman\u0027s terms, these interfaces allow to"},{"line_number":160,"context_line":"  demux the traffix before it hits the integration bridge where"},{"line_number":161,"context_line":"  the traffic will get isolated and sent off to the right"},{"line_number":162,"context_line":"  destination. This solution is `proven \u003chttps://etherpad.openstack.org/p/vlan@tap_experiment\u003e`_"},{"line_number":163,"context_line":"  to work at least in the case of iptables-based security rules"}],"source_content_type":"text/x-rst","patch_set":7,"id":"dab17558_e980398d","line":160,"range":{"start_line":160,"start_character":12,"end_line":160,"end_character":19},"in_reply_to":"dab17558_4b5d2f78","updated":"2016-05-11 17:35:48.000000000","message":"Done","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"67ac827c905845a48ea849c996c3c7296627b84f","unresolved":false,"context_lines":[{"line_number":175,"context_line":"    for both Open vSwitch and Linux Bridge."},{"line_number":176,"context_line":"  * Performance penalty: using VLAN interfaces means that the"},{"line_number":177,"context_line":"    kernel must be involved. For Open vSwitch, being able to use"},{"line_number":178,"context_line":"    a fast path like DPDK is an open issue (`Kernel NIC interfaces \u003chttp://dpdk.org/doc/guides/prog_guide/kernel_nic_interface.html\u003e`_"},{"line_number":179,"context_line":"    might be worth looking into), however, even if DPDK is not"},{"line_number":180,"context_line":"    feasible, it is unclear what the performance gap is between"},{"line_number":181,"context_line":"    a DPDK capable solution and a kernel based solution with the"},{"line_number":182,"context_line":"    adoption of OVS firewall for security groups."}],"source_content_type":"text/x-rst","patch_set":7,"id":"dab17558_eba86322","line":179,"range":{"start_line":178,"start_character":44,"end_line":179,"end_character":32},"updated":"2016-05-10 20:07:34.000000000","message":"kni is not upstream in any kernel and multiple distros have stated that they will not be compiling it in to there dpdk package.\n\novs also has no support for kni interfaces at present.","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"0640e096458afe99541d93d2f9a0008eb8f6ab17","unresolved":false,"context_lines":[{"line_number":176,"context_line":"  * Performance penalty: using VLAN interfaces means that the"},{"line_number":177,"context_line":"    kernel must be involved. For Open vSwitch, being able to use"},{"line_number":178,"context_line":"    a fast path like DPDK is an open issue (`Kernel NIC interfaces \u003chttp://dpdk.org/doc/guides/prog_guide/kernel_nic_interface.html\u003e`_"},{"line_number":179,"context_line":"    might be worth looking into), however, even if DPDK is not"},{"line_number":180,"context_line":"    feasible, it is unclear what the performance gap is between"},{"line_number":181,"context_line":"    a DPDK capable solution and a kernel based solution with the"},{"line_number":182,"context_line":"    adoption of OVS firewall for security groups."}],"source_content_type":"text/x-rst","patch_set":7,"id":"dab17558_57fbd278","line":179,"in_reply_to":"dab17558_57663bed","updated":"2016-05-11 22:21:49.000000000","message":"excellent feedback, thank you!","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":8788,"name":"Miguel Angel Ajo","email":"mangelajo@redhat.com","username":"mangelajo"},"change_message_id":"3184af2cc00edfd577c967cdee6219c0a2ef55f3","unresolved":false,"context_lines":[{"line_number":176,"context_line":"  * Performance penalty: using VLAN interfaces means that the"},{"line_number":177,"context_line":"    kernel must be involved. For Open vSwitch, being able to use"},{"line_number":178,"context_line":"    a fast path like DPDK is an open issue (`Kernel NIC interfaces \u003chttp://dpdk.org/doc/guides/prog_guide/kernel_nic_interface.html\u003e`_"},{"line_number":179,"context_line":"    might be worth looking into), however, even if DPDK is not"},{"line_number":180,"context_line":"    feasible, it is unclear what the performance gap is between"},{"line_number":181,"context_line":"    a DPDK capable solution and a kernel based solution with the"},{"line_number":182,"context_line":"    adoption of OVS firewall for security groups."}],"source_content_type":"text/x-rst","patch_set":7,"id":"dab17558_3d21bab5","line":179,"in_reply_to":"dab17558_57fbd278","updated":"2016-05-12 09:48:38.000000000","message":"Oh @sean, thanks. That\u0027s what I was exactly thinking. Thanks for expert confirmation :)","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4978608e38f2f2aadb2e9c9c3283c8c9bbaced68","unresolved":false,"context_lines":[{"line_number":175,"context_line":"    for both Open vSwitch and Linux Bridge."},{"line_number":176,"context_line":"  * Performance penalty: using VLAN interfaces means that the"},{"line_number":177,"context_line":"    kernel must be involved. For Open vSwitch, being able to use"},{"line_number":178,"context_line":"    a fast path like DPDK is an open issue (`Kernel NIC interfaces \u003chttp://dpdk.org/doc/guides/prog_guide/kernel_nic_interface.html\u003e`_"},{"line_number":179,"context_line":"    might be worth looking into), however, even if DPDK is not"},{"line_number":180,"context_line":"    feasible, it is unclear what the performance gap is between"},{"line_number":181,"context_line":"    a DPDK capable solution and a kernel based solution with the"},{"line_number":182,"context_line":"    adoption of OVS firewall for security groups."}],"source_content_type":"text/x-rst","patch_set":7,"id":"dab17558_57663bed","line":179,"range":{"start_line":178,"start_character":44,"end_line":179,"end_character":32},"in_reply_to":"dab17558_61661dee","updated":"2016-05-11 18:58:55.000000000","message":"if the kni module was upstream in the linux kernel then i would have no objection to using it provided the performance was good. the last time dpdk tried to upstream it it got fairly strong push back as the kernel netdev community are not keen on the idea of userspace process directly pushing packet to kernel memory via dma which is required for kni to work. \n\non a similar vain the distros i have talked to about this also do not want to ship a non upstream non gpl licensed kernel module. effectively they do not want to \"taint\" the kernel with a bsd module that is likely never going to be in the kernel tree.\n\nthe other issue with kni is its performance is significantly less then what vhost-user can support as there is still some over head involved in connecting it into the linux kernel networking stack. it is faster then kernel ovs with kernel vhost but still slow in comparison to a pure userspace datapath. this gap will continue to widen in the future as optimization efforts in dpdk focus on other areas.","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"e783a6ffe7756c601b42c8e73cd0f7897bb33af5","unresolved":false,"context_lines":[{"line_number":175,"context_line":"    for both Open vSwitch and Linux Bridge."},{"line_number":176,"context_line":"  * Performance penalty: using VLAN interfaces means that the"},{"line_number":177,"context_line":"    kernel must be involved. For Open vSwitch, being able to use"},{"line_number":178,"context_line":"    a fast path like DPDK is an open issue (`Kernel NIC interfaces \u003chttp://dpdk.org/doc/guides/prog_guide/kernel_nic_interface.html\u003e`_"},{"line_number":179,"context_line":"    might be worth looking into), however, even if DPDK is not"},{"line_number":180,"context_line":"    feasible, it is unclear what the performance gap is between"},{"line_number":181,"context_line":"    a DPDK capable solution and a kernel based solution with the"},{"line_number":182,"context_line":"    adoption of OVS firewall for security groups."}],"source_content_type":"text/x-rst","patch_set":7,"id":"dab17558_61661dee","line":179,"range":{"start_line":178,"start_character":44,"end_line":179,"end_character":32},"in_reply_to":"dab17558_895c0d4c","updated":"2016-05-11 17:42:36.000000000","message":"Good to know, Sean.  It is great to have your perspective here.","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"42cd35828c30064219fc0f410cb08eb29471048d","unresolved":false,"context_lines":[{"line_number":175,"context_line":"    for both Open vSwitch and Linux Bridge."},{"line_number":176,"context_line":"  * Performance penalty: using VLAN interfaces means that the"},{"line_number":177,"context_line":"    kernel must be involved. For Open vSwitch, being able to use"},{"line_number":178,"context_line":"    a fast path like DPDK is an open issue (`Kernel NIC interfaces \u003chttp://dpdk.org/doc/guides/prog_guide/kernel_nic_interface.html\u003e`_"},{"line_number":179,"context_line":"    might be worth looking into), however, even if DPDK is not"},{"line_number":180,"context_line":"    feasible, it is unclear what the performance gap is between"},{"line_number":181,"context_line":"    a DPDK capable solution and a kernel based solution with the"},{"line_number":182,"context_line":"    adoption of OVS firewall for security groups."}],"source_content_type":"text/x-rst","patch_set":7,"id":"dab17558_895c0d4c","line":179,"range":{"start_line":178,"start_character":44,"end_line":179,"end_character":32},"in_reply_to":"dab17558_eba86322","updated":"2016-05-11 17:35:48.000000000","message":"ack, thanks very much for the feedback, super appreciated.","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"67ac827c905845a48ea849c996c3c7296627b84f","unresolved":false,"context_lines":[{"line_number":210,"context_line":"    provisioning, thus making the requirement of QinQ support"},{"line_number":211,"context_line":"    no longer strictly necessary for Open vSwitch."},{"line_number":212,"context_line":""},{"line_number":213,"context_line":"* #TODO(armax): add more, if any (e.g. OVS+OVN??)."},{"line_number":214,"context_line":""},{"line_number":215,"context_line":"To summarize:"},{"line_number":216,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"dab17558_8e944543","line":213,"range":{"start_line":213,"start_character":0,"end_line":213,"end_character":50},"updated":"2016-05-10 20:07:34.000000000","message":"use a trunk bridge.\n\nfor each port create a port bridge.\nadd the tap/vhost-user to the port bridge.\nconnect the port bridge to the integration bridge with a patchport per subport.\n\non the port bridge side of the patch port set the port tag to the user asigned vlan for that subport. on the intergration bridge asing the local vlan as normal to the patchport. \n\n* Design complexity: low, this change require almost no changes to the existing agent.\n  * Upgrade complexity: existing deployments will be unable to\n    work correctly unless one of the actions take place: a) the\n    agent can handle both the \u0027old\u0027 and \u0027new\u0027 way of wiring the\n    data path.\n    b) a dataplane migration is done by atomically moving the port to the port bridge. this may cause dataplane distruption while the port is moved.\n\n  * Design reusability: a solution for Linux Bridge will still\n    be required to avoid widening the gap between Open vSwitch\n    (e.g. OVS has DVR but LB does not).\n  * Performance penalty: none. this will allow kernel or dpdk ovs to function with a single implementation. internal in ovs the additional bridges will be optimized when the bridges are collapsed into a single dataplane instance.\nwhen combined with the ovs conntrack security group driver this approach eliminates the need for a linux bridge between the vm tap device and the ovs bridge which should improve the performance of kernel ovs vs the current hybrid plug implementation with ip tables.\n \n  * Feature compatibility: with this approch, tenant\n    isolation is still provided by means of local vlan\n    provisioning, thus QinQ support is gated on a feuture  Open vSwitch version.","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"42cd35828c30064219fc0f410cb08eb29471048d","unresolved":false,"context_lines":[{"line_number":210,"context_line":"    provisioning, thus making the requirement of QinQ support"},{"line_number":211,"context_line":"    no longer strictly necessary for Open vSwitch."},{"line_number":212,"context_line":""},{"line_number":213,"context_line":"* #TODO(armax): add more, if any (e.g. OVS+OVN??)."},{"line_number":214,"context_line":""},{"line_number":215,"context_line":"To summarize:"},{"line_number":216,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"dab17558_e476a004","line":213,"in_reply_to":"dab17558_577aed77","updated":"2016-05-11 17:35:48.000000000","message":"@Sean: this is somewhat in line with what was discussed in previous revisions 1 and 3, and was mentioned on the spec (which prompted Russell to work on [1]), and I see it as a combination of A and B approaches.\n\nThis approach, the way I see it brings the best and worst of both worlds :( In fact:\n\n* from a design standpoint, we\u0027d have to have to maintain two code paths; this may not be as impactful on the existing design, but I am sure that some refactoring will need to be in order.\n* upgrade: as Sean said\n* performance: from Sean\u0027s comment, I understood that currently intra dataplane traffic is not yet optimized for dpdk (this seems a corner case that could be addressed with an anti-affinity, ie. spreading workload across multiple hosts, though it might be desirable), thus imposing an extra dependency on newer versions of OVS -- Sean, can you confirm?\n* design reusability: as Sean said,\n* Feature compatibility: we\u0027d still rely on local vlan provisioning, which leads to a need for QinQ.\n\nI can capture this and let us brainstorm a little, however the devil is in the detail :)\n\n[1] https://blueprints.launchpad.net/nova/+spec/neutron-ovs-bridge-name","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"69189a0e394af14c36b4b5dd70502ea23d3af863","unresolved":false,"context_lines":[{"line_number":210,"context_line":"    provisioning, thus making the requirement of QinQ support"},{"line_number":211,"context_line":"    no longer strictly necessary for Open vSwitch."},{"line_number":212,"context_line":""},{"line_number":213,"context_line":"* #TODO(armax): add more, if any (e.g. OVS+OVN??)."},{"line_number":214,"context_line":""},{"line_number":215,"context_line":"To summarize:"},{"line_number":216,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"dab17558_9e00c003","line":213,"range":{"start_line":213,"start_character":0,"end_line":213,"end_character":50},"in_reply_to":"dab17558_577aed77","updated":"2016-05-11 17:39:58.000000000","message":"i am not sure what the correct terminology is i have to check the original spec again but i am suggesting creating an ovs bridge per parent port(which i think is the trunkport e.g. the one that is attached to the vm) as distinct from the sub ports.\n\nbut yes to answer your question we would need one patch port pair per subport and one more for the untagged trafic. the only difference in the case of the untagged traffic is that while the local vlan will be set on the br-int side of the patch port no vlan will be set on the port bridge side of the patch port pair.\n\nincidentally if we were to take this approach i think it would be beneficial to always create the port bridge regardless of if it is a trunk bridge as it would allow you to convert a non trunk port to a trunk port at a later date if desired.\n\nby the way the creation of the port bridge could be done by os-vif where as the creation of the patch port pairs would be done by the ovs agent. When the os-vif pug fucntion is called it would create the port bridge based on the name passed in vif details it would then add the tap/vhost-user port to the port bridge and store the neutron port uuid in the external_ids: feild of the bridge. the neutron ovs agent would monitor for the addition of new ovs bridges and use the neutron port uuid in the bridge table to retirve the trunk information if available and create the patch ports as required.\n\nthis process should also work with external controllers like odl or ovn if modified correctly though they can use a more native openflow solution for this usecase.","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"5242eb563a8d43912e12c9840981f4c2f021fa77","unresolved":false,"context_lines":[{"line_number":210,"context_line":"    provisioning, thus making the requirement of QinQ support"},{"line_number":211,"context_line":"    no longer strictly necessary for Open vSwitch."},{"line_number":212,"context_line":""},{"line_number":213,"context_line":"* #TODO(armax): add more, if any (e.g. OVS+OVN??)."},{"line_number":214,"context_line":""},{"line_number":215,"context_line":"To summarize:"},{"line_number":216,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"dab17558_8464a649","line":213,"in_reply_to":"dab17558_6176d43f","updated":"2016-05-13 00:06:10.000000000","message":"@sean: ok, thanks for clarifying.","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":16800,"name":"Rawlin Peters","email":"rawlin.peters@hpe.com","username":"rawlin"},"change_message_id":"07b778b37dbf253f0987174d7ae38f40134a6dd0","unresolved":false,"context_lines":[{"line_number":210,"context_line":"    provisioning, thus making the requirement of QinQ support"},{"line_number":211,"context_line":"    no longer strictly necessary for Open vSwitch."},{"line_number":212,"context_line":""},{"line_number":213,"context_line":"* #TODO(armax): add more, if any (e.g. OVS+OVN??)."},{"line_number":214,"context_line":""},{"line_number":215,"context_line":"To summarize:"},{"line_number":216,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"dab17558_577aed77","line":213,"range":{"start_line":213,"start_character":0,"end_line":213,"end_character":50},"in_reply_to":"dab17558_743e0f29","updated":"2016-05-10 22:34:59.000000000","message":"For reference, here is the patch that added that \"pass the bridge name\" Nova functionality: https://review.openstack.org/#/c/260700/\n\n@sean just to clarify:\n\n\u003e for each port create a port bridge.\n\nYou mean to create an OVS bridge per trunk port, right?\n\nWhat happens to untagged traffic to/from the VM? Would we need another patchport from the trunk bridge to br-int to handle the untagged traffic?\n\nWill the trunk bridges need special openflow rules to handle the various traffic?","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"6c53d664bf297d359d0d8f3b28a1cdbb7ad19650","unresolved":false,"context_lines":[{"line_number":210,"context_line":"    provisioning, thus making the requirement of QinQ support"},{"line_number":211,"context_line":"    no longer strictly necessary for Open vSwitch."},{"line_number":212,"context_line":""},{"line_number":213,"context_line":"* #TODO(armax): add more, if any (e.g. OVS+OVN??)."},{"line_number":214,"context_line":""},{"line_number":215,"context_line":"To summarize:"},{"line_number":216,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"dab17558_743e0f29","line":213,"range":{"start_line":213,"start_character":0,"end_line":213,"end_character":50},"in_reply_to":"dab17558_8e944543","updated":"2016-05-10 22:14:06.000000000","message":"+1 to this approach. This feels like it will perform better, and on the surface seems much less invasive especially when compared to an purely openflow-based solution. Is there any reason not to pursue this, especially now that Nova allows us to pass a bridge name in the vif_details?","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"dd33423d81a17214bc84f7c7b9f54e3eeba2e549","unresolved":false,"context_lines":[{"line_number":210,"context_line":"    provisioning, thus making the requirement of QinQ support"},{"line_number":211,"context_line":"    no longer strictly necessary for Open vSwitch."},{"line_number":212,"context_line":""},{"line_number":213,"context_line":"* #TODO(armax): add more, if any (e.g. OVS+OVN??)."},{"line_number":214,"context_line":""},{"line_number":215,"context_line":"To summarize:"},{"line_number":216,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"dab17558_6176d43f","line":213,"in_reply_to":"dab17558_b7f31e72","updated":"2016-05-12 23:21:34.000000000","message":"@armando actually by the time Newton is released i am hoping the user space conntrack support will be merged in ovs.\n(https://patchwork.ozlabs.org/patch/611282/) this will enable the recently added conntrack based security group driver to be use with the kernel or dpdk datapath. as a fallback the learn action based driver we have in netwoking-ovs-dpdk could be use to provide stateless support in the interim.","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"0640e096458afe99541d93d2f9a0008eb8f6ab17","unresolved":false,"context_lines":[{"line_number":210,"context_line":"    provisioning, thus making the requirement of QinQ support"},{"line_number":211,"context_line":"    no longer strictly necessary for Open vSwitch."},{"line_number":212,"context_line":""},{"line_number":213,"context_line":"* #TODO(armax): add more, if any (e.g. OVS+OVN??)."},{"line_number":214,"context_line":""},{"line_number":215,"context_line":"To summarize:"},{"line_number":216,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"dab17558_b7f31e72","line":213,"in_reply_to":"dab17558_d46349af","updated":"2016-05-11 22:21:49.000000000","message":"@Sean: yes, you nailed it, thank you. One more thing: I remember from past conversations [1] that the use of ovs firewall with dpdk is currently not doable (i.e. the one merged in [2]), so were you referring to the learn-based firewall available in [3]?\n\n[1] https://bugs.launchpad.net/neutron/+bug/1531205\n[2] https://bugs.launchpad.net/neutron/+bug/1461000\n[3] https://github.com/openstack/networking-ovs-dpdk/blob/master/networking_ovs_dpdk/agent/ovs_dpdk_firewall.py","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"432826fa71996cc2afe2545e40026b5d0c4d322f","unresolved":false,"context_lines":[{"line_number":210,"context_line":"    provisioning, thus making the requirement of QinQ support"},{"line_number":211,"context_line":"    no longer strictly necessary for Open vSwitch."},{"line_number":212,"context_line":""},{"line_number":213,"context_line":"* #TODO(armax): add more, if any (e.g. OVS+OVN??)."},{"line_number":214,"context_line":""},{"line_number":215,"context_line":"To summarize:"},{"line_number":216,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"dab17558_ad43d4ad","line":213,"in_reply_to":"dab17558_e476a004","updated":"2016-05-11 19:23:37.000000000","message":"@Sean: I realized that I was not very clear in my question about dpdk. I was wondering if inter-bridge communication on a single data plane instance is already fully optimized and comparable (from a performance standpoint) to the case where only a single bridge is involved. If so, then we\u0027re good, if not, is there\u0027s anything in the making to make fill the gap?","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4978608e38f2f2aadb2e9c9c3283c8c9bbaced68","unresolved":false,"context_lines":[{"line_number":210,"context_line":"    provisioning, thus making the requirement of QinQ support"},{"line_number":211,"context_line":"    no longer strictly necessary for Open vSwitch."},{"line_number":212,"context_line":""},{"line_number":213,"context_line":"* #TODO(armax): add more, if any (e.g. OVS+OVN??)."},{"line_number":214,"context_line":""},{"line_number":215,"context_line":"To summarize:"},{"line_number":216,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"dab17558_d46349af","line":213,"in_reply_to":"dab17558_e476a004","updated":"2016-05-11 18:58:55.000000000","message":"@armando\nhi yes we discussed this or a variant of this during the Vancouver summit, which is as you said, why Russel introduced the ability to pass the bridge name into nova.\n\nQinQ would only be required in this case if we wanted to support QinQ for the guest. with this approch we would be translating the loval vlan to the vlan requeted by the tenant as part of the trunk port definition and vice versa.\n\nregarding performance im not sure i fully understood your question but ill try to answer. correct me if i got this wrong.\n\ncurrently an ovs bridge can only have one datapath type set (netdev or system). patch port only work between bridges of the same datapath type. ovs will collapse all bridges of the same datapath type that conneted by patch port into a single datapane instance. this effectivly means that there is 0 overhead with multiple bridges with a single port or one brige with multiple ports.\n\nthe other performance aspect with regards to ovs is the acceleration of the different port types. when using the system datapath the ovs and vhost kernel module accelerate packet processing of kernel interface such as tap device, veth port and kernel vhost ports. when using the netdev datapath with dpdk the dpdk interface(dpdkvhostuser,dpdk and dpdkr) are accelerate using the dpdk library. linux kernel interface are not accelerated by the dpdk library or ovs kernel module when using the netdev datapath. linux interfaces are process in the single threaded legacy userspace netdev dataplane code path which result in a performance bottleneck of ~40kpps for linux interfaces.","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"ddead7431a7b3e823afea79adcab75703c01e8ea","unresolved":false,"context_lines":[{"line_number":210,"context_line":"    provisioning, thus making the requirement of QinQ support"},{"line_number":211,"context_line":"    no longer strictly necessary for Open vSwitch."},{"line_number":212,"context_line":""},{"line_number":213,"context_line":"* #TODO(armax): add more, if any (e.g. OVS+OVN??)."},{"line_number":214,"context_line":""},{"line_number":215,"context_line":"To summarize:"},{"line_number":216,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"dab17558_cde458ad","line":213,"in_reply_to":"dab17558_e476a004","updated":"2016-05-11 19:30:33.000000000","message":"Upgrade complexity leaves a lot to be desired, which is a bummer.\n\n@Sean are you able to pull back the curtain and provide just a little more detail around how OVS collapses chained bridges?\n\nQinQ was mentioned, isn\u0027t there a way to do this without QinQ? I was thinking you would simply patch in multiple local VLAN\u0027s to the trunk bridge, then present them to the VM with the appropriate tag (or lack thereof). I guess I\u0027m not seeing where we need to push an outer VLAN tag. Can someone elaborate? I\u0027m not convinced it\u0027s necessary.","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"67ac827c905845a48ea849c996c3c7296627b84f","unresolved":false,"context_lines":[{"line_number":229,"context_line":"  Bridge) in order to fullfil both vlan awareness and transparency."},{"line_number":230,"context_line":""},{"line_number":231,"context_line":"To start with, option (A) may be pursued, as it is beneficial for"},{"line_number":232,"context_line":"Linux Bridge nonetheless. A working solution will also give the"},{"line_number":233,"context_line":"opportunity to identify the performance penalty compared to an"},{"line_number":234,"context_line":"accelerated fast-path solution. If the performance gap is of"},{"line_number":235,"context_line":"many orders of magnitude, and no other optimization is feasible,"},{"line_number":236,"context_line":"then investing in Option (B) becomes necessary and with it, data"},{"line_number":237,"context_line":"plane migration strategies required for solutions that employ"}],"source_content_type":"text/x-rst","patch_set":7,"id":"dab17558_34848c5c","line":234,"range":{"start_line":232,"start_character":27,"end_line":234,"end_character":31},"updated":"2016-05-10 20:07:34.000000000","message":"for context there is an example that can be used to proxy the perfromacne penalty for this approch with dpdk.\n\ncurrently today you can functionally use dvr with ovs and dpdk\ndvr user kernel tap interface which are added to the intergration bridge to send traffic to an network namespace to be routed.\n\nwhen used with the dpdk data plane these kernel tap device can only foreword traffic to/from the kernel at a rate of ~40,000 pps \n\none of the interesting tables form the latest onp performance report in this context is no page 30\nhttps://download.01.org/packet-processing/ONPS2.1/Intel_ONP_Release_2.1_Performance_Test_Report_Rev1.0.pdf\n\nthe first table show the making 0 loss forwarding rate for a vm using the dpdk testpmd application to do l3 forwarding in the guest. the traffic flow from the traffic generato a phical nic, then to the vm\u0027s first port and is forwarded with the dpdk application  to the vm\u0027s second port and forwarded to a another physical port by kernel ovs. in this configuration kernel ovs was capable of reaching ~470kpps.\n\novs with dpdk was able to reach ~3.4mpps that mean that a vm runing on ovs dpdk will have ~86 times the bandwith to a vm running on a seperat host as compered to a vm on the same host on a different l3 network using dvr. the performance pelenty so high that if using dvr for traffic between 2 vms on the same host in different l3 networks kernel ovs will out perfrome ovs with dpdk by over 10x.\n\nkni would mitigate this somewhat but useing kernel vlan interfaces as apart of the trunking solution would effectively make it unusable with ovs with dpdk even if it functionally worked.\n\nthis still might be the right way to go for linux bridge but if solution a is chosen for ovs a dedicated implementation will be required for ovs with dpdk.","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"42cd35828c30064219fc0f410cb08eb29471048d","unresolved":false,"context_lines":[{"line_number":231,"context_line":"To start with, option (A) may be pursued, as it is beneficial for"},{"line_number":232,"context_line":"Linux Bridge nonetheless. A working solution will also give the"},{"line_number":233,"context_line":"opportunity to identify the performance penalty compared to an"},{"line_number":234,"context_line":"accelerated fast-path solution. If the performance gap is of"},{"line_number":235,"context_line":"many orders of magnitude, and no other optimization is feasible,"},{"line_number":236,"context_line":"then investing in Option (B) becomes necessary and with it, data"},{"line_number":237,"context_line":"plane migration strategies required for solutions that employ"}],"source_content_type":"text/x-rst","patch_set":7,"id":"dab17558_7e707c0b","line":234,"in_reply_to":"dab17558_34848c5c","updated":"2016-05-11 17:35:48.000000000","message":"Sean, that\u0027s very insightful! What I hear is that you foresee no room for improvement in option A, and that it will be significantly slower than any dpdk enabled solution, correct?","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4978608e38f2f2aadb2e9c9c3283c8c9bbaced68","unresolved":false,"context_lines":[{"line_number":231,"context_line":"To start with, option (A) may be pursued, as it is beneficial for"},{"line_number":232,"context_line":"Linux Bridge nonetheless. A working solution will also give the"},{"line_number":233,"context_line":"opportunity to identify the performance penalty compared to an"},{"line_number":234,"context_line":"accelerated fast-path solution. If the performance gap is of"},{"line_number":235,"context_line":"many orders of magnitude, and no other optimization is feasible,"},{"line_number":236,"context_line":"then investing in Option (B) becomes necessary and with it, data"},{"line_number":237,"context_line":"plane migration strategies required for solutions that employ"}],"source_content_type":"text/x-rst","patch_set":7,"id":"dab17558_97df03d5","line":234,"in_reply_to":"dab17558_7e707c0b","updated":"2016-05-11 18:58:55.000000000","message":"unfortunetly yes.\n\nusing linux bridges as part of the ovs hybrid plug already reduce the performance of kernel ovs today vs when the vm tap divice is plugged directly into the ovs bridge.\n\nfor dpdk option a is effectively a non starter for two reasons: \n\nfirst the performance hit from coping all traffic form userspace to kernel space which require a context \n\nsecond the fact that with dpdk we do not have a tap device for the vm interface. with dpdk we use a vhost-user port for the vm which exits not exist in the kenel networking stack.as such we would still have to attached the vhost-user port to an ovs bridge and there for have to copy between all packets user/kernel space twice.\n\nsolution a could be viable for kernel ovs or linux bridge but i think the solution i proposed would be more efficient for kernel ovs while also supporting dpdk.\n\nregarding dvr our current recommend deployment configuration is to use either legacy ha routers on a kernel ovs network node or provider routers when using ovs with dpdk on a compute node. using the server anti afinity filter in this case wont help as the local dvr router would still process the packet via the tap device which is the source of the bottleneck. but this is a different topic that i would be happy do discuss elseware not to distract form this topic.","commit_id":"ca96668ae1031ce842d27539a5ad9505bd206b28"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"325287a04474136631a9ce2e4f836e20f3517fdb","unresolved":false,"context_lines":[{"line_number":143,"context_line":"  a negative impact for solving the transparency use case. Having"},{"line_number":144,"context_line":"  said that, the two features are still meant to be mutually"},{"line_number":145,"context_line":"  exclusive in their application, and plugging subports into"},{"line_number":146,"context_line":"  networks whose vlan-transparency flag might have unexpected"},{"line_number":147,"context_line":"  results.  In fact, it would be impossible from the platform\u0027s"},{"line_number":148,"context_line":"  point of view discerning which tagged packets are meant to be"},{"line_number":149,"context_line":"  treated \u0027transparently\u0027 and which ones are meant to be used"}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_78a4034a","line":146,"updated":"2016-05-12 00:54:21.000000000","message":"is set to True","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":16800,"name":"Rawlin Peters","email":"rawlin.peters@hpe.com","username":"rawlin"},"change_message_id":"1edd6ac45ad5635537f91e3663cae2ce38a0041d","unresolved":false,"context_lines":[{"line_number":159,"context_line":"* VLAN interfaces: in layman\u0027s terms, these interfaces allow to"},{"line_number":160,"context_line":"  demux the traffic before it hits the integration bridge where"},{"line_number":161,"context_line":"  the traffic will get isolated and sent off to the right"},{"line_number":162,"context_line":"  destination. This solution is `proven \u003chttps://etherpad.openstack.org/p/vlan@tap_experiment\u003e`_"},{"line_number":163,"context_line":"  to work at least in the case of iptables-based security rules"},{"line_number":164,"context_line":"  (credit to Rawlin Peters), though more validation is required"},{"line_number":165,"context_line":"  for the ovs native case. This solution has the following design"},{"line_number":166,"context_line":"  implications:"},{"line_number":167,"context_line":""},{"line_number":168,"context_line":"  * Design complexity: this requires relative small changes"}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_9e035776","line":165,"range":{"start_line":162,"start_character":15,"end_line":165,"end_character":26},"updated":"2016-05-12 22:50:05.000000000","message":"I proved the ovs native firewall case today and updated this etherpad with the change in steps. Plugging the vlan@tap device directly into br-int turned out to be much simpler than I had anticipated.\n\nSo the vlan@tap implementation should work with both the iptables and ovs-native firewalls.","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":21273,"name":"Ilya Chukhnakov","email":"Ilya.chukhnakov@gmail.com","username":"ichukhnakov"},"change_message_id":"30a2c96f1a5a3d18fc0676c8e09109ea9fd43be2","unresolved":false,"context_lines":[{"line_number":159,"context_line":"* VLAN interfaces: in layman\u0027s terms, these interfaces allow to"},{"line_number":160,"context_line":"  demux the traffic before it hits the integration bridge where"},{"line_number":161,"context_line":"  the traffic will get isolated and sent off to the right"},{"line_number":162,"context_line":"  destination. This solution is `proven \u003chttps://etherpad.openstack.org/p/vlan@tap_experiment\u003e`_"},{"line_number":163,"context_line":"  to work at least in the case of iptables-based security rules"},{"line_number":164,"context_line":"  (credit to Rawlin Peters), though more validation is required"},{"line_number":165,"context_line":"  for the ovs native case. This solution has the following design"},{"line_number":166,"context_line":"  implications:"},{"line_number":167,"context_line":""},{"line_number":168,"context_line":"  * Design complexity: this requires relative small changes"}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_44ee3eed","line":165,"range":{"start_line":162,"start_character":15,"end_line":165,"end_character":26},"in_reply_to":"dab17558_9e035776","updated":"2016-05-12 23:58:59.000000000","message":"Well, I suggested that (and had it working) exactly 1 month ago :) Should probably have posted those 70 lines of Nova code I guess...\n\nHowever there\u0027s still a problem with the hybrid firewall case here. By the time we detect an interface in OVS, its the veth pair (+bridge) created by Nova. But the tap may still have not been created yet by libvirt. So we either need to poll for the tap, or somehow get notified as soon as the tap is created.\n\nSo it\u0027s damn easy to implement in Nova (or os-vif). But gets quite complicated when doing so in Neutron.","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"f23ce2ec890a3b52615b2631bde4babc9a748134","unresolved":false,"context_lines":[{"line_number":159,"context_line":"* VLAN interfaces: in layman\u0027s terms, these interfaces allow to"},{"line_number":160,"context_line":"  demux the traffic before it hits the integration bridge where"},{"line_number":161,"context_line":"  the traffic will get isolated and sent off to the right"},{"line_number":162,"context_line":"  destination. This solution is `proven \u003chttps://etherpad.openstack.org/p/vlan@tap_experiment\u003e`_"},{"line_number":163,"context_line":"  to work at least in the case of iptables-based security rules"},{"line_number":164,"context_line":"  (credit to Rawlin Peters), though more validation is required"},{"line_number":165,"context_line":"  for the ovs native case. This solution has the following design"},{"line_number":166,"context_line":"  implications:"},{"line_number":167,"context_line":""},{"line_number":168,"context_line":"  * Design complexity: this requires relative small changes"}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_a4b9eaee","line":165,"range":{"start_line":162,"start_character":15,"end_line":165,"end_character":26},"in_reply_to":"dab17558_9e035776","updated":"2016-05-13 00:06:02.000000000","message":"ack, I\u0027ll revise, that\u0027s a bunch for driving this investigation!","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":21273,"name":"Ilya Chukhnakov","email":"Ilya.chukhnakov@gmail.com","username":"ichukhnakov"},"change_message_id":"5d1e7825101b60b4467659389549360394637aab","unresolved":false,"context_lines":[{"line_number":159,"context_line":"* VLAN interfaces: in layman\u0027s terms, these interfaces allow to"},{"line_number":160,"context_line":"  demux the traffic before it hits the integration bridge where"},{"line_number":161,"context_line":"  the traffic will get isolated and sent off to the right"},{"line_number":162,"context_line":"  destination. This solution is `proven \u003chttps://etherpad.openstack.org/p/vlan@tap_experiment\u003e`_"},{"line_number":163,"context_line":"  to work at least in the case of iptables-based security rules"},{"line_number":164,"context_line":"  (credit to Rawlin Peters), though more validation is required"},{"line_number":165,"context_line":"  for the ovs native case. This solution has the following design"},{"line_number":166,"context_line":"  implications:"},{"line_number":167,"context_line":""},{"line_number":168,"context_line":"  * Design complexity: this requires relative small changes"}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_cfb36709","line":165,"range":{"start_line":162,"start_character":15,"end_line":165,"end_character":26},"in_reply_to":"dab17558_a4b9eaee","updated":"2016-05-13 00:37:01.000000000","message":"Do you think it would be possible to make changes to Nova/os-vif (if its for Newton) for this spec? I believe I\u0027ve read somewhere that we can now pass custom fields in vif_details. If so, it would be quite easy to implement this as part of \u0027attach interface\u0027. I could probably publish my old POC on github (so we don\u0027t annoy Nova guys too early).","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"cbdcc9b2e0d6c543be353e5906a885adb29e22f4","unresolved":false,"context_lines":[{"line_number":159,"context_line":"* VLAN interfaces: in layman\u0027s terms, these interfaces allow to"},{"line_number":160,"context_line":"  demux the traffic before it hits the integration bridge where"},{"line_number":161,"context_line":"  the traffic will get isolated and sent off to the right"},{"line_number":162,"context_line":"  destination. This solution is `proven \u003chttps://etherpad.openstack.org/p/vlan@tap_experiment\u003e`_"},{"line_number":163,"context_line":"  to work at least in the case of iptables-based security rules"},{"line_number":164,"context_line":"  (credit to Rawlin Peters), though more validation is required"},{"line_number":165,"context_line":"  for the ovs native case. This solution has the following design"},{"line_number":166,"context_line":"  implications:"},{"line_number":167,"context_line":""},{"line_number":168,"context_line":"  * Design complexity: this requires relative small changes"}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_2ac5c15a","line":165,"range":{"start_line":162,"start_character":15,"end_line":165,"end_character":26},"in_reply_to":"dab17558_cfb36709","updated":"2016-05-13 01:09:06.000000000","message":"the creation of the vlan subports could be done by os-vif yes if the information was passed as part of the vif details.\nat this point we are quite close to replacing the plug logic in nova with os-vif. this would be an extention to the  ovs plugin \n\nhttps://github.com/openstack/os-vif/tree/master/vif_plug_ovs\n\nif the info was passed in the you would have to extend the vif objects in \nhttps://github.com/openstack/os-vif/blob/master/os_vif/objects/vif.py\n\nin particalar VIFBridge,VIFOpenVSwitch and VIFVHostUser\n\nand then you would have to extend plug function in https://github.com/openstack/os-vif/blob/master/vif_plug_ovs/ovs.py\n\none thing to consider is one of the goals for os-vif for this cycle would be to inegrate it with both nova and neutron.\n\nthe neutron integration would move the creation of os-vif vif object from the nova  vif.py to neutron this may conflict with that work.","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":16800,"name":"Rawlin Peters","email":"rawlin.peters@hpe.com","username":"rawlin"},"change_message_id":"1edd6ac45ad5635537f91e3663cae2ce38a0041d","unresolved":false,"context_lines":[{"line_number":186,"context_line":"  * Feature compatibility: in order to keep the design simple once"},{"line_number":187,"context_line":"    VLAN interfaces are adopted, and yet enable VLAN transparency,"},{"line_number":188,"context_line":"    Open vSwitch needs to support QinQ, which is currently lacking"},{"line_number":189,"context_line":"    as 2.5 and with no current plan for integration."},{"line_number":190,"context_line":""},{"line_number":191,"context_line":"* Going full openflow: in layman\u0027s terms, this means programming the"},{"line_number":192,"context_line":"  dataplane using OpenFlow in order to provide tenant isolation, and"}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_9e2a37e6","line":189,"range":{"start_line":189,"start_character":4,"end_line":189,"end_character":6},"updated":"2016-05-12 22:50:05.000000000","message":"as of","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"f23ce2ec890a3b52615b2631bde4babc9a748134","unresolved":false,"context_lines":[{"line_number":186,"context_line":"  * Feature compatibility: in order to keep the design simple once"},{"line_number":187,"context_line":"    VLAN interfaces are adopted, and yet enable VLAN transparency,"},{"line_number":188,"context_line":"    Open vSwitch needs to support QinQ, which is currently lacking"},{"line_number":189,"context_line":"    as 2.5 and with no current plan for integration."},{"line_number":190,"context_line":""},{"line_number":191,"context_line":"* Going full openflow: in layman\u0027s terms, this means programming the"},{"line_number":192,"context_line":"  dataplane using OpenFlow in order to provide tenant isolation, and"}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_24ce9a83","line":189,"range":{"start_line":189,"start_character":4,"end_line":189,"end_character":6},"in_reply_to":"dab17558_9e2a37e6","updated":"2016-05-13 00:06:02.000000000","message":"Done","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"306bdaea949e2483a01256a11f632053285472c1","unresolved":false,"context_lines":[{"line_number":210,"context_line":"    a considerable engineering cost nonetheless. Security rules"},{"line_number":211,"context_line":"    will have to be provided by a `learn based firewall \u003chttps://github.com/openstack/networking-ovs-dpdk\u003e`_"},{"line_number":212,"context_line":"    to fully exploit the capabilities of DPDK, at least until"},{"line_number":213,"context_line":"    user space connection tracking becomes available in OVS."},{"line_number":214,"context_line":"  * Feature compatibility: with the adoption of Open Flow, tenant"},{"line_number":215,"context_line":"    isolation will no longer be provided by means of local vlan"},{"line_number":216,"context_line":"    provisioning, thus making the requirement of QinQ support"}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_843b069c","line":213,"range":{"start_line":213,"start_character":4,"end_line":213,"end_character":60},"updated":"2016-05-13 00:47:17.000000000","message":"do you want to reference the \npatch series for usersapce conntarck support in ovs\n\nhttps://patchwork.ozlabs.org/patch/611282/\n\ni might not be relevant in a neutron context but just adding here in case people want to track its progress\n\nps this is part of a series of patches but i cant find the cover letter on the mailing list.","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"ab2cd03afa41ff024930ff547e5eab83f03f8a7f","unresolved":false,"context_lines":[{"line_number":210,"context_line":"    a considerable engineering cost nonetheless. Security rules"},{"line_number":211,"context_line":"    will have to be provided by a `learn based firewall \u003chttps://github.com/openstack/networking-ovs-dpdk\u003e`_"},{"line_number":212,"context_line":"    to fully exploit the capabilities of DPDK, at least until"},{"line_number":213,"context_line":"    user space connection tracking becomes available in OVS."},{"line_number":214,"context_line":"  * Feature compatibility: with the adoption of Open Flow, tenant"},{"line_number":215,"context_line":"    isolation will no longer be provided by means of local vlan"},{"line_number":216,"context_line":"    provisioning, thus making the requirement of QinQ support"}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_ca0b557c","line":213,"range":{"start_line":213,"start_character":4,"end_line":213,"end_character":60},"in_reply_to":"dab17558_843b069c","updated":"2016-05-13 01:50:30.000000000","message":"can do, thanks!","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":8788,"name":"Miguel Angel Ajo","email":"mangelajo@redhat.com","username":"mangelajo"},"change_message_id":"2e6b2042bd368182e2f9ae0e99f03038b01b5a59","unresolved":false,"context_lines":[{"line_number":216,"context_line":"    provisioning, thus making the requirement of QinQ support"},{"line_number":217,"context_line":"    no longer strictly necessary for Open vSwitch."},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"* Per trunk port OVS bridge: in layman\u0027s terms, this is similar to"},{"line_number":220,"context_line":"  the first option, in that an extra layer of mux/demux is introduced"},{"line_number":221,"context_line":"  between the VM and the integration bridge (br-int) but instead of"},{"line_number":222,"context_line":"  using vlan intefaces, a combination of a new OVS bridge (trunk"}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_7dc4e25e","line":219,"updated":"2016-05-12 09:47:29.000000000","message":"Do we have any sort of diagram or poc explaining how would we do this?","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"306bdaea949e2483a01256a11f632053285472c1","unresolved":false,"context_lines":[{"line_number":216,"context_line":"    provisioning, thus making the requirement of QinQ support"},{"line_number":217,"context_line":"    no longer strictly necessary for Open vSwitch."},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"* Per trunk port OVS bridge: in layman\u0027s terms, this is similar to"},{"line_number":220,"context_line":"  the first option, in that an extra layer of mux/demux is introduced"},{"line_number":221,"context_line":"  between the VM and the integration bridge (br-int) but instead of"},{"line_number":222,"context_line":"  using vlan intefaces, a combination of a new OVS bridge (trunk"}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_e16c840a","line":219,"in_reply_to":"dab17558_53629817","updated":"2016-05-13 00:47:17.000000000","message":"i may be able to pull together a quick poc demonstrating  this approach. i have done similar work to this in the past using patch port a a routing bridge to implement dvr.\n\nwhere firewall rule would be applied would depend on the symantics desired and the security group driver used. \n\nassuming the conntrack or learn action security group driver\nif you were to use define the security group rules on the trunk port and not the subport then you would apply filtering rules to the trunk bridge. security group rules are difiend on the subports the you would have a choice between defining them on the trunk bridge or integration bridge.\n\nassuming the ip tables security group driver you could simply use the same hybrid plug mechanisum as you do today. the difference being that instead of creating the veth pair between the vm tap and the br-int you would create it between the tap and trunk bridge.","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"c32494cff889ef42ee541569c1a22ac465c76405","unresolved":false,"context_lines":[{"line_number":216,"context_line":"    provisioning, thus making the requirement of QinQ support"},{"line_number":217,"context_line":"    no longer strictly necessary for Open vSwitch."},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"* Per trunk port OVS bridge: in layman\u0027s terms, this is similar to"},{"line_number":220,"context_line":"  the first option, in that an extra layer of mux/demux is introduced"},{"line_number":221,"context_line":"  between the VM and the integration bridge (br-int) but instead of"},{"line_number":222,"context_line":"  using vlan intefaces, a combination of a new OVS bridge (trunk"}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_53629817","line":219,"in_reply_to":"dab17558_7dc4e25e","updated":"2016-05-12 17:10:24.000000000","message":"@Ajo: I think we should post one as soon as we converged on which option we go with, or you think that would be essential to make a decision? For instance, I wonder where firewall rules are applied. My only regret with this option is that from a network design perspective I cringe at the idea of having two bridges :(","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":16800,"name":"Rawlin Peters","email":"rawlin.peters@hpe.com","username":"rawlin"},"change_message_id":"851b46af426dea7cca4e1a7e19c8d8a92fd68ca4","unresolved":false,"context_lines":[{"line_number":219,"context_line":"* Per trunk port OVS bridge: in layman\u0027s terms, this is similar to"},{"line_number":220,"context_line":"  the first option, in that an extra layer of mux/demux is introduced"},{"line_number":221,"context_line":"  between the VM and the integration bridge (br-int) but instead of"},{"line_number":222,"context_line":"  using vlan intefaces, a combination of a new OVS bridge (trunk"},{"line_number":223,"context_line":"  bridge or br-trunk) and patch ports to wire this new bridge with"},{"line_number":224,"context_line":"  br-int will be used. This solution has the following design"},{"line_number":225,"context_line":"  implications:"}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_f6da9516","line":222,"range":{"start_line":222,"start_character":13,"end_line":222,"end_character":22},"updated":"2016-05-12 19:54:04.000000000","message":"interfaces","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"f23ce2ec890a3b52615b2631bde4babc9a748134","unresolved":false,"context_lines":[{"line_number":219,"context_line":"* Per trunk port OVS bridge: in layman\u0027s terms, this is similar to"},{"line_number":220,"context_line":"  the first option, in that an extra layer of mux/demux is introduced"},{"line_number":221,"context_line":"  between the VM and the integration bridge (br-int) but instead of"},{"line_number":222,"context_line":"  using vlan intefaces, a combination of a new OVS bridge (trunk"},{"line_number":223,"context_line":"  bridge or br-trunk) and patch ports to wire this new bridge with"},{"line_number":224,"context_line":"  br-int will be used. This solution has the following design"},{"line_number":225,"context_line":"  implications:"}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_04cb9673","line":222,"range":{"start_line":222,"start_character":13,"end_line":222,"end_character":22},"in_reply_to":"dab17558_f6da9516","updated":"2016-05-13 00:06:02.000000000","message":"Done","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":8873,"name":"Assaf Muller","email":"amuller@redhat.com","username":"amuller"},"change_message_id":"dbf403a703d3b081a29898886074edf80a44041d","unresolved":false,"context_lines":[{"line_number":228,"context_line":"    considered in between the above mentioned options in that"},{"line_number":229,"context_line":"    some work is already available since `Mitaka \u003chttps://blueprints.launchpad.net/nova/+spec/neutron-ovs-bridge-name\u003e`_"},{"line_number":230,"context_line":"    and the data path wiring logic can be partially reused."},{"line_number":231,"context_line":"  * Upgrade complexity: existing deployments will be unable to"},{"line_number":232,"context_line":"    work correctly unless one of the actions take place: a) the"},{"line_number":233,"context_line":"    agent can handle both the \u0027old\u0027 and \u0027new\u0027 way of wiring the"},{"line_number":234,"context_line":"    data path; b) a dataplane migration is done by atomically"}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_8d0b3e2b","line":231,"updated":"2016-05-12 15:57:55.000000000","message":"Isn\u0027t this the same issue with solution A?","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"2b2b198441d9257b290e380fd0fb3e404d2e782e","unresolved":false,"context_lines":[{"line_number":228,"context_line":"    considered in between the above mentioned options in that"},{"line_number":229,"context_line":"    some work is already available since `Mitaka \u003chttps://blueprints.launchpad.net/nova/+spec/neutron-ovs-bridge-name\u003e`_"},{"line_number":230,"context_line":"    and the data path wiring logic can be partially reused."},{"line_number":231,"context_line":"  * Upgrade complexity: existing deployments will be unable to"},{"line_number":232,"context_line":"    work correctly unless one of the actions take place: a) the"},{"line_number":233,"context_line":"    agent can handle both the \u0027old\u0027 and \u0027new\u0027 way of wiring the"},{"line_number":234,"context_line":"    data path; b) a dataplane migration is done by atomically"}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_d6daf6e8","line":231,"in_reply_to":"dab17558_8d0b3e2b","updated":"2016-05-12 17:24:34.000000000","message":"only in case of sub-option a), right?","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":16800,"name":"Rawlin Peters","email":"rawlin.peters@hpe.com","username":"rawlin"},"change_message_id":"851b46af426dea7cca4e1a7e19c8d8a92fd68ca4","unresolved":false,"context_lines":[{"line_number":229,"context_line":"    some work is already available since `Mitaka \u003chttps://blueprints.launchpad.net/nova/+spec/neutron-ovs-bridge-name\u003e`_"},{"line_number":230,"context_line":"    and the data path wiring logic can be partially reused."},{"line_number":231,"context_line":"  * Upgrade complexity: existing deployments will be unable to"},{"line_number":232,"context_line":"    work correctly unless one of the actions take place: a) the"},{"line_number":233,"context_line":"    agent can handle both the \u0027old\u0027 and \u0027new\u0027 way of wiring the"},{"line_number":234,"context_line":"    data path; b) a dataplane migration is done by atomically"},{"line_number":235,"context_line":"    by moving all existing ports to the new trunk bridge. In"}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_b625ad0b","line":232,"range":{"start_line":232,"start_character":33,"end_line":232,"end_character":36},"updated":"2016-05-12 19:54:04.000000000","message":"these","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"cb33b38f37eb84aa997ca43c7610003fd03ffc03","unresolved":false,"context_lines":[{"line_number":231,"context_line":"  * Upgrade complexity: existing deployments will be unable to"},{"line_number":232,"context_line":"    work correctly unless one of the actions take place: a) the"},{"line_number":233,"context_line":"    agent can handle both the \u0027old\u0027 and \u0027new\u0027 way of wiring the"},{"line_number":234,"context_line":"    data path; b) a dataplane migration is done by atomically"},{"line_number":235,"context_line":"    by moving all existing ports to the new trunk bridge. In"},{"line_number":236,"context_line":"    case of a), a design decision must be made to allow whether"},{"line_number":237,"context_line":"    existing ports can updated to become trunk ports."}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_b68af718","line":234,"updated":"2016-05-12 05:47:09.000000000","message":"I don\u0027t see why the agent can\u0027t handle both ways of wiring the data path. I had been envisioning trunk ports being wired differently than traditional ports. The trunk bridge is only created when a trunk port is requested. This actually would alleviate some migration headaches because existing ports continue in their current state. The drawback is that it becomes difficult to turn a traditional port into a trunk port and vice-versa. However I see that as a limitation I could live with initially, if not indefinitely.","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"bc5f0d10fcd4c2d0c309bb7e8492ba2104cc5e69","unresolved":false,"context_lines":[{"line_number":231,"context_line":"  * Upgrade complexity: existing deployments will be unable to"},{"line_number":232,"context_line":"    work correctly unless one of the actions take place: a) the"},{"line_number":233,"context_line":"    agent can handle both the \u0027old\u0027 and \u0027new\u0027 way of wiring the"},{"line_number":234,"context_line":"    data path; b) a dataplane migration is done by atomically"},{"line_number":235,"context_line":"    by moving all existing ports to the new trunk bridge. In"},{"line_number":236,"context_line":"    case of a), a design decision must be made to allow whether"},{"line_number":237,"context_line":"    existing ports can updated to become trunk ports."}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_7cce89b5","line":234,"in_reply_to":"dab17558_532a98e8","updated":"2016-05-12 17:54:35.000000000","message":"As long as design a) means that the when using OVS the trunk bridge is an OVS bridge and not a Linux bridge I can get on board with that. Maybe that\u0027s been the intent all along and the light bulb has just been slow to turn on for me.","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"79860d15221b1a11f7e1b1c4fb9402bdae23f0e0","unresolved":false,"context_lines":[{"line_number":231,"context_line":"  * Upgrade complexity: existing deployments will be unable to"},{"line_number":232,"context_line":"    work correctly unless one of the actions take place: a) the"},{"line_number":233,"context_line":"    agent can handle both the \u0027old\u0027 and \u0027new\u0027 way of wiring the"},{"line_number":234,"context_line":"    data path; b) a dataplane migration is done by atomically"},{"line_number":235,"context_line":"    by moving all existing ports to the new trunk bridge. In"},{"line_number":236,"context_line":"    case of a), a design decision must be made to allow whether"},{"line_number":237,"context_line":"    existing ports can updated to become trunk ports."}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_3dcb8d73","line":234,"in_reply_to":"dab17558_6bad9383","updated":"2016-05-17 20:23:12.000000000","message":"basically today nova handles L1 e.g. adding the port to the bridge and neutron handle L2 and L3\n\nas nova is currently responsible for attaching the tap or vhost-user port to ovs  i would have nova(specifically os-vif) create the trunk bridge. i dont think we need to change that workflow for this proposal.","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"3cec1611e978fb41d4790ca2c1a8c0f92f03cebd","unresolved":false,"context_lines":[{"line_number":231,"context_line":"  * Upgrade complexity: existing deployments will be unable to"},{"line_number":232,"context_line":"    work correctly unless one of the actions take place: a) the"},{"line_number":233,"context_line":"    agent can handle both the \u0027old\u0027 and \u0027new\u0027 way of wiring the"},{"line_number":234,"context_line":"    data path; b) a dataplane migration is done by atomically"},{"line_number":235,"context_line":"    by moving all existing ports to the new trunk bridge. In"},{"line_number":236,"context_line":"    case of a), a design decision must be made to allow whether"},{"line_number":237,"context_line":"    existing ports can updated to become trunk ports."}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_8713160d","line":234,"in_reply_to":"dab17558_7cce89b5","updated":"2016-05-12 18:20:57.000000000","message":"A Linux Bridge? God forbid!","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"bd9a07b4e01504fb77c8c4bc668cffc67886e407","unresolved":false,"context_lines":[{"line_number":231,"context_line":"  * Upgrade complexity: existing deployments will be unable to"},{"line_number":232,"context_line":"    work correctly unless one of the actions take place: a) the"},{"line_number":233,"context_line":"    agent can handle both the \u0027old\u0027 and \u0027new\u0027 way of wiring the"},{"line_number":234,"context_line":"    data path; b) a dataplane migration is done by atomically"},{"line_number":235,"context_line":"    by moving all existing ports to the new trunk bridge. In"},{"line_number":236,"context_line":"    case of a), a design decision must be made to allow whether"},{"line_number":237,"context_line":"    existing ports can updated to become trunk ports."}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_6bad9383","line":234,"in_reply_to":"dab17558_849f86b3","updated":"2016-05-16 17:49:56.000000000","message":"I\u0027m just starting to look into this aspect so bear with me. Do we have neutron or nova create the trunk bridge? In addition, with OVS I think we may want the tap port to be configured with vlan_mode\u003dtrunk. Do we wait for port binding to configure this so that Nova can be isolated from these changes, or do we pass some more fields to Nova so that nova-compute can configure the tap port? I think this point could use a little discussion here","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"306bdaea949e2483a01256a11f632053285472c1","unresolved":false,"context_lines":[{"line_number":231,"context_line":"  * Upgrade complexity: existing deployments will be unable to"},{"line_number":232,"context_line":"    work correctly unless one of the actions take place: a) the"},{"line_number":233,"context_line":"    agent can handle both the \u0027old\u0027 and \u0027new\u0027 way of wiring the"},{"line_number":234,"context_line":"    data path; b) a dataplane migration is done by atomically"},{"line_number":235,"context_line":"    by moving all existing ports to the new trunk bridge. In"},{"line_number":236,"context_line":"    case of a), a design decision must be made to allow whether"},{"line_number":237,"context_line":"    existing ports can updated to become trunk ports."}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_849f86b3","line":234,"in_reply_to":"dab17558_8713160d","updated":"2016-05-13 00:47:17.000000000","message":"option a is simple to suppot i think.\n\nbasically if the bridge name passed in the vif_details by neutron to nova exists(e.g. br-int) os-vif/nova would just plug the vm interface as it does today. \n\nif the bridge does not exist nova/os-vif would create the trunk bridge setting the neutron port id on the bridge external_id field and add the vm interface to the trunk bridge. then the neutron agent on seeing the new bridge would wire up the patch ports as needed.\n\nthis would mean that existing port would contiune to work and only trunk ports would use the new method.","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"c32494cff889ef42ee541569c1a22ac465c76405","unresolved":false,"context_lines":[{"line_number":231,"context_line":"  * Upgrade complexity: existing deployments will be unable to"},{"line_number":232,"context_line":"    work correctly unless one of the actions take place: a) the"},{"line_number":233,"context_line":"    agent can handle both the \u0027old\u0027 and \u0027new\u0027 way of wiring the"},{"line_number":234,"context_line":"    data path; b) a dataplane migration is done by atomically"},{"line_number":235,"context_line":"    by moving all existing ports to the new trunk bridge. In"},{"line_number":236,"context_line":"    case of a), a design decision must be made to allow whether"},{"line_number":237,"context_line":"    existing ports can updated to become trunk ports."}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_532a98e8","line":234,"in_reply_to":"dab17558_b68af718","updated":"2016-05-12 17:10:24.000000000","message":"@Ryan: you\u0027re saying that design a) should be pursued. I would tend to agree, but I suppose that any further design consideration should be \u0027exploded\u0027 into a separate section.","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"325287a04474136631a9ce2e4f836e20f3517fdb","unresolved":false,"context_lines":[{"line_number":232,"context_line":"    work correctly unless one of the actions take place: a) the"},{"line_number":233,"context_line":"    agent can handle both the \u0027old\u0027 and \u0027new\u0027 way of wiring the"},{"line_number":234,"context_line":"    data path; b) a dataplane migration is done by atomically"},{"line_number":235,"context_line":"    by moving all existing ports to the new trunk bridge. In"},{"line_number":236,"context_line":"    case of a), a design decision must be made to allow whether"},{"line_number":237,"context_line":"    existing ports can updated to become trunk ports."},{"line_number":238,"context_line":"  * Design reusability: a solution for Linux Bridge will still"}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_f86e33fe","line":235,"updated":"2016-05-12 00:54:21.000000000","message":"drop second by","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"325287a04474136631a9ce2e4f836e20f3517fdb","unresolved":false,"context_lines":[{"line_number":233,"context_line":"    agent can handle both the \u0027old\u0027 and \u0027new\u0027 way of wiring the"},{"line_number":234,"context_line":"    data path; b) a dataplane migration is done by atomically"},{"line_number":235,"context_line":"    by moving all existing ports to the new trunk bridge. In"},{"line_number":236,"context_line":"    case of a), a design decision must be made to allow whether"},{"line_number":237,"context_line":"    existing ports can updated to become trunk ports."},{"line_number":238,"context_line":"  * Design reusability: a solution for Linux Bridge will still"},{"line_number":239,"context_line":"    be required to avoid widening the gap between Open vSwitch"}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_587adfbd","line":236,"updated":"2016-05-12 00:54:21.000000000","message":"whether to allow","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":8873,"name":"Assaf Muller","email":"amuller@redhat.com","username":"amuller"},"change_message_id":"dbf403a703d3b081a29898886074edf80a44041d","unresolved":false,"context_lines":[{"line_number":241,"context_line":"  * Performance penalty: from a performance standpoint, the adoption"},{"line_number":242,"context_line":"    of a trunk bridge relieves the agent from employing kernel"},{"line_number":243,"context_line":"    interfaces, thus unlocking the full potential of fast packet"},{"line_number":244,"context_line":"    processing. That said, this is only doable in combination of"},{"line_number":245,"context_line":"    a native ovs firewall. At the time of writing the only DPDK"},{"line_number":246,"context_line":"    enabled firewall driver is the learn based one available in"},{"line_number":247,"context_line":"    the `networking-ovs-dpdk repo \u003chttps://github.com/openstack/networking-ovs-dpdk\u003e`_;"}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_ad544221","line":244,"updated":"2016-05-12 15:57:55.000000000","message":"Looking at the NFV use case, you\u0027re using DPDK to minimize latency and maximize bandwidth, in which case the whole security groups discussion is not relevant. For the case security groups are relevant, the expectation is that OVS 2.6 will bring userspace conntrack, in which case the stateful OVS firewall that Jakub implemented is expected to work with DPDK without changing any code changes. Taking both points in to consideration I don\u0027t see the bullet point that starts at line 241 to be terribly relevant.","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"2b2b198441d9257b290e380fd0fb3e404d2e782e","unresolved":false,"context_lines":[{"line_number":241,"context_line":"  * Performance penalty: from a performance standpoint, the adoption"},{"line_number":242,"context_line":"    of a trunk bridge relieves the agent from employing kernel"},{"line_number":243,"context_line":"    interfaces, thus unlocking the full potential of fast packet"},{"line_number":244,"context_line":"    processing. That said, this is only doable in combination of"},{"line_number":245,"context_line":"    a native ovs firewall. At the time of writing the only DPDK"},{"line_number":246,"context_line":"    enabled firewall driver is the learn based one available in"},{"line_number":247,"context_line":"    the `networking-ovs-dpdk repo \u003chttps://github.com/openstack/networking-ovs-dpdk\u003e`_;"}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_36670227","line":244,"in_reply_to":"dab17558_ad544221","updated":"2016-05-12 17:24:34.000000000","message":"I am not sure I see what you\u0027re suggesting. It seems you rephrase what I have already said. I did mention that user space conntrack is coming (line 212). I can reiterate here.","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"325287a04474136631a9ce2e4f836e20f3517fdb","unresolved":false,"context_lines":[{"line_number":249,"context_line":"    will not be affected by the introduction of a trunk bridge,"},{"line_number":250,"context_line":"    therefore use cases where VMs are connected to a vlan transparent"},{"line_number":251,"context_line":"    network via a regular port will still require QinQ support"},{"line_number":252,"context_line":"    from OVS."},{"line_number":253,"context_line":""},{"line_number":254,"context_line":"* #TODO(armax): add more, if any (e.g. OVS+OVN??)."},{"line_number":255,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_98572725","line":252,"updated":"2016-05-12 00:54:21.000000000","message":"unless all ports will make use of trunk bridges, in which case QinQ may not be needed? That said, I am not sure how doable this is.","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"306bdaea949e2483a01256a11f632053285472c1","unresolved":false,"context_lines":[{"line_number":249,"context_line":"    will not be affected by the introduction of a trunk bridge,"},{"line_number":250,"context_line":"    therefore use cases where VMs are connected to a vlan transparent"},{"line_number":251,"context_line":"    network via a regular port will still require QinQ support"},{"line_number":252,"context_line":"    from OVS."},{"line_number":253,"context_line":""},{"line_number":254,"context_line":"* #TODO(armax): add more, if any (e.g. OVS+OVN??)."},{"line_number":255,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_64770203","line":252,"in_reply_to":"dab17558_98572725","updated":"2016-05-13 00:47:17.000000000","message":"im not sure if using trunk bridges alone would allow vlan transparency if we want to keep a single br-int that uses the normal action.\n\none way to achive vlan transparency without QinQ would be to have a bridge per neutron network. this would work without trunk bridges too but is a resonably large change in design.\ncode wise i dont think would be huge but you would have to add bridge awareness to that agent.\n\nin this case tenant isolation is enforce by the fact that vms interfaces would be connected to different bridges per tenant network bridges. this would allow you to have vlan transparency on tunnelled, flat or local networks. \n\ni belive this is similar to how the linux bridge agent works though im not that familar with linux bridge.","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"27ed69ee8579c289a57675005a32068dda59a63d","unresolved":false,"context_lines":[{"line_number":255,"context_line":""},{"line_number":256,"context_line":"To summarize:"},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"* VLAN interfaces (A) are compelling because will lead to a relatively"},{"line_number":259,"context_line":"  contained engineering cost at the expenses of performance. Both"},{"line_number":260,"context_line":"  Neutron and Open vSwitch communities will need to be involved"},{"line_number":261,"context_line":"  in order to deliver vlan awareness, and later on vlan transparency."},{"line_number":262,"context_line":"  Irrespective of whether this strategy is chosen for Open vSwitch or"},{"line_number":263,"context_line":"  not, this is still the only viable approach for Linux Bridge and"},{"line_number":264,"context_line":"  thus pursued to address Linux Bridge support for VLAN trunking."},{"line_number":265,"context_line":""},{"line_number":266,"context_line":"* Open Flow (B) is compelling because it will allow Neutron to unlock"},{"line_number":267,"context_line":"  the full potential of Open vSwitch, at the expenses of development"}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_ca9eb506","line":264,"range":{"start_line":258,"start_character":0,"end_line":264,"end_character":65},"updated":"2016-05-13 01:22:08.000000000","message":"actually reading this again two things just occurred to me. \n\nin mitika support was added to the openvswitch agent for managing ovs with the windows kernel datapath. how would this work on windows? you can create vlan interface with netsh and i know you can bridges interfaces in some way but i have no idea if this would work with hyperv. the code would have to be different for each os.\n\nthe other question i had is will this work when you are not doing hybrid plug e.g. if you have security groups disabled either globally or when creating the port.\n\nif you add a tap directly to an ovs bridge and create a subport form it and add the subport to the same bridge dose it work correctly?","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"79860d15221b1a11f7e1b1c4fb9402bdae23f0e0","unresolved":false,"context_lines":[{"line_number":255,"context_line":""},{"line_number":256,"context_line":"To summarize:"},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"* VLAN interfaces (A) are compelling because will lead to a relatively"},{"line_number":259,"context_line":"  contained engineering cost at the expenses of performance. Both"},{"line_number":260,"context_line":"  Neutron and Open vSwitch communities will need to be involved"},{"line_number":261,"context_line":"  in order to deliver vlan awareness, and later on vlan transparency."},{"line_number":262,"context_line":"  Irrespective of whether this strategy is chosen for Open vSwitch or"},{"line_number":263,"context_line":"  not, this is still the only viable approach for Linux Bridge and"},{"line_number":264,"context_line":"  thus pursued to address Linux Bridge support for VLAN trunking."},{"line_number":265,"context_line":""},{"line_number":266,"context_line":"* Open Flow (B) is compelling because it will allow Neutron to unlock"},{"line_number":267,"context_line":"  the full potential of Open vSwitch, at the expenses of development"}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_9dab9974","line":264,"range":{"start_line":258,"start_character":0,"end_line":264,"end_character":65},"in_reply_to":"dab17558_a5289b86","updated":"2016-05-17 20:23:12.000000000","message":"you should be able to change the mac of the  vlan@tap1 interface with ip link correct? it would have to be updated to match the mac in the neutron db to have the correct behavior.","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":16800,"name":"Rawlin Peters","email":"rawlin.peters@hpe.com","username":"rawlin"},"change_message_id":"b51ac900dc26f2563fbdbd359a567fef4a061e66","unresolved":false,"context_lines":[{"line_number":255,"context_line":""},{"line_number":256,"context_line":"To summarize:"},{"line_number":257,"context_line":""},{"line_number":258,"context_line":"* VLAN interfaces (A) are compelling because will lead to a relatively"},{"line_number":259,"context_line":"  contained engineering cost at the expenses of performance. Both"},{"line_number":260,"context_line":"  Neutron and Open vSwitch communities will need to be involved"},{"line_number":261,"context_line":"  in order to deliver vlan awareness, and later on vlan transparency."},{"line_number":262,"context_line":"  Irrespective of whether this strategy is chosen for Open vSwitch or"},{"line_number":263,"context_line":"  not, this is still the only viable approach for Linux Bridge and"},{"line_number":264,"context_line":"  thus pursued to address Linux Bridge support for VLAN trunking."},{"line_number":265,"context_line":""},{"line_number":266,"context_line":"* Open Flow (B) is compelling because it will allow Neutron to unlock"},{"line_number":267,"context_line":"  the full potential of Open vSwitch, at the expenses of development"}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_a5289b86","line":264,"range":{"start_line":258,"start_character":0,"end_line":264,"end_character":65},"in_reply_to":"dab17558_ca9eb506","updated":"2016-05-13 17:37:04.000000000","message":"\u003e if you add a tap directly to an ovs bridge and create a subport form it and add the subport to the same bridge dose it work correctly?\n\nI still had my vlan@tap experiment up-and-running, where I basically had this:\n\n VM -\u003e tap1 -\u003e qbr1 -\u003e qvb1/qvo1 -\u003e br-int (network A)\n        +-\u003e vlan@tap1 -\u003e br-int            (network B)\n\nand unplugged tap1 from qbr1 and qvo1 from br-int, then plugged tap1 directly into br-int:\n\n VM -\u003e tap1 -\u003e br-int           (network A)\n        +-\u003e vlan@tap1 -\u003e br-int (network B)\n\nAt that point the VM still had connectivity to both networks A and B. The only problem I could possibly foresee in terms of security groups is that fact that both tap1 and vlan@tap1 share the same MAC address. However, I don\u0027t know if that\u0027s an issue because they are different ports on different local vlans at that point.","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"325287a04474136631a9ce2e4f836e20f3517fdb","unresolved":false,"context_lines":[{"line_number":272,"context_line":"  DPDK at the time of writing, but a learn-based firewall can be a"},{"line_number":273,"context_line":"  suitable alternative."},{"line_number":274,"context_line":""},{"line_number":275,"context_line":"* Trunk Bridges (C) tries to bring the best of option A and B together,"},{"line_number":276,"context_line":"  as far as OVS development and performance are concerned, but it"},{"line_number":277,"context_line":"  brings the worse too in that it introduces operational complexity,"},{"line_number":278,"context_line":"  and it would still require a Linux Bridge solution as well as"}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_78524336","line":275,"updated":"2016-05-12 00:54:21.000000000","message":"drop comma","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"cb33b38f37eb84aa997ca43c7610003fd03ffc03","unresolved":false,"context_lines":[{"line_number":274,"context_line":""},{"line_number":275,"context_line":"* Trunk Bridges (C) tries to bring the best of option A and B together,"},{"line_number":276,"context_line":"  as far as OVS development and performance are concerned, but it"},{"line_number":277,"context_line":"  brings the worse too in that it introduces operational complexity,"},{"line_number":278,"context_line":"  and it would still require a Linux Bridge solution as well as"},{"line_number":279,"context_line":"  OVS vlan transparency support."},{"line_number":280,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_b67b17f4","line":277,"updated":"2016-05-12 05:47:09.000000000","message":"After thinking about this a little more (maybe a dangerous thing to do), I\u0027m not actually seeing a lot of upgrade or operational complexity. In terms of upgrade, traditional ports continue to be treated the way they always have. No need to do anything special to them during an upgrade. In terms of operational complexity, I\u0027m not seeing any more of a burden being placed on operators. Can we explore that a little more?\n\nI think you\u0027ve done a good job capturing the biggest drawback in my mind which is the widening gap between OVS and Linux bridge.","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"c32494cff889ef42ee541569c1a22ac465c76405","unresolved":false,"context_lines":[{"line_number":274,"context_line":""},{"line_number":275,"context_line":"* Trunk Bridges (C) tries to bring the best of option A and B together,"},{"line_number":276,"context_line":"  as far as OVS development and performance are concerned, but it"},{"line_number":277,"context_line":"  brings the worse too in that it introduces operational complexity,"},{"line_number":278,"context_line":"  and it would still require a Linux Bridge solution as well as"},{"line_number":279,"context_line":"  OVS vlan transparency support."},{"line_number":280,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_735ebc77","line":277,"in_reply_to":"dab17558_1de796ad","updated":"2016-05-12 17:10:24.000000000","message":"@Ajo: there\u0027s some comments provided by Sean, that said, if we chose this approach, we\u0027ll definitely elaborate on this more","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"99a92d6567cd2aeb2c56492631d7684afd01dd31","unresolved":false,"context_lines":[{"line_number":274,"context_line":""},{"line_number":275,"context_line":"* Trunk Bridges (C) tries to bring the best of option A and B together,"},{"line_number":276,"context_line":"  as far as OVS development and performance are concerned, but it"},{"line_number":277,"context_line":"  brings the worse too in that it introduces operational complexity,"},{"line_number":278,"context_line":"  and it would still require a Linux Bridge solution as well as"},{"line_number":279,"context_line":"  OVS vlan transparency support."},{"line_number":280,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_6bca011c","line":277,"in_reply_to":"dab17558_65299289","updated":"2016-05-13 18:51:00.000000000","message":"@Ryan: your statement is fair, and the inability to convert between ports is most likely the most sensible thing to do in case of C)\n\nThe point is not so much about limiting the conversion but having to handle two different network designs  (on top of all the others) that, in turn, increase the number of moving parts and complicate the agent\u0027s internals....and when that happens we all know what reverberating effects we might experience.","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"0fe425b945f6fbe21899f1b8ed658924ebf0a8a1","unresolved":false,"context_lines":[{"line_number":274,"context_line":""},{"line_number":275,"context_line":"* Trunk Bridges (C) tries to bring the best of option A and B together,"},{"line_number":276,"context_line":"  as far as OVS development and performance are concerned, but it"},{"line_number":277,"context_line":"  brings the worse too in that it introduces operational complexity,"},{"line_number":278,"context_line":"  and it would still require a Linux Bridge solution as well as"},{"line_number":279,"context_line":"  OVS vlan transparency support."},{"line_number":280,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_65299289","line":277,"in_reply_to":"dab17558_b3694428","updated":"2016-05-13 17:51:48.000000000","message":"@Armando I\u0027m questioning the utility of it. Sure, it\u0027s restrictive but is it so restrictive that it gets in the way of realizing the use case? Count me as a skeptic. That said, I\u0027d love to hear someone make the case for turning an existing port into a trunk port and vice-versa. I could still be persuaded.\n\n@Ajo I\u0027ve hacked together a quick PoC under devstack to prove this out. The solution looks a lot like the Linux bridge solution, just with an OVS bridge instead. There may be some OpenFlow rules to refine, but the short version is that I presented a trunk port with vlan_mode\u003dnative_untagged to the VM via br-trunk, then patched in each network presented to the VM as a pair of OVS patch ports from br-int to br-trunk. I was able to bring in a neutron network as the untagged VLAN, and another neutron network as a tagged VLAN and send traffic (SSH, not just ICMP :) ) between VM\u0027s on these different networks using both the untagged VLAN and a VLAN subinterface. Sean referenced an etherpad, I\u0027ll check that out and see if I can add to it.","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"c32494cff889ef42ee541569c1a22ac465c76405","unresolved":false,"context_lines":[{"line_number":274,"context_line":""},{"line_number":275,"context_line":"* Trunk Bridges (C) tries to bring the best of option A and B together,"},{"line_number":276,"context_line":"  as far as OVS development and performance are concerned, but it"},{"line_number":277,"context_line":"  brings the worse too in that it introduces operational complexity,"},{"line_number":278,"context_line":"  and it would still require a Linux Bridge solution as well as"},{"line_number":279,"context_line":"  OVS vlan transparency support."},{"line_number":280,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_b3694428","line":277,"in_reply_to":"dab17558_b67b17f4","updated":"2016-05-12 17:10:24.000000000","message":"@Ryan: Say we go for option a) (side by side) never allowing the opportunity to turn an existing port into a trunk parent, then yes...the tough migration is solved, but only because you deflect the problem altogether ;)","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":8788,"name":"Miguel Angel Ajo","email":"mangelajo@redhat.com","username":"mangelajo"},"change_message_id":"2e6b2042bd368182e2f9ae0e99f03038b01b5a59","unresolved":false,"context_lines":[{"line_number":274,"context_line":""},{"line_number":275,"context_line":"* Trunk Bridges (C) tries to bring the best of option A and B together,"},{"line_number":276,"context_line":"  as far as OVS development and performance are concerned, but it"},{"line_number":277,"context_line":"  brings the worse too in that it introduces operational complexity,"},{"line_number":278,"context_line":"  and it would still require a Linux Bridge solution as well as"},{"line_number":279,"context_line":"  OVS vlan transparency support."},{"line_number":280,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_1de796ad","line":277,"in_reply_to":"dab17558_b67b17f4","updated":"2016-05-12 09:47:29.000000000","message":"@ryan, can you provided more details about how trunk bridges would be done?","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":6788,"name":"Rossella Sblendido","email":"rsblendido@suse.com","username":"rossella-o"},"change_message_id":"b3280dcea8dd64f3459241b3bb1c94a8fbda6d21","unresolved":false,"context_lines":[{"line_number":275,"context_line":"* Trunk Bridges (C) tries to bring the best of option A and B together,"},{"line_number":276,"context_line":"  as far as OVS development and performance are concerned, but it"},{"line_number":277,"context_line":"  brings the worse too in that it introduces operational complexity,"},{"line_number":278,"context_line":"  and it would still require a Linux Bridge solution as well as"},{"line_number":279,"context_line":"  OVS vlan transparency support."},{"line_number":280,"context_line":""},{"line_number":281,"context_line":"To start with, option (A) may be pursued, as it is beneficial for"}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_b2bae308","line":278,"range":{"start_line":278,"start_character":6,"end_line":278,"end_character":43},"updated":"2016-05-12 15:46:30.000000000","message":"Even if we go with option (A) we need to code and test the solution for Linux Bridge. The only benefit of picking (A) is that the model is similar for OVS and Linux Bridge but in terms of development effort it doesn\u0027t matter if we pick (A) or (C) for OVS, since Linux Bridge will need its own code anyway. That\u0027s why I think it\u0027s unfair to consider this a drawback for option (C)","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"c32494cff889ef42ee541569c1a22ac465c76405","unresolved":false,"context_lines":[{"line_number":275,"context_line":"* Trunk Bridges (C) tries to bring the best of option A and B together,"},{"line_number":276,"context_line":"  as far as OVS development and performance are concerned, but it"},{"line_number":277,"context_line":"  brings the worse too in that it introduces operational complexity,"},{"line_number":278,"context_line":"  and it would still require a Linux Bridge solution as well as"},{"line_number":279,"context_line":"  OVS vlan transparency support."},{"line_number":280,"context_line":""},{"line_number":281,"context_line":"To start with, option (A) may be pursued, as it is beneficial for"}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_d324c8c7","line":278,"range":{"start_line":278,"start_character":6,"end_line":278,"end_character":43},"in_reply_to":"dab17558_b2bae308","updated":"2016-05-12 17:10:24.000000000","message":"What I mean is that with option (A) we can strike two birds with one stone, the birds being OVS and LB. With Option B and C we need two ongoing development efforts potentially clashing together.","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"325287a04474136631a9ce2e4f836e20f3517fdb","unresolved":false,"context_lines":[{"line_number":288,"context_line":"compelling in the medium term, but it may further complicate the"},{"line_number":289,"context_line":"process of embracing Option (B) in the long run. The migration"},{"line_number":290,"context_line":"and development complexity involved in Option (C) and (B) respectively"},{"line_number":291,"context_line":"aposes the existential question as to whether investing in the"},{"line_number":292,"context_line":"agent-based architecture is an effective strategy, especially if"},{"line_number":293,"context_line":"the end result would look a lot like other maturing alternatives."},{"line_number":294,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_b8366b00","line":291,"updated":"2016-05-12 00:54:21.000000000","message":"poses","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"2b2b198441d9257b290e380fd0fb3e404d2e782e","unresolved":false,"context_lines":[{"line_number":288,"context_line":"compelling in the medium term, but it may further complicate the"},{"line_number":289,"context_line":"process of embracing Option (B) in the long run. The migration"},{"line_number":290,"context_line":"and development complexity involved in Option (C) and (B) respectively"},{"line_number":291,"context_line":"aposes the existential question as to whether investing in the"},{"line_number":292,"context_line":"agent-based architecture is an effective strategy, especially if"},{"line_number":293,"context_line":"the end result would look a lot like other maturing alternatives."},{"line_number":294,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_765eaa77","line":291,"in_reply_to":"dab17558_0ded8e8e","updated":"2016-05-12 17:24:34.000000000","message":"I would not take C as lightly even if we punt on the ability to migrate, because the network design looks definitely nastier than any other option on the table. It now clear that A is not viable long-term but as a team we should ask ourselves if we care enough to keep Linux Bridge at parity with OVS and thus carry out A to completion.","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":16800,"name":"Rawlin Peters","email":"rawlin.peters@hpe.com","username":"rawlin"},"change_message_id":"1edd6ac45ad5635537f91e3663cae2ce38a0041d","unresolved":false,"context_lines":[{"line_number":288,"context_line":"compelling in the medium term, but it may further complicate the"},{"line_number":289,"context_line":"process of embracing Option (B) in the long run. The migration"},{"line_number":290,"context_line":"and development complexity involved in Option (C) and (B) respectively"},{"line_number":291,"context_line":"aposes the existential question as to whether investing in the"},{"line_number":292,"context_line":"agent-based architecture is an effective strategy, especially if"},{"line_number":293,"context_line":"the end result would look a lot like other maturing alternatives."},{"line_number":294,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_3e9ceb68","line":291,"in_reply_to":"dab17558_1bd49a45","updated":"2016-05-12 22:50:05.000000000","message":"If we get two parallel implementations going, option A for LinuxBridge and option C for OVS, then the only functional disparity I can see from a user-perspective would be whether or not upgrade/migration to the new datapath is disruptive. Option A isn\u0027t disruptive for LinuxBridge, but Option C can potentially be disruptive for OVS.\n\nWould there be any other functional disparities in that case?","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"306bdaea949e2483a01256a11f632053285472c1","unresolved":false,"context_lines":[{"line_number":288,"context_line":"compelling in the medium term, but it may further complicate the"},{"line_number":289,"context_line":"process of embracing Option (B) in the long run. The migration"},{"line_number":290,"context_line":"and development complexity involved in Option (C) and (B) respectively"},{"line_number":291,"context_line":"aposes the existential question as to whether investing in the"},{"line_number":292,"context_line":"agent-based architecture is an effective strategy, especially if"},{"line_number":293,"context_line":"the end result would look a lot like other maturing alternatives."},{"line_number":294,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_8f879f11","line":291,"in_reply_to":"dab17558_3e9ceb68","updated":"2016-05-13 00:47:17.000000000","message":"im going to side step the discussion of dpdk and openflow prominence or lack there or in the futre but i am quit interested in this so i have created an etherpad for the trunk bridge approach. \nhttps://etherpad.openstack.org/p/trunkport_bridge_experiment\n\nit is currently empty but will try and mirror the steps in \nhttps://etherpad.openstack.org/p/vlan@tap_experiment\nand adapt for the trunk bridge approach with kernel ovs\nsince that is eaier for people to reproduce. also it would not be different for dpdk anyway.","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"f23ce2ec890a3b52615b2631bde4babc9a748134","unresolved":false,"context_lines":[{"line_number":288,"context_line":"compelling in the medium term, but it may further complicate the"},{"line_number":289,"context_line":"process of embracing Option (B) in the long run. The migration"},{"line_number":290,"context_line":"and development complexity involved in Option (C) and (B) respectively"},{"line_number":291,"context_line":"aposes the existential question as to whether investing in the"},{"line_number":292,"context_line":"agent-based architecture is an effective strategy, especially if"},{"line_number":293,"context_line":"the end result would look a lot like other maturing alternatives."},{"line_number":294,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_84082693","line":291,"in_reply_to":"dab17558_3e9ceb68","updated":"2016-05-13 00:06:02.000000000","message":"not that I can see, especially if we consider the two data planes exist side by side.","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":8873,"name":"Assaf Muller","email":"amuller@redhat.com","username":"amuller"},"change_message_id":"dbf403a703d3b081a29898886074edf80a44041d","unresolved":false,"context_lines":[{"line_number":288,"context_line":"compelling in the medium term, but it may further complicate the"},{"line_number":289,"context_line":"process of embracing Option (B) in the long run. The migration"},{"line_number":290,"context_line":"and development complexity involved in Option (C) and (B) respectively"},{"line_number":291,"context_line":"aposes the existential question as to whether investing in the"},{"line_number":292,"context_line":"agent-based architecture is an effective strategy, especially if"},{"line_number":293,"context_line":"the end result would look a lot like other maturing alternatives."},{"line_number":294,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_0ded8e8e","line":291,"in_reply_to":"dab17558_525737ca","updated":"2016-05-12 15:57:55.000000000","message":"I agree with Rossella. As far as I\u0027m concerned option A is a complete non-starter. For the NFV use case, if we implement a solution that blocks us from using DPDK, we didn\u0027t really answer the use case, so what is it exactly that we did?","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":16800,"name":"Rawlin Peters","email":"rawlin.peters@hpe.com","username":"rawlin"},"change_message_id":"851b46af426dea7cca4e1a7e19c8d8a92fd68ca4","unresolved":false,"context_lines":[{"line_number":288,"context_line":"compelling in the medium term, but it may further complicate the"},{"line_number":289,"context_line":"process of embracing Option (B) in the long run. The migration"},{"line_number":290,"context_line":"and development complexity involved in Option (C) and (B) respectively"},{"line_number":291,"context_line":"aposes the existential question as to whether investing in the"},{"line_number":292,"context_line":"agent-based architecture is an effective strategy, especially if"},{"line_number":293,"context_line":"the end result would look a lot like other maturing alternatives."},{"line_number":294,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_ac671ae9","line":291,"in_reply_to":"dab17558_765eaa77","updated":"2016-05-12 19:54:04.000000000","message":"I\u0027m not too familiar with LinuxBridge, but it seems that because it lacks OpenFlow support, it\u0027s not really where the future is headed anyway?\n\nAlso, the parity would really only be in terms of performance of the implementation, right? Which it seems like OVS is already ahead in that regard, especially with DPDK support.","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":6788,"name":"Rossella Sblendido","email":"rsblendido@suse.com","username":"rossella-o"},"change_message_id":"b3280dcea8dd64f3459241b3bb1c94a8fbda6d21","unresolved":false,"context_lines":[{"line_number":288,"context_line":"compelling in the medium term, but it may further complicate the"},{"line_number":289,"context_line":"process of embracing Option (B) in the long run. The migration"},{"line_number":290,"context_line":"and development complexity involved in Option (C) and (B) respectively"},{"line_number":291,"context_line":"aposes the existential question as to whether investing in the"},{"line_number":292,"context_line":"agent-based architecture is an effective strategy, especially if"},{"line_number":293,"context_line":"the end result would look a lot like other maturing alternatives."},{"line_number":294,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_525737ca","line":291,"in_reply_to":"dab17558_7d7d02b1","updated":"2016-05-12 15:46:30.000000000","message":"We are experiencing here the \"eternal recurrence\" theorized by Nietzsche since I feel option (C) is very similar to the alternatives Bence proposed.\n(A) is easier but has worse performance, that\u0027s the reason why it\u0027s OK for a POC but probably not for a real development.E.g. I don\u0027t think the NFV world would use vlan aware vms if the traffic speed is not satisfying. \n(B) is the best and it\u0027s the future. It\u0027s also a good way to procrastinate and schedule the implementation of vlan aware vms in 2 or more releases.\n\nI\u0027d go for (C) at this point. It\u0027s the best in terms of effort required and gain. In medius stat virtus. It\u0027s also doable in Newton if we start right away. In the meanwhile we can lean the foundations for (B) but this should be an independent effort. \nMy 2 cents.","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"87c89f4d5b2106b16bfcf4596bdb37e6051696af","unresolved":false,"context_lines":[{"line_number":288,"context_line":"compelling in the medium term, but it may further complicate the"},{"line_number":289,"context_line":"process of embracing Option (B) in the long run. The migration"},{"line_number":290,"context_line":"and development complexity involved in Option (C) and (B) respectively"},{"line_number":291,"context_line":"aposes the existential question as to whether investing in the"},{"line_number":292,"context_line":"agent-based architecture is an effective strategy, especially if"},{"line_number":293,"context_line":"the end result would look a lot like other maturing alternatives."},{"line_number":294,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_1bd49a45","line":291,"in_reply_to":"dab17558_ac671ae9","updated":"2016-05-12 21:40:54.000000000","message":"This really depends how one interprets future :)\n\nParity here is to be intended functionally.","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":8788,"name":"Miguel Angel Ajo","email":"mangelajo@redhat.com","username":"mangelajo"},"change_message_id":"2e6b2042bd368182e2f9ae0e99f03038b01b5a59","unresolved":false,"context_lines":[{"line_number":288,"context_line":"compelling in the medium term, but it may further complicate the"},{"line_number":289,"context_line":"process of embracing Option (B) in the long run. The migration"},{"line_number":290,"context_line":"and development complexity involved in Option (C) and (B) respectively"},{"line_number":291,"context_line":"aposes the existential question as to whether investing in the"},{"line_number":292,"context_line":"agent-based architecture is an effective strategy, especially if"},{"line_number":293,"context_line":"the end result would look a lot like other maturing alternatives."},{"line_number":294,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_7d7d02b1","line":291,"in_reply_to":"dab17558_b8366b00","updated":"2016-05-12 09:47:29.000000000","message":"indeed, it\u0027s an existential question, I agree.","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"26dbbd58bcb00ed676cee3faaf8ee44326d8d3c3","unresolved":false,"context_lines":[{"line_number":346,"context_line":""},{"line_number":347,"context_line":"Upgrade should be no concern, since old ports will keep working the same"},{"line_number":348,"context_line":"way as before."},{"line_number":349,"context_line":""},{"line_number":350,"context_line":"Future Work"},{"line_number":351,"context_line":"+++++++++++"},{"line_number":352,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_ed9f9cb1","line":349,"updated":"2016-05-17 17:20:09.000000000","message":"Are we missing some discussion of what extra fields may or may not need to be included with the RPC?","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"b539fde55af63c85faef98eac04aa027be913eb4","unresolved":false,"context_lines":[{"line_number":346,"context_line":""},{"line_number":347,"context_line":"Upgrade should be no concern, since old ports will keep working the same"},{"line_number":348,"context_line":"way as before."},{"line_number":349,"context_line":""},{"line_number":350,"context_line":"Future Work"},{"line_number":351,"context_line":"+++++++++++"},{"line_number":352,"context_line":""}],"source_content_type":"text/x-rst","patch_set":8,"id":"dab17558_488056f7","line":349,"in_reply_to":"dab17558_ed9f9cb1","updated":"2016-05-17 17:46:13.000000000","message":"I am actually thinking of splitting this patch in half. This one is gonna document the rationale and the strategy adopted for agent implementation as outlined above. Another one will be filed where we drill down into the design considerations of the specific solution. Rossella will follow up shortly and we can move some of the discussion over there.","commit_id":"72abd5d0968ca8b688a2d0a5faace27971ce9eaf"},{"author":{"_account_id":16800,"name":"Rawlin Peters","email":"rawlin.peters@hpe.com","username":"rawlin"},"change_message_id":"d05209affe65a220a1c8708f797f2261b21357a6","unresolved":false,"context_lines":[{"line_number":155,"context_line":"  are stacked up together, making guest support even more crucial"},{"line_number":156,"context_line":"  for the combined use case."},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"It is clear by now that an acceptable solution must to be assessed"},{"line_number":159,"context_line":"with these issues in mind. The potential solutions worth enumerating"},{"line_number":160,"context_line":"are:"},{"line_number":161,"context_line":""}],"source_content_type":"text/x-rst","patch_set":9,"id":"dab17558_c0009103","line":158,"range":{"start_line":158,"start_character":52,"end_line":158,"end_character":54},"updated":"2016-05-17 22:49:34.000000000","message":"to -\u003e \u0027\u0027","commit_id":"144dd1b110cbcd1ebbee2a2cbe15e6fbfe74a589"},{"author":{"_account_id":6788,"name":"Rossella Sblendido","email":"rsblendido@suse.com","username":"rossella-o"},"change_message_id":"a35da1776bc06f7084b7ece2e5dfd52a9d7d2a3f","unresolved":false,"context_lines":[{"line_number":163,"context_line":"  demux the traffic before it hits the integration bridge where"},{"line_number":164,"context_line":"  the traffic will get isolated and sent off to the right"},{"line_number":165,"context_line":"  destination. This solution is `proven \u003chttps://etherpad.openstack.org/p/vlan@tap_experiment\u003e`_"},{"line_number":166,"context_line":"  to work for both iptables-based and native ovs security rules"},{"line_number":167,"context_line":"  (credit to Rawlin Peters). This solution has the following design"},{"line_number":168,"context_line":"  implications:"},{"line_number":169,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_a2f9f5ca","line":166,"range":{"start_line":166,"start_character":38,"end_line":166,"end_character":63},"updated":"2016-05-18 12:13:58.000000000","message":"It doesn\u0027t works for OVS firewall out of the box since the firewall installs flows to strip the vlans and send the packets untagged to the VM. Rawling\u0027s experiment didn\u0027t consider that. I will look more into it and report back...my feeling is that we will need to modify the ovs firewall\u0027s code and make it somehow vlan aware.","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"47e9968dc2a8f1db5bda411c127be84bbb7fc855","unresolved":false,"context_lines":[{"line_number":163,"context_line":"  demux the traffic before it hits the integration bridge where"},{"line_number":164,"context_line":"  the traffic will get isolated and sent off to the right"},{"line_number":165,"context_line":"  destination. This solution is `proven \u003chttps://etherpad.openstack.org/p/vlan@tap_experiment\u003e`_"},{"line_number":166,"context_line":"  to work for both iptables-based and native ovs security rules"},{"line_number":167,"context_line":"  (credit to Rawlin Peters). This solution has the following design"},{"line_number":168,"context_line":"  implications:"},{"line_number":169,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_e7fe566a","line":166,"updated":"2016-05-18 18:03:04.000000000","message":"The VLAN tags are gone before the packets reach OVS so from the firewall\u0027s perspective, these vlan ports look no different than regular VM ports.","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":8655,"name":"Jakub Libosvar","email":"libosvar@redhat.com","username":"jlibosva"},"change_message_id":"be45939160e01edfecf4eae40128097010bbe13b","unresolved":false,"context_lines":[{"line_number":163,"context_line":"  demux the traffic before it hits the integration bridge where"},{"line_number":164,"context_line":"  the traffic will get isolated and sent off to the right"},{"line_number":165,"context_line":"  destination. This solution is `proven \u003chttps://etherpad.openstack.org/p/vlan@tap_experiment\u003e`_"},{"line_number":166,"context_line":"  to work for both iptables-based and native ovs security rules"},{"line_number":167,"context_line":"  (credit to Rawlin Peters). This solution has the following design"},{"line_number":168,"context_line":"  implications:"},{"line_number":169,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_86ae4183","line":166,"in_reply_to":"bab6814e_0af0b68f","updated":"2016-05-19 12:55:59.000000000","message":"I think Rossella\u0027s concern is that we have rule strip_vlan,output:\u003cport_no\u003e for inbound traffic. I lack in this description how exactly are packets tagged with the outer vlan but if that happens based on \u003cport_no\u003e after packets leave switch, it should be fine with ovs-firewall without any changes. With iptables driver, we do normal action that strips the vlan tag by itself.","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"f2f9dcf77cc2b23c92d92a29c500a6b8a851ed4d","unresolved":false,"context_lines":[{"line_number":163,"context_line":"  demux the traffic before it hits the integration bridge where"},{"line_number":164,"context_line":"  the traffic will get isolated and sent off to the right"},{"line_number":165,"context_line":"  destination. This solution is `proven \u003chttps://etherpad.openstack.org/p/vlan@tap_experiment\u003e`_"},{"line_number":166,"context_line":"  to work for both iptables-based and native ovs security rules"},{"line_number":167,"context_line":"  (credit to Rawlin Peters). This solution has the following design"},{"line_number":168,"context_line":"  implications:"},{"line_number":169,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_88d31638","line":166,"in_reply_to":"bab6814e_38019baf","updated":"2016-05-18 20:08:08.000000000","message":"If we have a subport configured to use vlan 100, the traffic coming from that port to OVS will be untagged. That\u0027s the whole point of using a VLAN interface, the kernel does the multiplexing for us so we just get a bunch of interfaces that pass and receive untagged traffic on the OVS side while the VM gets tagged traffic.","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"6a54ad6399326c0f36ac901792317d37add58e0e","unresolved":false,"context_lines":[{"line_number":163,"context_line":"  demux the traffic before it hits the integration bridge where"},{"line_number":164,"context_line":"  the traffic will get isolated and sent off to the right"},{"line_number":165,"context_line":"  destination. This solution is `proven \u003chttps://etherpad.openstack.org/p/vlan@tap_experiment\u003e`_"},{"line_number":166,"context_line":"  to work for both iptables-based and native ovs security rules"},{"line_number":167,"context_line":"  (credit to Rawlin Peters). This solution has the following design"},{"line_number":168,"context_line":"  implications:"},{"line_number":169,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_0af0b68f","line":166,"in_reply_to":"bab6814e_88d31638","updated":"2016-05-18 23:25:37.000000000","message":"I think @Kevin\u0027s got it right here.  At least his understanding matches mine.  By the time packets come out of any of the tap (or vlan@tap) interfaces, they have been stripped of the vlan tags.  So, no matter what firewall driver you use, they\u0027ll see untagged traffic coming from and going to the devices.","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":16800,"name":"Rawlin Peters","email":"rawlin.peters@hpe.com","username":"rawlin"},"change_message_id":"f809294912841655a55e9efaf3b3f0c7d993461b","unresolved":false,"context_lines":[{"line_number":163,"context_line":"  demux the traffic before it hits the integration bridge where"},{"line_number":164,"context_line":"  the traffic will get isolated and sent off to the right"},{"line_number":165,"context_line":"  destination. This solution is `proven \u003chttps://etherpad.openstack.org/p/vlan@tap_experiment\u003e`_"},{"line_number":166,"context_line":"  to work for both iptables-based and native ovs security rules"},{"line_number":167,"context_line":"  (credit to Rawlin Peters). This solution has the following design"},{"line_number":168,"context_line":"  implications:"},{"line_number":169,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_6730a602","line":166,"range":{"start_line":166,"start_character":38,"end_line":166,"end_character":63},"in_reply_to":"bab6814e_a2f9f5ca","updated":"2016-05-18 19:21:19.000000000","message":"@Rossella forgive me, I haven\u0027t used the ovs-native firewall in practice yet. Are you saying that when using the ovs-native firewall the tap port on br-int is no longer configured as an access port (by setting tag\u003d\u003clocal vid\u003e on that port), similar to how the qvo port is configured in the hybrid-iptables firewall? My understanding is that the local VLAN ID is stripped/applied (on egress/ingress, respectively) at the qvo port because it has tag\u003d\u003clocal vid\u003e. Does the ovs-native firewall configure the tap similarly, or is that handled purely in openflow rules?\n\nThat said, Kevin is right. The vlan interfaces strip their corresponding tags before the traffic reaches br-int, so they should play nicely with any openflow rules on br-int that assume traffic from the VM is untagged.","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":6788,"name":"Rossella Sblendido","email":"rsblendido@suse.com","username":"rossella-o"},"change_message_id":"14a885dc51f13d64ea281d90c61244b3cb42d578","unresolved":false,"context_lines":[{"line_number":163,"context_line":"  demux the traffic before it hits the integration bridge where"},{"line_number":164,"context_line":"  the traffic will get isolated and sent off to the right"},{"line_number":165,"context_line":"  destination. This solution is `proven \u003chttps://etherpad.openstack.org/p/vlan@tap_experiment\u003e`_"},{"line_number":166,"context_line":"  to work for both iptables-based and native ovs security rules"},{"line_number":167,"context_line":"  (credit to Rawlin Peters). This solution has the following design"},{"line_number":168,"context_line":"  implications:"},{"line_number":169,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_38019baf","line":166,"in_reply_to":"bab6814e_e7fe566a","updated":"2016-05-18 19:06:08.000000000","message":"My point was not clear. Imagine we have a subport configured to use vlan 100, the inbound traffic for that port should be tagged. I haven\u0027t tested yet but I think OVS firewall strips the VLAN for inbound traffic.","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"47e9968dc2a8f1db5bda411c127be84bbb7fc855","unresolved":false,"context_lines":[{"line_number":199,"context_line":"  * Upgrade complexity: existing deployments will be unable to"},{"line_number":200,"context_line":"    work correctly unless one of the actions take place: a) the"},{"line_number":201,"context_line":"    agent can handle both the \u0027old\u0027 and \u0027new\u0027 way of wiring the"},{"line_number":202,"context_line":"    data path; b) a dataplane migration is forced during a release"},{"line_number":203,"context_line":"    upgrade and thus it may cause (potentially unrecoverable) dataplane"},{"line_number":204,"context_line":"    disruption."},{"line_number":205,"context_line":"  * Design reusability: a solution for Linux Bridge will still"}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_c7035272","line":202,"updated":"2016-05-18 18:03:04.000000000","message":"If we go this route I would suggest having some logic that recognizes that there is a bridge and then clears all of the iptables rules for that bridge. That way the filtering can happen in OVS just like a directly attached tap interface.","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":8788,"name":"Miguel Angel Ajo","email":"mangelajo@redhat.com","username":"mangelajo"},"change_message_id":"0dca3f10799dd8885852d6a8059fa9e7e0b11b19","unresolved":false,"context_lines":[{"line_number":199,"context_line":"  * Upgrade complexity: existing deployments will be unable to"},{"line_number":200,"context_line":"    work correctly unless one of the actions take place: a) the"},{"line_number":201,"context_line":"    agent can handle both the \u0027old\u0027 and \u0027new\u0027 way of wiring the"},{"line_number":202,"context_line":"    data path; b) a dataplane migration is forced during a release"},{"line_number":203,"context_line":"    upgrade and thus it may cause (potentially unrecoverable) dataplane"},{"line_number":204,"context_line":"    disruption."},{"line_number":205,"context_line":"  * Design reusability: a solution for Linux Bridge will still"}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_fc244eb0","line":202,"updated":"2016-05-18 09:13:53.000000000","message":"do you mean hybrid  to pure ovs/openflow ? \n\nor old openflow to new openflow? (this one wouldn\u0027t have any issue, while the former, as you say it would unless we managed to support both concurrently, which I suspect, could be done by using the hybrid firewall driver simultaneously based on the type of port binding).","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"a22f348b3d1e04c772df30d7cb421b4f86cbad06","unresolved":false,"context_lines":[{"line_number":199,"context_line":"  * Upgrade complexity: existing deployments will be unable to"},{"line_number":200,"context_line":"    work correctly unless one of the actions take place: a) the"},{"line_number":201,"context_line":"    agent can handle both the \u0027old\u0027 and \u0027new\u0027 way of wiring the"},{"line_number":202,"context_line":"    data path; b) a dataplane migration is forced during a release"},{"line_number":203,"context_line":"    upgrade and thus it may cause (potentially unrecoverable) dataplane"},{"line_number":204,"context_line":"    disruption."},{"line_number":205,"context_line":"  * Design reusability: a solution for Linux Bridge will still"}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_2d32fff1","line":202,"in_reply_to":"bab6814e_c7035272","updated":"2016-05-18 18:42:36.000000000","message":"Going pure openflow would mean moving away from hybrid plugging as well as tenant isolation via local vlan provisioning. In other words a complete overhaul of the agent architecture.","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"6a54ad6399326c0f36ac901792317d37add58e0e","unresolved":false,"context_lines":[{"line_number":235,"context_line":"    from one to the other (and vice versa), no migration is"},{"line_number":236,"context_line":"    required. This is done at a cost of some loss of flexibility"},{"line_number":237,"context_line":"    and maintainance complexity."},{"line_number":238,"context_line":"  * Design reusability: a solution for Linux Bridge will still"},{"line_number":239,"context_line":"    be required to avoid widening the gap between Open vSwitch"},{"line_number":240,"context_line":"    (e.g. OVS has DVR but LB does not)."},{"line_number":241,"context_line":"  * Performance penalty: from a performance standpoint, the adoption"}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_ea20d24b","line":238,"range":{"start_line":238,"start_character":26,"end_line":238,"end_character":51},"updated":"2016-05-18 23:25:37.000000000","message":"This includes the linux bridge firewall driver for ovs, right?  I think it must because the traffic must be demuxed before security groups are applied.","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"2dd6fa4fa107fc3ab3a3e2297943c03394bcd5c1","unresolved":false,"context_lines":[{"line_number":235,"context_line":"    from one to the other (and vice versa), no migration is"},{"line_number":236,"context_line":"    required. This is done at a cost of some loss of flexibility"},{"line_number":237,"context_line":"    and maintainance complexity."},{"line_number":238,"context_line":"  * Design reusability: a solution for Linux Bridge will still"},{"line_number":239,"context_line":"    be required to avoid widening the gap between Open vSwitch"},{"line_number":240,"context_line":"    (e.g. OVS has DVR but LB does not)."},{"line_number":241,"context_line":"  * Performance penalty: from a performance standpoint, the adoption"}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_f5f4b95b","line":238,"in_reply_to":"bab6814e_99321b0f","updated":"2016-05-20 22:44:29.000000000","message":"linuxbridge firewall with this solution is not supported. Why would we?","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":16800,"name":"Rawlin Peters","email":"rawlin.peters@hpe.com","username":"rawlin"},"change_message_id":"850c79ff17113e3a0af48f8e15902e53d81c489d","unresolved":false,"context_lines":[{"line_number":235,"context_line":"    from one to the other (and vice versa), no migration is"},{"line_number":236,"context_line":"    required. This is done at a cost of some loss of flexibility"},{"line_number":237,"context_line":"    and maintainance complexity."},{"line_number":238,"context_line":"  * Design reusability: a solution for Linux Bridge will still"},{"line_number":239,"context_line":"    be required to avoid widening the gap between Open vSwitch"},{"line_number":240,"context_line":"    (e.g. OVS has DVR but LB does not)."},{"line_number":241,"context_line":"  * Performance penalty: from a performance standpoint, the adoption"}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_99321b0f","line":238,"range":{"start_line":238,"start_character":26,"end_line":238,"end_character":51},"in_reply_to":"bab6814e_ea20d24b","updated":"2016-05-19 15:10:30.000000000","message":"Hmmm...I believe you\u0027re right. I don\u0027t think we can use the per-trunk OVS bridge implementation with the linux bridge firewall. This implementation will require either no firewall or an ovs-native firewall.","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"47e9968dc2a8f1db5bda411c127be84bbb7fc855","unresolved":false,"context_lines":[{"line_number":255,"context_line":""},{"line_number":256,"context_line":"* VLAN interfaces (A) are compelling because will lead to a relatively"},{"line_number":257,"context_line":"  contained engineering cost at the expenses of performance. Both"},{"line_number":258,"context_line":"  Neutron and Open vSwitch communities will need to be involved"},{"line_number":259,"context_line":"  in order to deliver vlan awareness, and later on vlan transparency."},{"line_number":260,"context_line":"  Irrespective of whether this strategy is chosen for Open vSwitch or"},{"line_number":261,"context_line":"  not, this is still the only viable approach for Linux Bridge and"}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_27f97e81","line":258,"updated":"2016-05-18 18:03:04.000000000","message":"We don\u0027t need any changes from OVS for vlan awareness. The only cross community effort would be QinQ for vlan transparency + vlan aware.","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"8d724ee2f9e644c4d708b6a63a1f674ba487e677","unresolved":false,"context_lines":[{"line_number":255,"context_line":""},{"line_number":256,"context_line":"* VLAN interfaces (A) are compelling because will lead to a relatively"},{"line_number":257,"context_line":"  contained engineering cost at the expenses of performance. Both"},{"line_number":258,"context_line":"  Neutron and Open vSwitch communities will need to be involved"},{"line_number":259,"context_line":"  in order to deliver vlan awareness, and later on vlan transparency."},{"line_number":260,"context_line":"  Irrespective of whether this strategy is chosen for Open vSwitch or"},{"line_number":261,"context_line":"  not, this is still the only viable approach for Linux Bridge and"}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_2d2ddfa7","line":258,"in_reply_to":"bab6814e_0dd29b00","updated":"2016-05-18 19:00:21.000000000","message":"no, but ok I\u0027ll rephrase","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"a22f348b3d1e04c772df30d7cb421b4f86cbad06","unresolved":false,"context_lines":[{"line_number":255,"context_line":""},{"line_number":256,"context_line":"* VLAN interfaces (A) are compelling because will lead to a relatively"},{"line_number":257,"context_line":"  contained engineering cost at the expenses of performance. Both"},{"line_number":258,"context_line":"  Neutron and Open vSwitch communities will need to be involved"},{"line_number":259,"context_line":"  in order to deliver vlan awareness, and later on vlan transparency."},{"line_number":260,"context_line":"  Irrespective of whether this strategy is chosen for Open vSwitch or"},{"line_number":261,"context_line":"  not, this is still the only viable approach for Linux Bridge and"}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_8d820b51","line":258,"in_reply_to":"bab6814e_27f97e81","updated":"2016-05-18 18:42:36.000000000","message":"Haven\u0027t we said the same thing? Can you elaborate?","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"7f03380bff32936266fcc12fa3665a2dd16b0606","unresolved":false,"context_lines":[{"line_number":255,"context_line":""},{"line_number":256,"context_line":"* VLAN interfaces (A) are compelling because will lead to a relatively"},{"line_number":257,"context_line":"  contained engineering cost at the expenses of performance. Both"},{"line_number":258,"context_line":"  Neutron and Open vSwitch communities will need to be involved"},{"line_number":259,"context_line":"  in order to deliver vlan awareness, and later on vlan transparency."},{"line_number":260,"context_line":"  Irrespective of whether this strategy is chosen for Open vSwitch or"},{"line_number":261,"context_line":"  not, this is still the only viable approach for Linux Bridge and"}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_0dd29b00","line":258,"in_reply_to":"bab6814e_8d820b51","updated":"2016-05-18 18:52:31.000000000","message":"The way I read the sentence made it sound like the Open vSwitch community would need to be involved for VLAN awareness.","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"47e9968dc2a8f1db5bda411c127be84bbb7fc855","unresolved":false,"context_lines":[{"line_number":265,"context_line":"  the full potential of Open vSwitch, at the expenses of development"},{"line_number":266,"context_line":"  and operations effort. The development is confined within the"},{"line_number":267,"context_line":"  boundaries of the Neutron community (for both Open vSwitch and Linux"},{"line_number":268,"context_line":"  Bridge) in order to fullfil both vlan awareness and transparency."},{"line_number":269,"context_line":"  Stateful firewall (based on ovs conntrack) limits the adoption for"},{"line_number":270,"context_line":"  DPDK at the time of writing, but a learn-based firewall can be a"},{"line_number":271,"context_line":"  suitable alternative."}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_07f6fa8e","line":268,"updated":"2016-05-18 18:03:04.000000000","message":"Except for transparency on top of vlan awareness, that requires QinQ from OVS.","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"a22f348b3d1e04c772df30d7cb421b4f86cbad06","unresolved":false,"context_lines":[{"line_number":265,"context_line":"  the full potential of Open vSwitch, at the expenses of development"},{"line_number":266,"context_line":"  and operations effort. The development is confined within the"},{"line_number":267,"context_line":"  boundaries of the Neutron community (for both Open vSwitch and Linux"},{"line_number":268,"context_line":"  Bridge) in order to fullfil both vlan awareness and transparency."},{"line_number":269,"context_line":"  Stateful firewall (based on ovs conntrack) limits the adoption for"},{"line_number":270,"context_line":"  DPDK at the time of writing, but a learn-based firewall can be a"},{"line_number":271,"context_line":"  suitable alternative."}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_2d8e7f78","line":268,"in_reply_to":"bab6814e_07f6fa8e","updated":"2016-05-18 18:42:36.000000000","message":"not if we moved away from the way we provide tenant isolation via local vlan provisioning though, right?","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":7448,"name":"Carl Baldwin","email":"carl@ecbaldwin.net","username":"carl-baldwin"},"change_message_id":"6a54ad6399326c0f36ac901792317d37add58e0e","unresolved":false,"context_lines":[{"line_number":265,"context_line":"  the full potential of Open vSwitch, at the expenses of development"},{"line_number":266,"context_line":"  and operations effort. The development is confined within the"},{"line_number":267,"context_line":"  boundaries of the Neutron community (for both Open vSwitch and Linux"},{"line_number":268,"context_line":"  Bridge) in order to fullfil both vlan awareness and transparency."},{"line_number":269,"context_line":"  Stateful firewall (based on ovs conntrack) limits the adoption for"},{"line_number":270,"context_line":"  DPDK at the time of writing, but a learn-based firewall can be a"},{"line_number":271,"context_line":"  suitable alternative."}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_6a9502e3","line":268,"in_reply_to":"bab6814e_18de576d","updated":"2016-05-18 23:25:37.000000000","message":"I think making use of both at the same time (QinQ) should be out of scope.  I haven\u0027t heard any requirement for this and I don\u0027t know of anyone who\u0027s tried to get a VM instance to produce QinQ traffic.  Is it possible?","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"7f03380bff32936266fcc12fa3665a2dd16b0606","unresolved":false,"context_lines":[{"line_number":265,"context_line":"  the full potential of Open vSwitch, at the expenses of development"},{"line_number":266,"context_line":"  and operations effort. The development is confined within the"},{"line_number":267,"context_line":"  boundaries of the Neutron community (for both Open vSwitch and Linux"},{"line_number":268,"context_line":"  Bridge) in order to fullfil both vlan awareness and transparency."},{"line_number":269,"context_line":"  Stateful firewall (based on ovs conntrack) limits the adoption for"},{"line_number":270,"context_line":"  DPDK at the time of writing, but a learn-based firewall can be a"},{"line_number":271,"context_line":"  suitable alternative."}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_8d796bff","line":268,"in_reply_to":"bab6814e_2d8e7f78","updated":"2016-05-18 18:52:31.000000000","message":"No, if we have VLAN transparency running on top of a network tagged to a VM via VLAN awareness, that means there will be nested tags on the traffic coming from the VM.\n\ntag -\u003e tag -\u003epayload\n ^       ^\n |       |----- Tag for vlan transparent traffic on tenant network\n | ---- Tag for vlan aware","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":16800,"name":"Rawlin Peters","email":"rawlin.peters@hpe.com","username":"rawlin"},"change_message_id":"850c79ff17113e3a0af48f8e15902e53d81c489d","unresolved":false,"context_lines":[{"line_number":265,"context_line":"  the full potential of Open vSwitch, at the expenses of development"},{"line_number":266,"context_line":"  and operations effort. The development is confined within the"},{"line_number":267,"context_line":"  boundaries of the Neutron community (for both Open vSwitch and Linux"},{"line_number":268,"context_line":"  Bridge) in order to fullfil both vlan awareness and transparency."},{"line_number":269,"context_line":"  Stateful firewall (based on ovs conntrack) limits the adoption for"},{"line_number":270,"context_line":"  DPDK at the time of writing, but a learn-based firewall can be a"},{"line_number":271,"context_line":"  suitable alternative."}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_cbc04a7f","line":268,"in_reply_to":"bab6814e_6a9502e3","updated":"2016-05-19 15:10:30.000000000","message":"@Carl I tested this out last week. Using an ubuntu image I was able to produce QinQ traffic. With QinQ traffic from the VM (OVS QinQ support wouldn\u0027t be needed), we could probably even support nested vlan subports eventually, at least with the vlan interface implementation. Once you\u0027ve created the first vlan@tap, you create another vlan interface on top of the vlan@tap to further demux the QinQ traffic. Then we could connect to 16777216 (if my math is right) networks using one trunk port! But this would definitely be out-of-scope for this first round :)","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"8d724ee2f9e644c4d708b6a63a1f674ba487e677","unresolved":false,"context_lines":[{"line_number":265,"context_line":"  the full potential of Open vSwitch, at the expenses of development"},{"line_number":266,"context_line":"  and operations effort. The development is confined within the"},{"line_number":267,"context_line":"  boundaries of the Neutron community (for both Open vSwitch and Linux"},{"line_number":268,"context_line":"  Bridge) in order to fullfil both vlan awareness and transparency."},{"line_number":269,"context_line":"  Stateful firewall (based on ovs conntrack) limits the adoption for"},{"line_number":270,"context_line":"  DPDK at the time of writing, but a learn-based firewall can be a"},{"line_number":271,"context_line":"  suitable alternative."}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_b85c6b26","line":268,"in_reply_to":"bab6814e_8d796bff","updated":"2016-05-18 19:00:21.000000000","message":"sorry I got confused and misread your first comment, discard my previous comment. You were saying: using VLAN transparency in conjunction with VLAN awareness\u0027. I mean fulfil both requirements but separately. I\u0027ll rephrase","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"65641a872730e8a7864412c65b6e2e8d8f471703","unresolved":false,"context_lines":[{"line_number":265,"context_line":"  the full potential of Open vSwitch, at the expenses of development"},{"line_number":266,"context_line":"  and operations effort. The development is confined within the"},{"line_number":267,"context_line":"  boundaries of the Neutron community (for both Open vSwitch and Linux"},{"line_number":268,"context_line":"  Bridge) in order to fullfil both vlan awareness and transparency."},{"line_number":269,"context_line":"  Stateful firewall (based on ovs conntrack) limits the adoption for"},{"line_number":270,"context_line":"  DPDK at the time of writing, but a learn-based firewall can be a"},{"line_number":271,"context_line":"  suitable alternative."}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_18de576d","line":268,"in_reply_to":"bab6814e_b85c6b26","updated":"2016-05-18 19:01:43.000000000","message":"oh, makes sense.","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"47e9968dc2a8f1db5bda411c127be84bbb7fc855","unresolved":false,"context_lines":[{"line_number":268,"context_line":"  Bridge) in order to fullfil both vlan awareness and transparency."},{"line_number":269,"context_line":"  Stateful firewall (based on ovs conntrack) limits the adoption for"},{"line_number":270,"context_line":"  DPDK at the time of writing, but a learn-based firewall can be a"},{"line_number":271,"context_line":"  suitable alternative."},{"line_number":272,"context_line":""},{"line_number":273,"context_line":"* Trunk Bridges (C) tries to bring the best of option A and B together"},{"line_number":274,"context_line":"  as far as OVS development and performance are concerned, but it"}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_67f3869f","line":271,"updated":"2016-05-18 18:03:04.000000000","message":"Additionally, the Open Flow firewall driver will not be useable in many distros released today due to the high kernel-version requirements and OVS version requirements.","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"a22f348b3d1e04c772df30d7cb421b4f86cbad06","unresolved":false,"context_lines":[{"line_number":268,"context_line":"  Bridge) in order to fullfil both vlan awareness and transparency."},{"line_number":269,"context_line":"  Stateful firewall (based on ovs conntrack) limits the adoption for"},{"line_number":270,"context_line":"  DPDK at the time of writing, but a learn-based firewall can be a"},{"line_number":271,"context_line":"  suitable alternative."},{"line_number":272,"context_line":""},{"line_number":273,"context_line":"* Trunk Bridges (C) tries to bring the best of option A and B together"},{"line_number":274,"context_line":"  as far as OVS development and performance are concerned, but it"}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_cdca53a1","line":271,"in_reply_to":"bab6814e_67f3869f","updated":"2016-05-18 18:42:36.000000000","message":"I suppose that\u0027s a problem we\u0027d have any time we are on the bleeding edge.","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"7f03380bff32936266fcc12fa3665a2dd16b0606","unresolved":false,"context_lines":[{"line_number":268,"context_line":"  Bridge) in order to fullfil both vlan awareness and transparency."},{"line_number":269,"context_line":"  Stateful firewall (based on ovs conntrack) limits the adoption for"},{"line_number":270,"context_line":"  DPDK at the time of writing, but a learn-based firewall can be a"},{"line_number":271,"context_line":"  suitable alternative."},{"line_number":272,"context_line":""},{"line_number":273,"context_line":"* Trunk Bridges (C) tries to bring the best of option A and B together"},{"line_number":274,"context_line":"  as far as OVS development and performance are concerned, but it"}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_0ddc5be3","line":271,"in_reply_to":"bab6814e_cdca53a1","updated":"2016-05-18 18:52:31.000000000","message":"True, just that\u0027s in contrast to the kernel VLAN interfaces that have been present for a long time.","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"47e9968dc2a8f1db5bda411c127be84bbb7fc855","unresolved":false,"context_lines":[{"line_number":276,"context_line":"  and it would still require a Linux Bridge solution, as well as OVS vlan"},{"line_number":277,"context_line":"  transparency support."},{"line_number":278,"context_line":""},{"line_number":279,"context_line":"All things considered, as far as OVS is concerned, option (C) is the most"},{"line_number":280,"context_line":"promising in the medium term. Management of trunks and ports within trunks"},{"line_number":281,"context_line":"will have to be managed differently and, to start with, it is sensible to"},{"line_number":282,"context_line":"restrict the ability to update ports (i.e. convert) once they are bound to"}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_47f00291","line":279,"updated":"2016-05-18 18:03:04.000000000","message":"Option C will have an annoying requirement of declaring trunk ports before the\nVM is booted.\n\nI would rather we just go right for option B since it has the same OVS firewall requirement as C. But that\u0027s just my opinion.","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"d19905e09baae2208f039a2afb4f6ac1c2419303","unresolved":false,"context_lines":[{"line_number":276,"context_line":"  and it would still require a Linux Bridge solution, as well as OVS vlan"},{"line_number":277,"context_line":"  transparency support."},{"line_number":278,"context_line":""},{"line_number":279,"context_line":"All things considered, as far as OVS is concerned, option (C) is the most"},{"line_number":280,"context_line":"promising in the medium term. Management of trunks and ports within trunks"},{"line_number":281,"context_line":"will have to be managed differently and, to start with, it is sensible to"},{"line_number":282,"context_line":"restrict the ability to update ports (i.e. convert) once they are bound to"}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_b2464a21","line":279,"in_reply_to":"bab6814e_47f00291","updated":"2016-05-18 18:21:12.000000000","message":"It is a little annoying to have to first declare the trunk port explicitly, but all things considered it\u0027s at least a workable solution. SR-IOV initially came with the same baggage. I\u0027ve always seen it as quirky, but nothing that would cause me too much heartburn.\n\nOption B is my preferred end state as well, but can we get there in less than 2 cycles? Consider me a skeptic.","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"a22f348b3d1e04c772df30d7cb421b4f86cbad06","unresolved":false,"context_lines":[{"line_number":276,"context_line":"  and it would still require a Linux Bridge solution, as well as OVS vlan"},{"line_number":277,"context_line":"  transparency support."},{"line_number":278,"context_line":""},{"line_number":279,"context_line":"All things considered, as far as OVS is concerned, option (C) is the most"},{"line_number":280,"context_line":"promising in the medium term. Management of trunks and ports within trunks"},{"line_number":281,"context_line":"will have to be managed differently and, to start with, it is sensible to"},{"line_number":282,"context_line":"restrict the ability to update ports (i.e. convert) once they are bound to"}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_ad5d4feb","line":279,"in_reply_to":"bab6814e_47f00291","updated":"2016-05-18 18:42:36.000000000","message":"True, even though one could argue that an appliance booting might not be operational until the trunk is up and running.","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"7f03380bff32936266fcc12fa3665a2dd16b0606","unresolved":false,"context_lines":[{"line_number":276,"context_line":"  and it would still require a Linux Bridge solution, as well as OVS vlan"},{"line_number":277,"context_line":"  transparency support."},{"line_number":278,"context_line":""},{"line_number":279,"context_line":"All things considered, as far as OVS is concerned, option (C) is the most"},{"line_number":280,"context_line":"promising in the medium term. Management of trunks and ports within trunks"},{"line_number":281,"context_line":"will have to be managed differently and, to start with, it is sensible to"},{"line_number":282,"context_line":"restrict the ability to update ports (i.e. convert) once they are bound to"}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_cd9ff301","line":279,"in_reply_to":"bab6814e_b2464a21","updated":"2016-05-18 18:52:31.000000000","message":"Option C will create tech debt that will make it harder to get to B because it introduces a bunch of new logic in the OVS agent specific to the new bridges that won\u0027t be related to C\u0027s logic. So then when C comes along, it needs to handle VMs wired up with the bridge one as well.","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"8d724ee2f9e644c4d708b6a63a1f674ba487e677","unresolved":false,"context_lines":[{"line_number":276,"context_line":"  and it would still require a Linux Bridge solution, as well as OVS vlan"},{"line_number":277,"context_line":"  transparency support."},{"line_number":278,"context_line":""},{"line_number":279,"context_line":"All things considered, as far as OVS is concerned, option (C) is the most"},{"line_number":280,"context_line":"promising in the medium term. Management of trunks and ports within trunks"},{"line_number":281,"context_line":"will have to be managed differently and, to start with, it is sensible to"},{"line_number":282,"context_line":"restrict the ability to update ports (i.e. convert) once they are bound to"}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_98824751","line":279,"in_reply_to":"bab6814e_cd9ff301","updated":"2016-05-18 19:00:21.000000000","message":"That\u0027s the point I am making in 294, I think. Though Option B might not be attainable in the span of the time we got left for Newton, and even though I agree with your points, there\u0027s enough unknowns in Option B at this point that I am being reluctant to endorse it just yet.","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":7787,"name":"Kevin Benton","email":"kevin@benton.pub","username":"blak111"},"change_message_id":"47e9968dc2a8f1db5bda411c127be84bbb7fc855","unresolved":false,"context_lines":[{"line_number":291,"context_line":"plane performance improvement is hindered by the extra use of kernel resources,"},{"line_number":292,"context_line":"this option is not at all appealing in the long term."},{"line_number":293,"context_line":""},{"line_number":294,"context_line":"Embracing option (B) in the long run may be complicated by the adoption of"},{"line_number":295,"context_line":"option (C). The development and maintainance complexity involved in Option"},{"line_number":296,"context_line":"(C) and (B) respectively poses the existential question as to whether"},{"line_number":297,"context_line":"investing in the agent-based architecture is an effective strategy,"}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_a72baeea","line":294,"updated":"2016-05-18 18:03:04.000000000","message":"So skip option C","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"a22f348b3d1e04c772df30d7cb421b4f86cbad06","unresolved":false,"context_lines":[{"line_number":291,"context_line":"plane performance improvement is hindered by the extra use of kernel resources,"},{"line_number":292,"context_line":"this option is not at all appealing in the long term."},{"line_number":293,"context_line":""},{"line_number":294,"context_line":"Embracing option (B) in the long run may be complicated by the adoption of"},{"line_number":295,"context_line":"option (C). The development and maintainance complexity involved in Option"},{"line_number":296,"context_line":"(C) and (B) respectively poses the existential question as to whether"},{"line_number":297,"context_line":"investing in the agent-based architecture is an effective strategy,"}],"source_content_type":"text/x-rst","patch_set":10,"id":"bab6814e_4d6dc397","line":294,"in_reply_to":"bab6814e_a72baeea","updated":"2016-05-18 18:42:36.000000000","message":"if it were that simple!","commit_id":"da9cfed5c79fccd97ecfad2ffc9473222ad1861d"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e1ff99bb86ffa19b88bba53ff7d45ecd685c84eb","unresolved":false,"context_lines":[{"line_number":221,"context_line":"  the first option, in that an extra layer of mux/demux is introduced"},{"line_number":222,"context_line":"  between the VM and the integration bridge (br-int) but instead of"},{"line_number":223,"context_line":"  using vlan interfaces, a combination of a new OVS bridge (trunk"},{"line_number":224,"context_line":"  bridge or br-trunk) and patch ports to wire this new bridge with"},{"line_number":225,"context_line":"  br-int will be used. This solution has the following design"},{"line_number":226,"context_line":"  implications:"},{"line_number":227,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"bab6814e_cda3b0b0","line":224,"range":{"start_line":224,"start_character":12,"end_line":224,"end_character":20},"updated":"2016-05-23 16:52:12.000000000","message":"i think port\u003cuuid\u003e would be better here as it one brige per vm interface not one bridge for all trunk ports to share","commit_id":"af74d818374c8b3b58d201cc447e361797bb7ba6"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"46ab9e476f9cc075cb6f016e703791a7f4daecb6","unresolved":false,"context_lines":[{"line_number":221,"context_line":"  the first option, in that an extra layer of mux/demux is introduced"},{"line_number":222,"context_line":"  between the VM and the integration bridge (br-int) but instead of"},{"line_number":223,"context_line":"  using vlan interfaces, a combination of a new OVS bridge (trunk"},{"line_number":224,"context_line":"  bridge or br-trunk) and patch ports to wire this new bridge with"},{"line_number":225,"context_line":"  br-int will be used. This solution has the following design"},{"line_number":226,"context_line":"  implications:"},{"line_number":227,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"bab6814e_98b527d2","line":224,"range":{"start_line":224,"start_character":12,"end_line":224,"end_character":20},"in_reply_to":"bab6814e_cda3b0b0","updated":"2016-05-24 16:07:14.000000000","message":"agreed, this is simply mnemonic. Line 220 clearly states: per trunk port OVS bridge.","commit_id":"af74d818374c8b3b58d201cc447e361797bb7ba6"},{"author":{"_account_id":16800,"name":"Rawlin Peters","email":"rawlin.peters@hpe.com","username":"rawlin"},"change_message_id":"46837dea066e434c5812de264dc032eae7bcf981","unresolved":false,"context_lines":[{"line_number":266,"context_line":"* Open Flow (B) is compelling because it will allow Neutron to unlock"},{"line_number":267,"context_line":"  the full potential of Open vSwitch, at the expenses of development"},{"line_number":268,"context_line":"  and operations effort. The development is confined within the"},{"line_number":269,"context_line":"  boundaries of the Neutron community in order to fullfil vlan awareness"},{"line_number":270,"context_line":"  and transparency (as two distinct use cases, ie. to be adopted"},{"line_number":271,"context_line":"  separately)."},{"line_number":272,"context_line":"  Stateful firewall (based on ovs conntrack) limits the adoption for"}],"source_content_type":"text/x-rst","patch_set":11,"id":"bab6814e_c9f3ab71","line":269,"range":{"start_line":269,"start_character":50,"end_line":269,"end_character":57},"updated":"2016-05-23 15:01:14.000000000","message":"sp: fulfill","commit_id":"af74d818374c8b3b58d201cc447e361797bb7ba6"},{"author":{"_account_id":748,"name":"Armando Migliaccio","email":"armamig@gmail.com","username":"armando-migliaccio"},"change_message_id":"07620d38456adabbe2ab51660625598dd5767d68","unresolved":false,"context_lines":[{"line_number":266,"context_line":"* Open Flow (B) is compelling because it will allow Neutron to unlock"},{"line_number":267,"context_line":"  the full potential of Open vSwitch, at the expenses of development"},{"line_number":268,"context_line":"  and operations effort. The development is confined within the"},{"line_number":269,"context_line":"  boundaries of the Neutron community in order to fullfil vlan awareness"},{"line_number":270,"context_line":"  and transparency (as two distinct use cases, ie. to be adopted"},{"line_number":271,"context_line":"  separately)."},{"line_number":272,"context_line":"  Stateful firewall (based on ovs conntrack) limits the adoption for"}],"source_content_type":"text/x-rst","patch_set":11,"id":"bab6814e_98dc071a","line":269,"range":{"start_line":269,"start_character":50,"end_line":269,"end_character":57},"in_reply_to":"bab6814e_c9f3ab71","updated":"2016-05-24 16:07:33.000000000","message":"argh","commit_id":"af74d818374c8b3b58d201cc447e361797bb7ba6"},{"author":{"_account_id":16800,"name":"Rawlin Peters","email":"rawlin.peters@hpe.com","username":"rawlin"},"change_message_id":"90927d2feb3affc30d337ebd681db53434e3c33f","unresolved":false,"context_lines":[{"line_number":151,"context_line":"  platform\u0027s point of view discerning which tagged packets are meant"},{"line_number":152,"context_line":"  to be treated \u0027transparently\u0027 and which ones are meant to be used"},{"line_number":153,"context_line":"  for demultiplexing (in order to reach the right destination)."},{"line_number":154,"context_line":"  The outcome might only be predicatble if two layers of vlan tags"},{"line_number":155,"context_line":"  are stacked up together, making guest support even more crucial"},{"line_number":156,"context_line":"  for the combined use case."},{"line_number":157,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"9abb7d3a_97f6a3d5","line":154,"range":{"start_line":154,"start_character":28,"end_line":154,"end_character":39},"updated":"2016-05-27 21:49:00.000000000","message":"sp","commit_id":"3088e93097770fcc67e64a0f0090b18be474f644"},{"author":{"_account_id":16800,"name":"Rawlin Peters","email":"rawlin.peters@hpe.com","username":"rawlin"},"change_message_id":"90927d2feb3affc30d337ebd681db53434e3c33f","unresolved":false,"context_lines":[{"line_number":167,"context_line":"  (credit to Rawlin Peters). This solution has the following design"},{"line_number":168,"context_line":"  implications:"},{"line_number":169,"context_line":""},{"line_number":170,"context_line":"  * Design complexity: this requires relative small changes"},{"line_number":171,"context_line":"    to the existing OVS design, and it can work with both"},{"line_number":172,"context_line":"    iptables and native ovs security rules."},{"line_number":173,"context_line":"  * Upgrade complexity: in order to employ this solution"}],"source_content_type":"text/x-rst","patch_set":12,"id":"9abb7d3a_173113a3","line":170,"range":{"start_line":170,"start_character":37,"end_line":170,"end_character":45},"updated":"2016-05-27 21:49:00.000000000","message":"relatively","commit_id":"3088e93097770fcc67e64a0f0090b18be474f644"},{"author":{"_account_id":11907,"name":"cathy","email":"cathy.h.zhang@huawei.com","username":"cathy"},"change_message_id":"dd36c6b54b9d00d9ee34a0f662e9e8c87fb938a8","unresolved":false,"context_lines":[{"line_number":220,"context_line":"* Per trunk port OVS bridge: in layman\u0027s terms, this is similar to"},{"line_number":221,"context_line":"  the first option, in that an extra layer of mux/demux is introduced"},{"line_number":222,"context_line":"  between the VM and the integration bridge (br-int) but instead of"},{"line_number":223,"context_line":"  using vlan interfaces, a combination of a new per port OVS bridge"},{"line_number":224,"context_line":"  and patch ports to wire this new bridge with br-int will be used."},{"line_number":225,"context_line":"  This solution has the following design implications:"},{"line_number":226,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"bab6814e_5759be5a","line":223,"updated":"2016-05-26 19:35:19.000000000","message":"What is meant by \"per port OVS bridge\"? Is it \"per trunk port OVS bridge\", which means an OVS trunk bridge is created for each trunk port between the VM and br-int?","commit_id":"3088e93097770fcc67e64a0f0090b18be474f644"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"62ba88823d92b86c7b3b7516ea7a86f12ce459e5","unresolved":false,"context_lines":[{"line_number":220,"context_line":"* Per trunk port OVS bridge: in layman\u0027s terms, this is similar to"},{"line_number":221,"context_line":"  the first option, in that an extra layer of mux/demux is introduced"},{"line_number":222,"context_line":"  between the VM and the integration bridge (br-int) but instead of"},{"line_number":223,"context_line":"  using vlan interfaces, a combination of a new per port OVS bridge"},{"line_number":224,"context_line":"  and patch ports to wire this new bridge with br-int will be used."},{"line_number":225,"context_line":"  This solution has the following design implications:"},{"line_number":226,"context_line":""}],"source_content_type":"text/x-rst","patch_set":12,"id":"bab6814e_98de3d3c","line":223,"in_reply_to":"bab6814e_5759be5a","updated":"2016-05-26 20:53:14.000000000","message":"it one bridge per trunk port/parent port.\n\nor said another way you have one bridge per vm interface.\n\nfor each subport in the trunk you have a patch port between the trunk port bridge and the br-int.\n\nso if a vm had 2 interfaces both of which were trunk ports with 3 sub ports each this would translate\nto two independent trunk bridges which will be conneted to the br-int via patch ports.","commit_id":"3088e93097770fcc67e64a0f0090b18be474f644"},{"author":{"_account_id":11313,"name":"Louis Fourie","email":"fouriehl70@gmail.com","username":"lfourie"},"change_message_id":"ec254f444bbe69619f6cd56806ecf4bf650dcf12","unresolved":false,"context_lines":[{"line_number":273,"context_line":"  suitable alternative. Obviously this solution is not compliant with"},{"line_number":274,"context_line":"  iptables firewall."},{"line_number":275,"context_line":""},{"line_number":276,"context_line":"* Trunk Bridges (C) tries to bring the best of option A and B together"},{"line_number":277,"context_line":"  as far as OVS development and performance are concerned, but it"},{"line_number":278,"context_line":"  comes at the expenses of maintainance complexity and loss of flexibility."},{"line_number":279,"context_line":"  A Linux Bridge solution would still be required and, QinQ support will"}],"source_content_type":"text/x-rst","patch_set":12,"id":"9abb7d3a_d7f3fe08","line":276,"range":{"start_line":276,"start_character":2,"end_line":276,"end_character":15},"updated":"2016-05-28 17:27:57.000000000","message":"Add a diagram to clarify br-trunk, br-int, etc. interconnect","commit_id":"3088e93097770fcc67e64a0f0090b18be474f644"},{"author":{"_account_id":16800,"name":"Rawlin Peters","email":"rawlin.peters@hpe.com","username":"rawlin"},"change_message_id":"ce4b3c2a4760eab261714128747f7ab63f8428c1","unresolved":false,"context_lines":[{"line_number":273,"context_line":"  suitable alternative. Obviously this solution is not compliant with"},{"line_number":274,"context_line":"  iptables firewall."},{"line_number":275,"context_line":""},{"line_number":276,"context_line":"* Trunk Bridges (C) tries to bring the best of option A and B together"},{"line_number":277,"context_line":"  as far as OVS development and performance are concerned, but it"},{"line_number":278,"context_line":"  comes at the expenses of maintainance complexity and loss of flexibility."},{"line_number":279,"context_line":"  A Linux Bridge solution would still be required and, QinQ support will"}],"source_content_type":"text/x-rst","patch_set":12,"id":"9abb7d3a_fb7e8368","line":276,"range":{"start_line":276,"start_character":2,"end_line":276,"end_character":15},"in_reply_to":"9abb7d3a_d7f3fe08","updated":"2016-05-31 16:46:04.000000000","message":"The follow-on patch - https://review.openstack.org/318317 - has a couple diagrams.","commit_id":"3088e93097770fcc67e64a0f0090b18be474f644"},{"author":{"_account_id":11907,"name":"cathy","email":"cathy.h.zhang@huawei.com","username":"cathy"},"change_message_id":"dd36c6b54b9d00d9ee34a0f662e9e8c87fb938a8","unresolved":false,"context_lines":[{"line_number":284,"context_line":"will have to be managed differently and, to start with, it is sensible to"},{"line_number":285,"context_line":"restrict the ability to update ports (i.e. convert) once they are bound to"},{"line_number":286,"context_line":"a particular bridge (integration vs trunk). Security rules via iptables"},{"line_number":287,"context_line":"rules is obviously not supported, and never will be."},{"line_number":288,"context_line":""},{"line_number":289,"context_line":"Option (A) for OVS could be pursued in conjunction with Linux Bridge support,"},{"line_number":290,"context_line":"if the effort is seen particularly low hanging fruit."}],"source_content_type":"text/x-rst","patch_set":12,"id":"bab6814e_82af66e2","line":287,"updated":"2016-05-26 19:35:19.000000000","message":"Is option (C) being chosen?","commit_id":"3088e93097770fcc67e64a0f0090b18be474f644"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"ab3e31c2da50c39b75aa98c2bdbdacf6491f83b0","unresolved":false,"context_lines":[{"line_number":284,"context_line":"will have to be managed differently and, to start with, it is sensible to"},{"line_number":285,"context_line":"restrict the ability to update ports (i.e. convert) once they are bound to"},{"line_number":286,"context_line":"a particular bridge (integration vs trunk). Security rules via iptables"},{"line_number":287,"context_line":"rules is obviously not supported, and never will be."},{"line_number":288,"context_line":""},{"line_number":289,"context_line":"Option (A) for OVS could be pursued in conjunction with Linux Bridge support,"},{"line_number":290,"context_line":"if the effort is seen particularly low hanging fruit."}],"source_content_type":"text/x-rst","patch_set":12,"id":"7aa08908_93b2de04","line":287,"in_reply_to":"bab6814e_82af66e2","updated":"2016-06-07 16:30:48.000000000","message":"I believe so. We should be clear on this point, although maybe the devref is not the right forum to communicate that?","commit_id":"3088e93097770fcc67e64a0f0090b18be474f644"},{"author":{"_account_id":8655,"name":"Jakub Libosvar","email":"libosvar@redhat.com","username":"jlibosva"},"change_message_id":"dd535065de360706c46f999a0976fcc09f91b03a","unresolved":false,"context_lines":[{"line_number":289,"context_line":"Option (A) for OVS could be pursued in conjunction with Linux Bridge support,"},{"line_number":290,"context_line":"if the effort is seen particularly low hanging fruit."},{"line_number":291,"context_line":"However, a working solution based on this option positions the OVS agent as"},{"line_number":292,"context_line":"a sub-optminal platform for performance sensitive applications in comparison"},{"line_number":293,"context_line":"to other accelerated or SDN-controller based solutions. Since further data"},{"line_number":294,"context_line":"plane performance improvement is hindered by the extra use of kernel resources,"},{"line_number":295,"context_line":"this option is not at all appealing in the long term."}],"source_content_type":"text/x-rst","patch_set":12,"id":"9abb7d3a_0983ddcd","line":292,"range":{"start_line":292,"start_character":6,"end_line":292,"end_character":14},"updated":"2016-06-17 10:11:02.000000000","message":"optimal?","commit_id":"3088e93097770fcc67e64a0f0090b18be474f644"}]}