)]}'
{"specs/train/dvr-enhancements.rst":[{"author":{"_account_id":9531,"name":"liuyulong","display_name":"LIU Yulong","email":"i@liuyulong.me","username":"LIU-Yulong"},"change_message_id":"6d315ecfa789793fa65b64d918d6e5b6451afd18","unresolved":false,"context_lines":[{"line_number":59,"context_line":"    it via OpenFlow."},{"line_number":60,"context_line":"  * There is an existing blueprint for this, see [2]"},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"* Distributed DHCP"},{"line_number":63,"context_line":"  * Rather than having DHCP for a given network be answered centrally, OpenFlow"},{"line_number":64,"context_line":"    rules will be programmed into OVS to provide static, locally generated"},{"line_number":65,"context_line":"    responses to DHCP requests received on br-int."}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_3cdab74b","line":62,"range":{"start_line":62,"start_character":2,"end_line":62,"end_character":18},"updated":"2019-05-13 04:36:27.000000000","message":"Problem: some functions like DNS based on current DHCP dnsmasq [1] will not be available?\n\n[1] https://docs.openstack.org/neutron/latest/admin/config-dns-res.html","commit_id":"2973b5129f5ad1e7ccee2cd00048545084d922e6"},{"author":{"_account_id":9531,"name":"liuyulong","display_name":"LIU Yulong","email":"i@liuyulong.me","username":"LIU-Yulong"},"change_message_id":"8b8608d32816e19ae3d5e4a2d40343a21fcaf569","unresolved":false,"context_lines":[{"line_number":59,"context_line":"    it via OpenFlow."},{"line_number":60,"context_line":"  * There is an existing blueprint for this, see [2]"},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"* Distributed DHCP"},{"line_number":63,"context_line":"  * Rather than having DHCP for a given network be answered centrally, OpenFlow"},{"line_number":64,"context_line":"    rules will be programmed into OVS to provide static, locally generated"},{"line_number":65,"context_line":"    responses to DHCP requests received on br-int."}],"source_content_type":"text/x-rst","patch_set":1,"id":"bfb3d3c7_e69b1415","line":62,"range":{"start_line":62,"start_character":2,"end_line":62,"end_character":18},"in_reply_to":"bfb3d3c7_1f75c995","updated":"2019-05-28 15:21:16.000000000","message":"I think, we should evaluate a bearable port quantity for one single ovs-agent. For instance, if a ovs-agent clould host 1000 ports (as far as I\u0027m concerned it can\u0027t now), then its RPC, restart time, restart success rate, flow recovery are all at very high success rate, 99%?","commit_id":"2973b5129f5ad1e7ccee2cd00048545084d922e6"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"a8e9e34d0ae043451dd7465f6651161d3f484e4f","unresolved":false,"context_lines":[{"line_number":59,"context_line":"    it via OpenFlow."},{"line_number":60,"context_line":"  * There is an existing blueprint for this, see [2]"},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"* Distributed DHCP"},{"line_number":63,"context_line":"  * Rather than having DHCP for a given network be answered centrally, OpenFlow"},{"line_number":64,"context_line":"    rules will be programmed into OVS to provide static, locally generated"},{"line_number":65,"context_line":"    responses to DHCP requests received on br-int."}],"source_content_type":"text/x-rst","patch_set":1,"id":"bfb3d3c7_1f75c995","line":62,"range":{"start_line":62,"start_character":2,"end_line":62,"end_character":18},"in_reply_to":"bfb3d3c7_d04c0578","updated":"2019-05-20 21:10:03.000000000","message":"Yes, there are definitely scale issues with the OVS agent and we don\u0027t want to overburden it. My thinking is that this shouldn\u0027t require an extra RPC call, all the information needed will be included in the response from the call to get_device_details(). At a minimum it takes the RPC round-trip to obtain the relevant information out of the mix. Of course there are issues processing large numbers of ports outside of the RPC context, so adding another call to OVS for each port is a valid concern.","commit_id":"2973b5129f5ad1e7ccee2cd00048545084d922e6"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"ccb972d9ac18a8bc5dff9e6c6eab9985c35fc7d1","unresolved":false,"context_lines":[{"line_number":59,"context_line":"    it via OpenFlow."},{"line_number":60,"context_line":"  * There is an existing blueprint for this, see [2]"},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"* Distributed DHCP"},{"line_number":63,"context_line":"  * Rather than having DHCP for a given network be answered centrally, OpenFlow"},{"line_number":64,"context_line":"    rules will be programmed into OVS to provide static, locally generated"},{"line_number":65,"context_line":"    responses to DHCP requests received on br-int."}],"source_content_type":"text/x-rst","patch_set":1,"id":"bfb3d3c7_aca73d0b","line":62,"range":{"start_line":62,"start_character":2,"end_line":62,"end_character":18},"in_reply_to":"bfb3d3c7_e69b1415","updated":"2019-05-28 16:03:25.000000000","message":"I like this idea. In the past we seem to have simply measured the number of ports that can be serviced in aggregate across a region and how many compute nodes can be run, but even that isn\u0027t well documented. I think we can do a better job providing scale numbers, and this is a multi-faceted thing. I have a performance section in the latest patch set that is just a placeholder, we should capture what the current limits are there and compare with OVN.","commit_id":"2973b5129f5ad1e7ccee2cd00048545084d922e6"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"a54538004ba6aed91a51da6f870042d512c4d455","unresolved":false,"context_lines":[{"line_number":59,"context_line":"    it via OpenFlow."},{"line_number":60,"context_line":"  * There is an existing blueprint for this, see [2]"},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"* Distributed DHCP"},{"line_number":63,"context_line":"  * Rather than having DHCP for a given network be answered centrally, OpenFlow"},{"line_number":64,"context_line":"    rules will be programmed into OVS to provide static, locally generated"},{"line_number":65,"context_line":"    responses to DHCP requests received on br-int."}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_bcf8e77a","line":62,"range":{"start_line":62,"start_character":2,"end_line":62,"end_character":18},"in_reply_to":"dfbec78f_3cdab74b","updated":"2019-05-13 05:12:16.000000000","message":"That is a good point, we would need to consider how to provide the DNS functionality of dnsmasq somehow. Maybe it\u0027s easier to simply run dnsmaq locally and steer DHCP and DNS appropriately to a namespace? One of the overarching goals for me is to consolidate the number of agents that need to be run and monitored on any given node, pushing as much as possible into OVS. The DHCP agent seems like a prime candidate for consolidation, but maybe this is just not feasible. Nothing is ever really agentless, but fewer agents is simpler to operate and is a noble goal IMO.","commit_id":"2973b5129f5ad1e7ccee2cd00048545084d922e6"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"0d2d2c593df7ea5073e15ebb8df8cd8c30d7a0ff","unresolved":false,"context_lines":[{"line_number":59,"context_line":"    it via OpenFlow."},{"line_number":60,"context_line":"  * There is an existing blueprint for this, see [2]"},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"* Distributed DHCP"},{"line_number":63,"context_line":"  * Rather than having DHCP for a given network be answered centrally, OpenFlow"},{"line_number":64,"context_line":"    rules will be programmed into OVS to provide static, locally generated"},{"line_number":65,"context_line":"    responses to DHCP requests received on br-int."}],"source_content_type":"text/x-rst","patch_set":1,"id":"bfb3d3c7_d04c0578","line":62,"range":{"start_line":62,"start_character":2,"end_line":62,"end_character":18},"in_reply_to":"dfbec78f_bcf8e77a","updated":"2019-05-20 20:15:03.000000000","message":"Yes, but please keep in mind that ovs agent in current state is already not scale well. So giving him more and more work to do may kill it ;)","commit_id":"2973b5129f5ad1e7ccee2cd00048545084d922e6"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"0d2d2c593df7ea5073e15ebb8df8cd8c30d7a0ff","unresolved":false,"context_lines":[{"line_number":69,"context_line":"    fixed IP address, network segment, etc.). Making this the responsibility of"},{"line_number":70,"context_line":"    the OVS agent makes the DHCP agent optional when using ML2+OVS, not just"},{"line_number":71,"context_line":"    when DVR is in use."},{"line_number":72,"context_line":"  * Flesh out details here....."},{"line_number":73,"context_line":"  * OVN provides an example of this in action [3]"},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"* Distributed SNAT"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bfb3d3c7_d09ac5c3","line":72,"range":{"start_line":72,"start_character":0,"end_line":72,"end_character":31},"updated":"2019-05-20 20:15:03.000000000","message":"?? :)","commit_id":"2973b5129f5ad1e7ccee2cd00048545084d922e6"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"a8e9e34d0ae043451dd7465f6651161d3f484e4f","unresolved":false,"context_lines":[{"line_number":69,"context_line":"    fixed IP address, network segment, etc.). Making this the responsibility of"},{"line_number":70,"context_line":"    the OVS agent makes the DHCP agent optional when using ML2+OVS, not just"},{"line_number":71,"context_line":"    when DVR is in use."},{"line_number":72,"context_line":"  * Flesh out details here....."},{"line_number":73,"context_line":"  * OVN provides an example of this in action [3]"},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"* Distributed SNAT"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bfb3d3c7_7f63a5dd","line":72,"range":{"start_line":72,"start_character":0,"end_line":72,"end_character":31},"in_reply_to":"bfb3d3c7_d09ac5c3","updated":"2019-05-20 21:10:03.000000000","message":"New patch set coming soon :)","commit_id":"2973b5129f5ad1e7ccee2cd00048545084d922e6"},{"author":{"_account_id":9531,"name":"liuyulong","display_name":"LIU Yulong","email":"i@liuyulong.me","username":"LIU-Yulong"},"change_message_id":"6d315ecfa789793fa65b64d918d6e5b6451afd18","unresolved":false,"context_lines":[{"line_number":72,"context_line":"  * Flesh out details here....."},{"line_number":73,"context_line":"  * OVN provides an example of this in action [3]"},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"* Distributed SNAT"},{"line_number":76,"context_line":"  * This involves allowing SNAT to happen directly on the compute node instead"},{"line_number":77,"context_line":"    of centralizing it on a network node."},{"line_number":78,"context_line":"  * To provide proper tenant isolation when using the namespace-based"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_bc72277a","line":75,"range":{"start_line":75,"start_character":2,"end_line":75,"end_character":18},"updated":"2019-05-13 04:36:27.000000000","message":"This is really a good proposal. But it may face some new problem, and I do not see any discuss in the previous context (maybe have discussed somewhere I just not see).\n1. How to limit such distributed SNAT traffic? One router can spread to many compute hosts, then the SNAT functionality will work on it. Each router will have unlimited SNAT total bandwidth, since it is totally distributed. This can be a disaster when the users\u0027 VMs are hijacked, in a large public cloud, this can happen.\n2. It will share the physical external device (we can not afford a new NIC for SNAT only, it costs too much), so it will have influence on floating IP traffic?\n3. It will increase the operation difficulty?\n\nSome concern that may arise in real production use, but do not hinder the advantages of this proposal.","commit_id":"2973b5129f5ad1e7ccee2cd00048545084d922e6"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"a54538004ba6aed91a51da6f870042d512c4d455","unresolved":false,"context_lines":[{"line_number":72,"context_line":"  * Flesh out details here....."},{"line_number":73,"context_line":"  * OVN provides an example of this in action [3]"},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"* Distributed SNAT"},{"line_number":76,"context_line":"  * This involves allowing SNAT to happen directly on the compute node instead"},{"line_number":77,"context_line":"    of centralizing it on a network node."},{"line_number":78,"context_line":"  * To provide proper tenant isolation when using the namespace-based"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_fcec1f90","line":75,"range":{"start_line":75,"start_character":2,"end_line":75,"end_character":18},"in_reply_to":"dfbec78f_bc72277a","updated":"2019-05-13 05:12:16.000000000","message":"I have talked to operators who love and hate this idea, and each have their own unique reasons. My proposal is provide the option for distributed SNAT, understanding that this isn\u0027t a one-size-fits-all solution.\n\n1. This is a tricky problem, although it\u0027s one that exists when VM\u0027s with floating IP\u0027s get hijacked so I don\u0027t see it as a show-stopper for developing or deploying distributed SNAT. My thought is to make this something operators opt in to, so it\u0027s not forced on them.\n\n2. Yes, SNAT would share the same external device as floating IP traffic. Ultimately in many deployments FIP, SNAT, and directly routable traffic is all funneled through the same top-of-rack gear and physical devices. The question is whether it is encapsulated in the overlay or not upon cloud ingress/egress. I don\u0027t see this as a blocker to deployments, it\u0027s just something to be aware of and consider developing QoS-like knobs for operators.\n\n3. In what ways are you thinking this is more difficult to operate? That\u0027s a very subjective thing that depends on the environment. One thing I can think of that becomes more difficult when you distribute services like this is IDS/IPS, you simply have more points to worry about inspecting traffic. I\u0027ve been a part of compliance reviews where this is a concern but nothing was a show-stopper. Perhaps extending tap-as-a-service or something similar would help some segment of operators?","commit_id":"2973b5129f5ad1e7ccee2cd00048545084d922e6"},{"author":{"_account_id":7016,"name":"Swaminathan Vasudevan","email":"swvasude@cisco.com","username":"souminathan"},"change_message_id":"535c9969e4fc5b514f2ffe4fc58c7cc793a4058a","unresolved":false,"context_lines":[{"line_number":80,"context_line":"    (Insert diagram and explain in detail here)"},{"line_number":81,"context_line":"  * Open questions:"},{"line_number":82,"context_line":"    * Should SNAT traffic use the FIP gateway IP as the source address, or"},{"line_number":83,"context_line":"      should it use an IP address specific to the tenant router? Using the"},{"line_number":84,"context_line":"      FIP gateway IP seems simpler and does cut down on address usage"},{"line_number":85,"context_line":"      (although subnet service types does make this less of an issue). On the"},{"line_number":86,"context_line":"      flip side, an address associated with the router does allow for better"},{"line_number":87,"context_line":"      scrutiny of network traffic as traffic flows can be tied to a specific"},{"line_number":88,"context_line":"      project and router."}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_088bff6d","line":85,"range":{"start_line":83,"start_character":65,"end_line":85,"end_character":69},"updated":"2019-05-10 18:12:48.000000000","message":"This would not be possible, since we are sharing the FIP agent gateway port will all tenants.\nSo we need to come up with an External IP for each and every tenant per compute node in here.","commit_id":"2973b5129f5ad1e7ccee2cd00048545084d922e6"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"987c5d0d221b19c8351d818e3f8824b02b7034e4","unresolved":false,"context_lines":[{"line_number":80,"context_line":"    (Insert diagram and explain in detail here)"},{"line_number":81,"context_line":"  * Open questions:"},{"line_number":82,"context_line":"    * Should SNAT traffic use the FIP gateway IP as the source address, or"},{"line_number":83,"context_line":"      should it use an IP address specific to the tenant router? Using the"},{"line_number":84,"context_line":"      FIP gateway IP seems simpler and does cut down on address usage"},{"line_number":85,"context_line":"      (although subnet service types does make this less of an issue). On the"},{"line_number":86,"context_line":"      flip side, an address associated with the router does allow for better"},{"line_number":87,"context_line":"      scrutiny of network traffic as traffic flows can be tied to a specific"},{"line_number":88,"context_line":"      project and router."}],"source_content_type":"text/x-rst","patch_set":1,"id":"dfbec78f_ae119b5f","line":85,"range":{"start_line":83,"start_character":65,"end_line":85,"end_character":69},"in_reply_to":"dfbec78f_088bff6d","updated":"2019-05-10 20:46:01.000000000","message":"I actually think it is possible, you can snat coming out of the qrouter namespace, then do it again on egress from the FIP namespace. Not elegant, but it works.\n\nThis is a place where openflow DVR may provide a cleaner solution, we wouldn\u0027t have the same multi-tenancy concerns there while processing the packet in an OpenFlow pipeline. There are commercial SDN solutions that do this exact thing with OpenFlow and OVS.","commit_id":"2973b5129f5ad1e7ccee2cd00048545084d922e6"}],"specs/train/ml2ovs-ovn-convergence.rst":[{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"c27a84c88be794dfdf54a8cf6518d1a7a0bc13d3","unresolved":false,"context_lines":[{"line_number":42,"context_line":"When looking at enhancing control plane scalability, distributed DHCP, and"},{"line_number":43,"context_line":"pushing all forwarding policy into OVS for potential hardware offload, it"},{"line_number":44,"context_line":"has been noted that OVN already implements many of these things. OVN also"},{"line_number":45,"context_line":"lacks some functionality that ML2+OVS+DVR has such as fully distributed ingress"},{"line_number":46,"context_line":"and egress which makes it possible to route all north-south traffic directly"},{"line_number":47,"context_line":"to the appropriate compute, bypassing a central network node."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"Proposed solution"},{"line_number":50,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_3e4d2f72","line":47,"range":{"start_line":45,"start_character":54,"end_line":47,"end_character":60},"updated":"2019-06-04 17:58:56.000000000","message":"So I might have mis-spoke when we discussed this on IRC.\n\nOVN has fully distributed ingress/egress for floating IP addresses, just as ML2+OVS+DVR has today.  I was confusing it with something else.","commit_id":"3f0f65df15b47eabae823fe18780e09666e5d36e"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"5a21dde85882bac0fa033b8b977f96c8ded6bf2c","unresolved":false,"context_lines":[{"line_number":42,"context_line":"When looking at enhancing control plane scalability, distributed DHCP, and"},{"line_number":43,"context_line":"pushing all forwarding policy into OVS for potential hardware offload, it"},{"line_number":44,"context_line":"has been noted that OVN already implements many of these things. OVN also"},{"line_number":45,"context_line":"lacks some functionality that ML2+OVS+DVR has such as fully distributed ingress"},{"line_number":46,"context_line":"and egress which makes it possible to route all north-south traffic directly"},{"line_number":47,"context_line":"to the appropriate compute, bypassing a central network node."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"Proposed solution"},{"line_number":50,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_92d64cc3","line":47,"range":{"start_line":45,"start_character":54,"end_line":47,"end_character":60},"in_reply_to":"9fb8cfa7_37e19fd1","updated":"2019-06-07 16:11:26.000000000","message":"Ok, I\u0027ll put this back with an additional item about BGP in the gap section.","commit_id":"3f0f65df15b47eabae823fe18780e09666e5d36e"},{"author":{"_account_id":9531,"name":"liuyulong","display_name":"LIU Yulong","email":"i@liuyulong.me","username":"LIU-Yulong"},"change_message_id":"6cca58b53af0d1f57603f605cabbcc4b1460c858","unresolved":false,"context_lines":[{"line_number":42,"context_line":"When looking at enhancing control plane scalability, distributed DHCP, and"},{"line_number":43,"context_line":"pushing all forwarding policy into OVS for potential hardware offload, it"},{"line_number":44,"context_line":"has been noted that OVN already implements many of these things. OVN also"},{"line_number":45,"context_line":"lacks some functionality that ML2+OVS+DVR has such as fully distributed ingress"},{"line_number":46,"context_line":"and egress which makes it possible to route all north-south traffic directly"},{"line_number":47,"context_line":"to the appropriate compute, bypassing a central network node."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"Proposed solution"},{"line_number":50,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_72f0b391","line":47,"range":{"start_line":45,"start_character":54,"end_line":47,"end_character":60},"in_reply_to":"9fb8cfa7_3e4d2f72","updated":"2019-06-05 03:06:50.000000000","message":"Doesn\u0027t this mean SNAT traffic for port without floating IP? Line 40.","commit_id":"3f0f65df15b47eabae823fe18780e09666e5d36e"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"ba1dd424dd735dcfddbdb07fbe309db6af81ca32","unresolved":false,"context_lines":[{"line_number":42,"context_line":"When looking at enhancing control plane scalability, distributed DHCP, and"},{"line_number":43,"context_line":"pushing all forwarding policy into OVS for potential hardware offload, it"},{"line_number":44,"context_line":"has been noted that OVN already implements many of these things. OVN also"},{"line_number":45,"context_line":"lacks some functionality that ML2+OVS+DVR has such as fully distributed ingress"},{"line_number":46,"context_line":"and egress which makes it possible to route all north-south traffic directly"},{"line_number":47,"context_line":"to the appropriate compute, bypassing a central network node."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"Proposed solution"},{"line_number":50,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_df237f04","line":47,"range":{"start_line":45,"start_character":54,"end_line":47,"end_character":60},"in_reply_to":"9fb8cfa7_72f0b391","updated":"2019-06-06 18:08:12.000000000","message":"I thought it was just floating IP, but if it was for distributed SNAT I can put it back.","commit_id":"3f0f65df15b47eabae823fe18780e09666e5d36e"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"0290e10af0231fbe11065e28389695d45fce2857","unresolved":false,"context_lines":[{"line_number":42,"context_line":"When looking at enhancing control plane scalability, distributed DHCP, and"},{"line_number":43,"context_line":"pushing all forwarding policy into OVS for potential hardware offload, it"},{"line_number":44,"context_line":"has been noted that OVN already implements many of these things. OVN also"},{"line_number":45,"context_line":"lacks some functionality that ML2+OVS+DVR has such as fully distributed ingress"},{"line_number":46,"context_line":"and egress which makes it possible to route all north-south traffic directly"},{"line_number":47,"context_line":"to the appropriate compute, bypassing a central network node."},{"line_number":48,"context_line":""},{"line_number":49,"context_line":"Proposed solution"},{"line_number":50,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_37e19fd1","line":47,"range":{"start_line":45,"start_character":54,"end_line":47,"end_character":60},"in_reply_to":"9fb8cfa7_df237f04","updated":"2019-06-06 22:49:35.000000000","message":"I intended ALL traffic here. This is something you can currently do with DVR, with the exception of SNAT. You can make the tenant subnet routable via BGP and announce host routes, you can use floating IP\u0027s, or a combination of the two. These features are not mutually exclusive today, I envision parity with this in OVN before calling convergence complete.\n\nDistributed SNAT would nice to have, I am envisioning a world where things are either somewhat or totally distributed. No dedicated network nodes needed.","commit_id":"3f0f65df15b47eabae823fe18780e09666e5d36e"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"c27a84c88be794dfdf54a8cf6518d1a7a0bc13d3","unresolved":false,"context_lines":[{"line_number":76,"context_line":"Feature Gap Analysis"},{"line_number":77,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"TODO Fill out feature matrix comparing OVN and DVR."},{"line_number":80,"context_line":""},{"line_number":81,"context_line":"Performance Analysis"},{"line_number":82,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_5ea023f5","line":79,"updated":"2019-06-04 17:58:56.000000000","message":"I can add some info here, but basically the gaps are things like newer extensions.","commit_id":"3f0f65df15b47eabae823fe18780e09666e5d36e"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"c27a84c88be794dfdf54a8cf6518d1a7a0bc13d3","unresolved":false,"context_lines":[{"line_number":86,"context_line":"Migration"},{"line_number":87,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"TODO Discuss the details of migration."},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"RFE/Blueprints to Implement"},{"line_number":92,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_1e138bb7","line":89,"updated":"2019-06-04 17:58:56.000000000","message":"Migration is not straightforward, and it\u0027s unclear it\u0027s something that can be accomplished in upstream Neutron in an automated fashion as it\u0027s very dependent on the deployment tool being used.","commit_id":"3f0f65df15b47eabae823fe18780e09666e5d36e"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"0290e10af0231fbe11065e28389695d45fce2857","unresolved":false,"context_lines":[{"line_number":86,"context_line":"Migration"},{"line_number":87,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"TODO Discuss the details of migration."},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"RFE/Blueprints to Implement"},{"line_number":92,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_644f9abd","line":89,"in_reply_to":"9fb8cfa7_1e138bb7","updated":"2019-06-06 22:49:35.000000000","message":"Agreed, I\u0027m not sure neutron can handle this entirely on its own. I\u0027m thinking we should call out any loose ends we know of right now that would make migration a little cleaner.\n\nWe should also make it a goal to at least have some docs that describe in the abstract what the migration process looks like.","commit_id":"3f0f65df15b47eabae823fe18780e09666e5d36e"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"5a21dde85882bac0fa033b8b977f96c8ded6bf2c","unresolved":false,"context_lines":[{"line_number":86,"context_line":"Migration"},{"line_number":87,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"TODO Discuss the details of migration."},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"RFE/Blueprints to Implement"},{"line_number":92,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_52e0d496","line":89,"in_reply_to":"9fb8cfa7_644f9abd","updated":"2019-06-07 16:11:26.000000000","message":"See my link from the latest update :)","commit_id":"3f0f65df15b47eabae823fe18780e09666e5d36e"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"c27a84c88be794dfdf54a8cf6518d1a7a0bc13d3","unresolved":false,"context_lines":[{"line_number":146,"context_line":"      scrutiny of network traffic as traffic flows can be tied to a specific"},{"line_number":147,"context_line":"      project and router."},{"line_number":148,"context_line":"  * See [4] for some historical context and details"},{"line_number":149,"context_line":"  * TODO more details"},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"Configuration Impact:"},{"line_number":152,"context_line":"* TODO"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fb8cfa7_fe21d7a0","line":149,"updated":"2019-06-04 17:58:56.000000000","message":"I\u0027ll get some info on what OVN does here.","commit_id":"3f0f65df15b47eabae823fe18780e09666e5d36e"},{"author":{"_account_id":9531,"name":"liuyulong","display_name":"LIU Yulong","email":"i@liuyulong.me","username":"LIU-Yulong"},"change_message_id":"6cca58b53af0d1f57603f605cabbcc4b1460c858","unresolved":false,"context_lines":[{"line_number":55,"context_line":"  OVN provides."},{"line_number":56,"context_line":"- Removes the duplication of effort for both core neutron developers and"},{"line_number":57,"context_line":"  networking-ovn developers, and allows for cross-pollination of ideas for"},{"line_number":58,"context_line":"  addressing scale, data plane performance, and usability issues in neutron."},{"line_number":59,"context_line":"- Aligns the community of developers supporting neutron and OVN, broadening"},{"line_number":60,"context_line":"  the potential contributor base for neutron."},{"line_number":61,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_b252ab66","line":58,"range":{"start_line":58,"start_character":13,"end_line":58,"end_character":64},"updated":"2019-06-05 03:06:50.000000000","message":"Indeed, we meet all these issues locally. Everytime we are trying to build a cloud, we will do many estimating work for cluster capacity. How many physical hosts we have? How many port per host? How many router per network node? Large-flavor virtual machine traffic latency sometimes can not meet the requirement for our customers. And everytime upgrading the deployment can result different issues.","commit_id":"7139b6c1c68dde2db8c783c1040f0d69211f0d45"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"0290e10af0231fbe11065e28389695d45fce2857","unresolved":false,"context_lines":[{"line_number":55,"context_line":"  OVN provides."},{"line_number":56,"context_line":"- Removes the duplication of effort for both core neutron developers and"},{"line_number":57,"context_line":"  networking-ovn developers, and allows for cross-pollination of ideas for"},{"line_number":58,"context_line":"  addressing scale, data plane performance, and usability issues in neutron."},{"line_number":59,"context_line":"- Aligns the community of developers supporting neutron and OVN, broadening"},{"line_number":60,"context_line":"  the potential contributor base for neutron."},{"line_number":61,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_d7e7e3e3","line":58,"range":{"start_line":58,"start_character":13,"end_line":58,"end_character":64},"in_reply_to":"9fb8cfa7_b252ab66","updated":"2019-06-06 22:49:35.000000000","message":"I want to see a section on performance analysis in this spec, with hard data for all scale and performance items.","commit_id":"7139b6c1c68dde2db8c783c1040f0d69211f0d45"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"78772e5d70151817e0906f949437d987139fe07d","unresolved":false,"context_lines":[{"line_number":169,"context_line":"  * To provide proper tenant isolation when using the namespace-based"},{"line_number":170,"context_line":"    implementation of DVR, SNAT would be performed twice"},{"line_number":171,"context_line":"    (Insert diagram and explain in detail here)"},{"line_number":172,"context_line":"  * Open questions:"},{"line_number":173,"context_line":"    * Should SNAT traffic use the FIP gateway IP as the source address, or"},{"line_number":174,"context_line":"      should it use an IP address specific to the tenant router? Using the"},{"line_number":175,"context_line":"      FIP gateway IP seems simpler and does cut down on address usage"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9fb8cfa7_2f609ba5","line":172,"updated":"2019-06-04 19:15:47.000000000","message":"tox -e docs really wants an empty line after this, strange.","commit_id":"7139b6c1c68dde2db8c783c1040f0d69211f0d45"},{"author":{"_account_id":30156,"name":"Igor D.C.","email":"igor.duarte.cardoso@intel.com","username":"igordc"},"change_message_id":"c4b9f17c793eacd17c49ea485196554fe7136aa8","unresolved":false,"context_lines":[{"line_number":28,"context_line":"  when large numbers of nodes participate in the neutron deployment"},{"line_number":29,"context_line":"- Support for distributed ingress/egress when using IPv6 in conjunction with"},{"line_number":30,"context_line":"  BGP and/or neutron-dynamic-routing"},{"line_number":31,"context_line":"- DVR cannot be cleanly offloaded with smart-NIC technology due to its use of"},{"line_number":32,"context_line":"  linux namespaces"},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"In addition to the above shortcomings, DVR would also benefit from the"}],"source_content_type":"text/x-rst","patch_set":9,"id":"7faddb67_77f1c56a","line":31,"range":{"start_line":31,"start_character":59,"end_line":31,"end_character":60},"updated":"2019-08-06 19:46:09.000000000","message":"or user-space tools","commit_id":"61e698a643d22071f97b7295ed8237a5450f1183"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"6b450be9cf6d3777bc1264f9c8a8f7d1dc3cc9f5","unresolved":false,"context_lines":[{"line_number":28,"context_line":"  when large numbers of nodes participate in the neutron deployment"},{"line_number":29,"context_line":"- Support for distributed ingress/egress when using IPv6 in conjunction with"},{"line_number":30,"context_line":"  BGP and/or neutron-dynamic-routing"},{"line_number":31,"context_line":"- DVR cannot be cleanly offloaded with smart-NIC technology due to its use of"},{"line_number":32,"context_line":"  linux namespaces"},{"line_number":33,"context_line":""},{"line_number":34,"context_line":"In addition to the above shortcomings, DVR would also benefit from the"}],"source_content_type":"text/x-rst","patch_set":9,"id":"7faddb67_2e4f3293","line":31,"range":{"start_line":31,"start_character":59,"end_line":31,"end_character":60},"in_reply_to":"7faddb67_77f1c56a","updated":"2019-08-09 20:55:51.000000000","message":"Done","commit_id":"61e698a643d22071f97b7295ed8237a5450f1183"},{"author":{"_account_id":9531,"name":"liuyulong","display_name":"LIU Yulong","email":"i@liuyulong.me","username":"LIU-Yulong"},"change_message_id":"76ca2223fa6499c80cc22b0d44dbd6954c33ddea","unresolved":false,"context_lines":[{"line_number":35,"context_line":"following enhancements:"},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"- Support for running without network nodes if an operator chooses"},{"line_number":38,"context_line":"- Support for distributed DHCP (local DHCP responder) [1]_"},{"line_number":39,"context_line":"- Support for distributed SNAT"},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"When looking at enhancing control plane scalability, distributed DHCP, and"}],"source_content_type":"text/x-rst","patch_set":9,"id":"9fb8cfa7_27700472","line":38,"range":{"start_line":38,"start_character":2,"end_line":38,"end_character":58},"updated":"2019-07-02 01:37:45.000000000","message":"This will be a neutron natively supporting or using OVN?","commit_id":"61e698a643d22071f97b7295ed8237a5450f1183"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"e81381013a1c3f06df83f41a917af6c9fd29a003","unresolved":false,"context_lines":[{"line_number":35,"context_line":"following enhancements:"},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"- Support for running without network nodes if an operator chooses"},{"line_number":38,"context_line":"- Support for distributed DHCP (local DHCP responder) [1]_"},{"line_number":39,"context_line":"- Support for distributed SNAT"},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"When looking at enhancing control plane scalability, distributed DHCP, and"}],"source_content_type":"text/x-rst","patch_set":9,"id":"7faddb67_ed5c927f","line":38,"range":{"start_line":38,"start_character":2,"end_line":38,"end_character":58},"in_reply_to":"9fb8cfa7_27700472","updated":"2019-07-10 20:56:30.000000000","message":"In this spec we\u0027re only trying to identify the problems/gaps/etc, I\u0027m not proposing a solution for this problem in Neutron.","commit_id":"61e698a643d22071f97b7295ed8237a5450f1183"},{"author":{"_account_id":30156,"name":"Igor D.C.","email":"igor.duarte.cardoso@intel.com","username":"igordc"},"change_message_id":"c4b9f17c793eacd17c49ea485196554fe7136aa8","unresolved":false,"context_lines":[{"line_number":69,"context_line":"- What is the migration path? How disruptive will migration be? How can it be"},{"line_number":70,"context_line":"  simplified?"},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"The following sections attempt to answer these questions outline the procedural"},{"line_number":73,"context_line":"and technical aspects of the convergence of ML2+OVS+DVR and networking-ovn."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"Feature Gap Analysis"}],"source_content_type":"text/x-rst","patch_set":9,"id":"7faddb67_37326d5f","line":72,"range":{"start_line":72,"start_character":56,"end_line":72,"end_character":57},"updated":"2019-08-06 19:46:09.000000000","message":"and","commit_id":"61e698a643d22071f97b7295ed8237a5450f1183"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"6b450be9cf6d3777bc1264f9c8a8f7d1dc3cc9f5","unresolved":false,"context_lines":[{"line_number":69,"context_line":"- What is the migration path? How disruptive will migration be? How can it be"},{"line_number":70,"context_line":"  simplified?"},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"The following sections attempt to answer these questions outline the procedural"},{"line_number":73,"context_line":"and technical aspects of the convergence of ML2+OVS+DVR and networking-ovn."},{"line_number":74,"context_line":""},{"line_number":75,"context_line":"Feature Gap Analysis"}],"source_content_type":"text/x-rst","patch_set":9,"id":"7faddb67_0e4a7682","line":72,"range":{"start_line":72,"start_character":56,"end_line":72,"end_character":57},"in_reply_to":"7faddb67_37326d5f","updated":"2019-08-09 20:55:51.000000000","message":"Done","commit_id":"61e698a643d22071f97b7295ed8237a5450f1183"},{"author":{"_account_id":19307,"name":"Antonio Ojea","email":"antonio.ojea.garcia@gmail.com","username":"itsuugo"},"change_message_id":"0d478dabbad7b8bbdf93a5f779984576bc4c974b","unresolved":false,"context_lines":[{"line_number":147,"context_line":"description of what steps are required, and the other being deployment-specific"},{"line_number":148,"context_line":"notes, would help others when adding more tools."},{"line_number":149,"context_line":""},{"line_number":150,"context_line":"Developer Impact"},{"line_number":151,"context_line":"----------------"},{"line_number":152,"context_line":""},{"line_number":153,"context_line":"TODO fill out with more potential RFE\u0027s and/or blueprints"}],"source_content_type":"text/x-rst","patch_set":9,"id":"7faddb67_0d392340","line":150,"updated":"2019-07-24 16:09:42.000000000","message":"It will be nice to describe/sketch the final architecture, reading the spec seems that at least some of the current OVS/DVR agents like the neutron-dhcp-agent will no longer need","commit_id":"61e698a643d22071f97b7295ed8237a5450f1183"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"6b450be9cf6d3777bc1264f9c8a8f7d1dc3cc9f5","unresolved":false,"context_lines":[{"line_number":147,"context_line":"description of what steps are required, and the other being deployment-specific"},{"line_number":148,"context_line":"notes, would help others when adding more tools."},{"line_number":149,"context_line":""},{"line_number":150,"context_line":"Developer Impact"},{"line_number":151,"context_line":"----------------"},{"line_number":152,"context_line":""},{"line_number":153,"context_line":"TODO fill out with more potential RFE\u0027s and/or blueprints"}],"source_content_type":"text/x-rst","patch_set":9,"id":"7faddb67_2e1df272","line":150,"in_reply_to":"7faddb67_0d392340","updated":"2019-08-09 20:55:51.000000000","message":"Right, if OVN is the final architecture, we will not need some (any?) of the current neutron agents.\n\nI think the lists above and below describe both items we feel are necessary, and some \"wish list\" items we feel are needed in the future.  Not sure if there\u0027s a better way to structure this though.","commit_id":"61e698a643d22071f97b7295ed8237a5450f1183"},{"author":{"_account_id":30156,"name":"Igor D.C.","email":"igor.duarte.cardoso@intel.com","username":"igordc"},"change_message_id":"c4b9f17c793eacd17c49ea485196554fe7136aa8","unresolved":false,"context_lines":[{"line_number":169,"context_line":"    a network node."},{"line_number":170,"context_line":"  * There is an existing RFE for this, see [7]_"},{"line_number":171,"context_line":""},{"line_number":172,"context_line":"- Support for smart-NIC offloads"},{"line_number":173,"context_line":""},{"line_number":174,"context_line":"  * This involves pushing all DVR forwarding policy into OVS and implementing"},{"line_number":175,"context_line":"    it via OpenFlow."}],"source_content_type":"text/x-rst","patch_set":9,"id":"7faddb67_b7e17d9d","line":172,"range":{"start_line":172,"start_character":23,"end_line":172,"end_character":24},"updated":"2019-08-06 19:46:09.000000000","message":"or user-space","commit_id":"61e698a643d22071f97b7295ed8237a5450f1183"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"6b450be9cf6d3777bc1264f9c8a8f7d1dc3cc9f5","unresolved":false,"context_lines":[{"line_number":169,"context_line":"    a network node."},{"line_number":170,"context_line":"  * There is an existing RFE for this, see [7]_"},{"line_number":171,"context_line":""},{"line_number":172,"context_line":"- Support for smart-NIC offloads"},{"line_number":173,"context_line":""},{"line_number":174,"context_line":"  * This involves pushing all DVR forwarding policy into OVS and implementing"},{"line_number":175,"context_line":"    it via OpenFlow."}],"source_content_type":"text/x-rst","patch_set":9,"id":"7faddb67_ce43fe6b","line":172,"range":{"start_line":172,"start_character":23,"end_line":172,"end_character":24},"in_reply_to":"7faddb67_b7e17d9d","updated":"2019-08-09 20:55:51.000000000","message":"Done","commit_id":"61e698a643d22071f97b7295ed8237a5450f1183"},{"author":{"_account_id":23804,"name":"Daniel Alvarez","email":"dalvarez@redhat.com","username":"dalvarez"},"change_message_id":"dc2f5321510c9bbca0670edc336cd59a8d0a1254","unresolved":false,"context_lines":[{"line_number":81,"context_line":""},{"line_number":82,"context_line":"- Fragmentation and Jumbo frames support"},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"  * OVN does not yet support sending ICMP \"fragmentation needed\" packets, so"},{"line_number":85,"context_line":"    larger ICMP/UDP packets that needs to be fragmented will not work as they"},{"line_number":86,"context_line":"    would with the ML2/OVS driver implementation. TCP traffic should work due"},{"line_number":87,"context_line":"    to the MSS mechanism however."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"  * Upstream work to support this in the OVS/OVN code has been completed,"},{"line_number":90,"context_line":"    additional work is required in the networking-ovn repository to enable it."}],"source_content_type":"text/x-rst","patch_set":11,"id":"5faad753_af1470a1","line":87,"range":{"start_line":84,"start_character":0,"end_line":87,"end_character":33},"updated":"2019-09-10 13:12:55.000000000","message":"Maybe by the time we merge this, the support is added [0].\nThe OVN kernel bits got merged in upstream kernel \u003e\u003d 5.2\n\n[0] https://review.opendev.org/#/c/671766/","commit_id":"3c9ac4ae0c4d75679f82a3c41d2a191547691953"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"00693063549176a98733470ced6addd6f964c4ac","unresolved":false,"context_lines":[{"line_number":81,"context_line":""},{"line_number":82,"context_line":"- Fragmentation and Jumbo frames support"},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"  * OVN does not yet support sending ICMP \"fragmentation needed\" packets, so"},{"line_number":85,"context_line":"    larger ICMP/UDP packets that needs to be fragmented will not work as they"},{"line_number":86,"context_line":"    would with the ML2/OVS driver implementation. TCP traffic should work due"},{"line_number":87,"context_line":"    to the MSS mechanism however."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"  * Upstream work to support this in the OVS/OVN code has been completed,"},{"line_number":90,"context_line":"    additional work is required in the networking-ovn repository to enable it."}],"source_content_type":"text/x-rst","patch_set":11,"id":"3fa7e38b_45b71688","line":87,"range":{"start_line":84,"start_character":0,"end_line":87,"end_character":33},"in_reply_to":"5faad753_af1470a1","updated":"2019-09-17 14:48:13.000000000","message":"Yes, this has merged, we should remove it from the spec.","commit_id":"3c9ac4ae0c4d75679f82a3c41d2a191547691953"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"630d406fb3d49b62e4dd9f907208ed49e0873beb","unresolved":false,"context_lines":[{"line_number":154,"context_line":"- Move networking-ovn code to neutron repo and treat OVN as an in-tree driver"},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"  * Moving networking-ovn into the neutron repository is the first step toward"},{"line_number":157,"context_line":"    supporting convergence."},{"line_number":158,"context_line":""},{"line_number":159,"context_line":"- Distributed ingress/egress for IPv6"},{"line_number":160,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"5faad753_13c88f53","line":157,"updated":"2019-09-06 13:58:02.000000000","message":"that is great idea. One thing which we should thing of is CI jobs. I see now that there is potentially 8 jobs from check queue from networking-ovn which should be probably moved to neutron also. 3 of them are non-voting and 2 voting ones are python 2.7 so we will be able to drop them next year probably.\nSo it should be not too bad :)","commit_id":"3c9ac4ae0c4d75679f82a3c41d2a191547691953"},{"author":{"_account_id":23804,"name":"Daniel Alvarez","email":"dalvarez@redhat.com","username":"dalvarez"},"change_message_id":"dc2f5321510c9bbca0670edc336cd59a8d0a1254","unresolved":false,"context_lines":[{"line_number":154,"context_line":"- Move networking-ovn code to neutron repo and treat OVN as an in-tree driver"},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"  * Moving networking-ovn into the neutron repository is the first step toward"},{"line_number":157,"context_line":"    supporting convergence."},{"line_number":158,"context_line":""},{"line_number":159,"context_line":"- Distributed ingress/egress for IPv6"},{"line_number":160,"context_line":""}],"source_content_type":"text/x-rst","patch_set":11,"id":"5faad753_ef2108fd","line":157,"in_reply_to":"5faad753_13c88f53","updated":"2019-09-10 13:12:55.000000000","message":"++ to this!","commit_id":"3c9ac4ae0c4d75679f82a3c41d2a191547691953"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"630d406fb3d49b62e4dd9f907208ed49e0873beb","unresolved":false,"context_lines":[{"line_number":231,"context_line":"functionality in terms of data plane features such trunks, routed networks,"},{"line_number":232,"context_line":"address scopes, etc. Matching support for every specific extension is not"},{"line_number":233,"context_line":"necessary in all cases. For example, OVN provides DVR functionality in its"},{"line_number":234,"context_line":"implementation without implementing the API extensions DVR introduces."},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"Implementation"},{"line_number":237,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5faad753_5387e7d8","line":234,"range":{"start_line":234,"start_character":23,"end_line":234,"end_character":69},"updated":"2019-09-06 13:58:02.000000000","message":"can You elaborate a bit more about those API extensions? What extensions are not needed there? And will we need to load/unload specific extensions depending on mechanism drivers configured?","commit_id":"3c9ac4ae0c4d75679f82a3c41d2a191547691953"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"b32694afa44f5e853c9fd250bd2ce63b7c7a022d","unresolved":false,"context_lines":[{"line_number":231,"context_line":"functionality in terms of data plane features such trunks, routed networks,"},{"line_number":232,"context_line":"address scopes, etc. Matching support for every specific extension is not"},{"line_number":233,"context_line":"necessary in all cases. For example, OVN provides DVR functionality in its"},{"line_number":234,"context_line":"implementation without implementing the API extensions DVR introduces."},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"Implementation"},{"line_number":237,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5faad753_476cfc07","line":234,"range":{"start_line":234,"start_character":23,"end_line":234,"end_character":69},"in_reply_to":"5faad753_0721244e","updated":"2019-09-06 17:32:03.000000000","message":"I was actually looking at this today, since there are tests that fail without those router extensions, see https://review.opendev.org/#/c/670291/ - if we wanted to make it compatible, we could have OVN \"fake\" things out and return distributed and ha attributes in the router.  I too was torn on what the best thing to do is, since they are only admin-visible.\n\nCreated a hack at https://review.opendev.org/#/c/680749/","commit_id":"3c9ac4ae0c4d75679f82a3c41d2a191547691953"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"8830cb9d70717fa1fb1c13ef95a30ee8acf610a5","unresolved":false,"context_lines":[{"line_number":231,"context_line":"functionality in terms of data plane features such trunks, routed networks,"},{"line_number":232,"context_line":"address scopes, etc. Matching support for every specific extension is not"},{"line_number":233,"context_line":"necessary in all cases. For example, OVN provides DVR functionality in its"},{"line_number":234,"context_line":"implementation without implementing the API extensions DVR introduces."},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"Implementation"},{"line_number":237,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5faad753_f7f30c09","line":234,"range":{"start_line":234,"start_character":23,"end_line":234,"end_character":69},"in_reply_to":"5faad753_476cfc07","updated":"2019-09-11 08:52:36.000000000","message":"Thx Ryan and Brian for explanation. I think that this \"fake\" things can be useful as we should IMO provide exactly same API (and parameters) in case of ML2/OVS and OVN drivers.","commit_id":"3c9ac4ae0c4d75679f82a3c41d2a191547691953"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"c8b1e7c9388ad1e6121a8ed6148124898fa1dd37","unresolved":false,"context_lines":[{"line_number":231,"context_line":"functionality in terms of data plane features such trunks, routed networks,"},{"line_number":232,"context_line":"address scopes, etc. Matching support for every specific extension is not"},{"line_number":233,"context_line":"necessary in all cases. For example, OVN provides DVR functionality in its"},{"line_number":234,"context_line":"implementation without implementing the API extensions DVR introduces."},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"Implementation"},{"line_number":237,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":11,"id":"5faad753_0721244e","line":234,"range":{"start_line":234,"start_character":23,"end_line":234,"end_character":69},"in_reply_to":"5faad753_5387e7d8","updated":"2019-09-06 16:49:53.000000000","message":"I\u0027ll elaborate here. DVR is the perfect example of what I\u0027m trying to express. The \u0027dvr\u0027 extension defines an attribute of \u0027distributed\u0027 for routers [1]. This extension is not implemented by the L3 plugin for OVN. My assertion is that this is not an issue. OVN gives us DVR in the data plane, even though it does not expose the \u0027dvr\u0027 extension. This is an example of \"parity\" that doesn\u0027t really matter. We are getting the same data plane features, even though we\u0027re taking away an API extension. In my view, these sorts of things should not be obstacles.\n\n[1] https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/dvr.py","commit_id":"3c9ac4ae0c4d75679f82a3c41d2a191547691953"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"00693063549176a98733470ced6addd6f964c4ac","unresolved":false,"context_lines":[{"line_number":231,"context_line":"functionality in terms of data plane features such trunks, routed networks,"},{"line_number":232,"context_line":"address scopes, etc. Matching support for every specific extension is not"},{"line_number":233,"context_line":"necessary in all cases. For example, OVN provides DVR functionality in its"},{"line_number":234,"context_line":"implementation without implementing the API extensions DVR introduces."},{"line_number":235,"context_line":""},{"line_number":236,"context_line":"Implementation"},{"line_number":237,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":11,"id":"3fa7e38b_307a5624","line":234,"range":{"start_line":234,"start_character":23,"end_line":234,"end_character":69},"in_reply_to":"5faad753_f7f30c09","updated":"2019-09-17 14:48:13.000000000","message":"So after working on the above review, I maybe missed the point Ryan was trying to make.  It\u0027s Ok if OVN doesn\u0027t support an extension, if it still implements it by default, like DVR and HA.  I think we just have to make sure we don\u0027t lose any test coverage in the process.","commit_id":"3c9ac4ae0c4d75679f82a3c41d2a191547691953"},{"author":{"_account_id":8655,"name":"Jakub Libosvar","email":"libosvar@redhat.com","username":"jlibosva"},"change_message_id":"b92928910deaf8e56ec044de64f7f97744e840d6","unresolved":false,"context_lines":[{"line_number":146,"context_line":"Developer Impact"},{"line_number":147,"context_line":"----------------"},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"- Move networking-ovn code to neutron repo and treat OVN as an in-tree driver"},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"  * Moving networking-ovn into the neutron repository is the first step toward"},{"line_number":152,"context_line":"    supporting convergence."}],"source_content_type":"text/x-rst","patch_set":12,"id":"3fa7e38b_34c70799","line":149,"updated":"2019-09-26 09:00:21.000000000","message":"Perhaps would be good to write more details about this.\n\nWhy networking-ovn cannot live outside of Neutron?\nWhat would be the benefit of having it in-tree?\nHow will the reviewing work for different parts of the tree?\nHow complex will the gating become?\nWhat\u0027s the impact on installers?\n\nMy opinion so far is that it\u0027s a big effort and we don\u0027t have enough dataa to decide. It would be good if it\u0027s worth the change in advance and write down cons and pros. Currently we have experts on Neutron who are not familiar with networking-ovn and vice-versa - experts in networking-ovn not familiar with Neutron internals. That would make reviews hard.","commit_id":"208ebc9cd865b6ca3fd7e552d2663f03dde8b267"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"36f66fcc1e720bcd52ee66fce6be403ba2507388","unresolved":false,"context_lines":[{"line_number":146,"context_line":"Developer Impact"},{"line_number":147,"context_line":"----------------"},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"- Move networking-ovn code to neutron repo and treat OVN as an in-tree driver"},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"  * Moving networking-ovn into the neutron repository is the first step toward"},{"line_number":152,"context_line":"    supporting convergence."}],"source_content_type":"text/x-rst","patch_set":12,"id":"3fa7e38b_5c6c259b","line":149,"in_reply_to":"3fa7e38b_34c70799","updated":"2019-09-26 14:05:37.000000000","message":"Perhaps initially we could hold off on bringing it in-tree. However, if we are serious about this direction it is my opinion that we should bring it in-tree. Perhaps it\u0027s not clear in the spec, but the end game here is to *eventually* deprecate ML2+OVS. In my opinion having code scattered across too many repositories is a barrier to entry and a nuisance for maintenance. In my opinion, the circumstances that necessitated the creation of the stadium no longer exist. With a smaller team of contributors, I think having more code in-tree actually has more upside than downside.\n\nBut as you point out, this is an impactful step that may warrant more discussion. I\u0027m curious what others think.","commit_id":"208ebc9cd865b6ca3fd7e552d2663f03dde8b267"},{"author":{"_account_id":8655,"name":"Jakub Libosvar","email":"libosvar@redhat.com","username":"jlibosva"},"change_message_id":"df5691dcac29b095ea6e35a9b4ac8fb4b801bd8f","unresolved":false,"context_lines":[{"line_number":146,"context_line":"Developer Impact"},{"line_number":147,"context_line":"----------------"},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"- Move networking-ovn code to neutron repo and treat OVN as an in-tree driver"},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"  * Moving networking-ovn into the neutron repository is the first step toward"},{"line_number":152,"context_line":"    supporting convergence."}],"source_content_type":"text/x-rst","patch_set":12,"id":"3fa7e38b_9c2a9dd8","line":149,"in_reply_to":"3fa7e38b_5c6c259b","updated":"2019-09-26 14:13:53.000000000","message":"Thanks for reply. I understood from the document (or maybe it were discussions outside of this document) to deprecate ML2+OVS in the future. My concern was to not rush into doing something that requires a lot of work and testing without considering benefits of doing so. We\u0027ve been doing rehoming and splitting of the code all the time in Neutron since Kilo I think :)","commit_id":"208ebc9cd865b6ca3fd7e552d2663f03dde8b267"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"e3fcad087c448f21fb1e38dbf64683a1fa676c02","unresolved":false,"context_lines":[{"line_number":146,"context_line":"Developer Impact"},{"line_number":147,"context_line":"----------------"},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"- Move networking-ovn code to neutron repo and treat OVN as an in-tree driver"},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"  * Moving networking-ovn into the neutron repository is the first step toward"},{"line_number":152,"context_line":"    supporting convergence."}],"source_content_type":"text/x-rst","patch_set":12,"id":"3fa7e38b_e5445476","line":149,"in_reply_to":"3fa7e38b_629dba64","updated":"2019-09-26 16:18:20.000000000","message":"It\u0027s not that we haven\u0027t thought about these things or even discussed them in depth. This was a topic of discussion at the last PTG and all of these points were raised and discussed. Writing this down and ensuring it\u0027s communicated is where we\u0027re lacking.\n\n@Brian am I correct in understanding your response to mean you want to cover this with a different spec rather than capturing it in this one?","commit_id":"208ebc9cd865b6ca3fd7e552d2663f03dde8b267"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"775a0da29723422fbb992736ba4c63ca0a00c708","unresolved":false,"context_lines":[{"line_number":146,"context_line":"Developer Impact"},{"line_number":147,"context_line":"----------------"},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"- Move networking-ovn code to neutron repo and treat OVN as an in-tree driver"},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"  * Moving networking-ovn into the neutron repository is the first step toward"},{"line_number":152,"context_line":"    supporting convergence."}],"source_content_type":"text/x-rst","patch_set":12,"id":"3fa7e38b_b6df7067","line":149,"in_reply_to":"3fa7e38b_8b1b31c8","updated":"2019-09-26 18:19:52.000000000","message":"Maybe we just need an etherpad? Conceptually, there\u0027s no secret sauce involved in moving over code. We move the code bringing CI jobs and docs along with it, then work toward some feature parity. That\u0027s what this spec says, I think another spec might be redundant.","commit_id":"208ebc9cd865b6ca3fd7e552d2663f03dde8b267"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"132506b4cc609b4322b6948bfcd9a0db149e6be0","unresolved":false,"context_lines":[{"line_number":146,"context_line":"Developer Impact"},{"line_number":147,"context_line":"----------------"},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"- Move networking-ovn code to neutron repo and treat OVN as an in-tree driver"},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"  * Moving networking-ovn into the neutron repository is the first step toward"},{"line_number":152,"context_line":"    supporting convergence."}],"source_content_type":"text/x-rst","patch_set":12,"id":"3fa7e38b_629dba64","line":149,"in_reply_to":"3fa7e38b_9c2a9dd8","updated":"2019-09-26 15:24:07.000000000","message":"Hi Kuba!  I was going to start another review to cover the details of moving the code (which might be complicated), but let\u0027s try and talk about your points here.\n\n1) Why move OVN in-tree?\n\nOne reason is, assuming the eventual deprecation of ML2/OVS, that having the default (OVN) in-tree is a requirement.  I think it would also lead to more people using it, if even just in devstack.\n\n2) How will reviews work?\n\nMy thought is that the current networking-ovn core team would be given +2 in neutron, with the caveat that they primarily only approve code related to OVN.  It\u0027s similar to how we had done things in Neutron for a while, with Lieutenants responsible for certain areas.  Over time this could change as people become more familiar with all the code.  It has the side-effect of growing the core team.\n\n3) Gating\n\nThe number of gate jobs will initially grow, so we would need to look at reducing them somehow over the U cycle.  Time for linuxbridge deprecation?\n\n4) Installers\n\nWe would have to figure out a packaging strategy, but I think we could keep things somewhat similar to today.  Upgrades is probably the more difficult piece.","commit_id":"208ebc9cd865b6ca3fd7e552d2663f03dde8b267"},{"author":{"_account_id":8655,"name":"Jakub Libosvar","email":"libosvar@redhat.com","username":"jlibosva"},"change_message_id":"aed47272853952f5fa20ce6f8735583c0fc6b332","unresolved":false,"context_lines":[{"line_number":146,"context_line":"Developer Impact"},{"line_number":147,"context_line":"----------------"},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"- Move networking-ovn code to neutron repo and treat OVN as an in-tree driver"},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"  * Moving networking-ovn into the neutron repository is the first step toward"},{"line_number":152,"context_line":"    supporting convergence."}],"source_content_type":"text/x-rst","patch_set":12,"id":"3fa7e38b_b1cf7027","line":149,"in_reply_to":"3fa7e38b_b6df7067","updated":"2019-09-27 09:34:59.000000000","message":"Thanks Brian and Ryan for answers. I might still miss the real benefit of having the code in-tree, so far what I\u0027m reading is that it\u0027s just a requirement to have it in-tree - but isn\u0027t that requirement given by us?\n\nSorry I\u0027m poking too much about it but how about we have devstack defaulting to enable_plugin/service with ovn repo/services, with that we achieve the same goal - having OVN as default and we avoid the burden of moving code, redefining jobs, merging core members of both projects, etc.\n\nMy thinking was that we could try e.g. one cycle having OVN default (when the right time comes), separated in its own repo. If it\u0027s not working, we can start working moving the code in-tree.\n\nWhat do you think?","commit_id":"208ebc9cd865b6ca3fd7e552d2663f03dde8b267"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"ce8a9b0592f5d00a718fb31cb8005e952085278d","unresolved":false,"context_lines":[{"line_number":146,"context_line":"Developer Impact"},{"line_number":147,"context_line":"----------------"},{"line_number":148,"context_line":""},{"line_number":149,"context_line":"- Move networking-ovn code to neutron repo and treat OVN as an in-tree driver"},{"line_number":150,"context_line":""},{"line_number":151,"context_line":"  * Moving networking-ovn into the neutron repository is the first step toward"},{"line_number":152,"context_line":"    supporting convergence."}],"source_content_type":"text/x-rst","patch_set":12,"id":"3fa7e38b_8b1b31c8","line":149,"in_reply_to":"3fa7e38b_e5445476","updated":"2019-09-26 17:52:18.000000000","message":"Ryan - yes, I\u0027d rather merge this then have a spec for how to move the code over.  Unless I\u0027m overthinking it and we just need an etherpad.","commit_id":"208ebc9cd865b6ca3fd7e552d2663f03dde8b267"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"ac63c16580c566915e17811f49f3dda104a6824b","unresolved":false,"context_lines":[{"line_number":235,"context_line":"Assignee(s)"},{"line_number":236,"context_line":"-----------"},{"line_number":237,"context_line":""},{"line_number":238,"context_line":"* Brian Haley \u003chaleyb.dev@gmail.com\u003e"},{"line_number":239,"context_line":""},{"line_number":240,"context_line":"Work Items"},{"line_number":241,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":12,"id":"3fa7e38b_f56f50f9","line":238,"updated":"2019-09-24 19:01:49.000000000","message":"Good, I get to assign all the tasks :)","commit_id":"208ebc9cd865b6ca3fd7e552d2663f03dde8b267"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"3d51dcc9c8e842f808ff5e2262020ade5cbba86e","unresolved":false,"context_lines":[{"line_number":106,"context_line":""},{"line_number":107,"context_line":"  * Currently ML2/OVS supports QoS DSCP tagging and egress bandwidth limiting."},{"line_number":108,"context_line":"    Those are basic QoS features that while integrated in the OVS/OVN C core"},{"line_number":109,"context_line":"    are not integrated (or fully tested) in the neutron OVN mechanism driver."},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"- BGP support"},{"line_number":112,"context_line":""}],"source_content_type":"text/x-rst","patch_set":14,"id":"3fa7e38b_c430f3eb","line":109,"updated":"2019-10-01 19:22:45.000000000","message":"speaking about QoS, bandwidth limit also don\u0027t work currently in networking-ovn. AFAIR it is added in networking-ovn but it is broken in core ovn.","commit_id":"d4407be9fa3f33984328a38d3cda106b7767e02c"}],"specs/ussuri/ml2ovs-ovn-convergence.rst":[{"author":{"_account_id":9531,"name":"liuyulong","display_name":"LIU Yulong","email":"i@liuyulong.me","username":"LIU-Yulong"},"change_message_id":"c13c89d9ae6001e0a9923b9d923b615988cd665e","unresolved":false,"context_lines":[{"line_number":66,"context_line":""},{"line_number":67,"context_line":"- Will users actually observe better control plane scale?"},{"line_number":68,"context_line":"- Will users lose support for any use cases?"},{"line_number":69,"context_line":"- What is the migration path? How disruptive will migration be? How can it be"},{"line_number":70,"context_line":"  simplified?"},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"The following sections attempt to answer these questions and outline the"}],"source_content_type":"text/x-rst","patch_set":15,"id":"3fa7e38b_4271b7a7","line":69,"range":{"start_line":69,"start_character":30,"end_line":69,"end_character":63},"updated":"2019-10-11 08:40:15.000000000","message":"Dataplane down is inevitable.","commit_id":"00ae32d27a8abacf3545c08ab683cf70912372d6"},{"author":{"_account_id":9531,"name":"liuyulong","display_name":"LIU Yulong","email":"i@liuyulong.me","username":"LIU-Yulong"},"change_message_id":"c13c89d9ae6001e0a9923b9d923b615988cd665e","unresolved":false,"context_lines":[{"line_number":76,"context_line":"Feature Gap Analysis"},{"line_number":77,"context_line":"--------------------"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"This is a list of currently known gaps between ML2/OVS and OVN. It might"},{"line_number":80,"context_line":"not be complete."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"- Fragmentation and Jumbo frames support"},{"line_number":83,"context_line":""}],"source_content_type":"text/x-rst","patch_set":15,"id":"3fa7e38b_ff007c36","line":80,"range":{"start_line":79,"start_character":64,"end_line":80,"end_character":16},"updated":"2019-10-11 08:40:15.000000000","message":"It\u0027s better to mention this TODO list for OVN:\nhttps://github.com/ovn-org/ovn/blob/master/TODO.rst","commit_id":"00ae32d27a8abacf3545c08ab683cf70912372d6"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"941606f2794a2f94572f1fb9a21ac1baee188d45","unresolved":false,"context_lines":[{"line_number":76,"context_line":"Feature Gap Analysis"},{"line_number":77,"context_line":"--------------------"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"This is a list of currently known gaps between ML2/OVS and OVN. It might"},{"line_number":80,"context_line":"not be complete."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"- Fragmentation and Jumbo frames support"},{"line_number":83,"context_line":""}],"source_content_type":"text/x-rst","patch_set":15,"id":"3fa7e38b_35cd8c5c","line":80,"range":{"start_line":79,"start_character":64,"end_line":80,"end_character":16},"in_reply_to":"3fa7e38b_ff007c36","updated":"2019-10-16 15:59:45.000000000","message":"Done","commit_id":"00ae32d27a8abacf3545c08ab683cf70912372d6"},{"author":{"_account_id":6773,"name":"Lucas Alvares Gomes","email":"lucasagomes@gmail.com","username":"lucasagomes"},"change_message_id":"88615b24d349a18dfefaa376ff559ba1374baf47","unresolved":false,"context_lines":[{"line_number":79,"context_line":"This is a list of currently known gaps between ML2/OVS and OVN. It might"},{"line_number":80,"context_line":"not be complete."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"- Fragmentation and Jumbo frames support"},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"  * Upstream work to support this in the OVS/OVN code has been completed,"},{"line_number":85,"context_line":"    additional work is required in the networking-ovn repository to enable it."},{"line_number":86,"context_line":""},{"line_number":87,"context_line":"- Port forwarding"},{"line_number":88,"context_line":""}],"source_content_type":"text/x-rst","patch_set":15,"id":"3fa7e38b_9a05fd12","line":85,"range":{"start_line":82,"start_character":0,"end_line":85,"end_character":78},"updated":"2019-10-09 13:05:54.000000000","message":"This should be done by: https://review.opendev.org/#/c/671766/ (tho it\u0027s disabled by default due to a kernel version requirement, see commit message)","commit_id":"00ae32d27a8abacf3545c08ab683cf70912372d6"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"941606f2794a2f94572f1fb9a21ac1baee188d45","unresolved":false,"context_lines":[{"line_number":79,"context_line":"This is a list of currently known gaps between ML2/OVS and OVN. It might"},{"line_number":80,"context_line":"not be complete."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"- Fragmentation and Jumbo frames support"},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"  * Upstream work to support this in the OVS/OVN code has been completed,"},{"line_number":85,"context_line":"    additional work is required in the networking-ovn repository to enable it."},{"line_number":86,"context_line":""},{"line_number":87,"context_line":"- Port forwarding"},{"line_number":88,"context_line":""}],"source_content_type":"text/x-rst","patch_set":15,"id":"3fa7e38b_d5d758ed","line":85,"range":{"start_line":82,"start_character":0,"end_line":85,"end_character":78},"in_reply_to":"3fa7e38b_9a05fd12","updated":"2019-10-16 15:59:45.000000000","message":"Done","commit_id":"00ae32d27a8abacf3545c08ab683cf70912372d6"},{"author":{"_account_id":9531,"name":"liuyulong","display_name":"LIU Yulong","email":"i@liuyulong.me","username":"LIU-Yulong"},"change_message_id":"c13c89d9ae6001e0a9923b9d923b615988cd665e","unresolved":false,"context_lines":[{"line_number":106,"context_line":""},{"line_number":107,"context_line":"  * Currently ML2/OVS supports QoS DSCP tagging and egress bandwidth limiting."},{"line_number":108,"context_line":"    Those are basic QoS features that while integrated in the OVS/OVN C core"},{"line_number":109,"context_line":"    are not integrated (or fully tested) in the neutron OVN mechanism driver."},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"- BGP support"},{"line_number":112,"context_line":""}],"source_content_type":"text/x-rst","patch_set":15,"id":"3fa7e38b_ff24fc0e","line":109,"range":{"start_line":109,"start_character":56,"end_line":109,"end_character":59},"updated":"2019-10-11 08:40:15.000000000","message":"This is for QoS only.\nQoS \u0027meter\u0027 needs a higher kernel version or user space datapath. Which does not meet current neutron features of QoS for L2 and L3.","commit_id":"00ae32d27a8abacf3545c08ab683cf70912372d6"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"a15a886d24404c9b4c33b1bcf5384f1fbdd41632","unresolved":false,"context_lines":[{"line_number":106,"context_line":""},{"line_number":107,"context_line":"  * Currently ML2/OVS supports QoS DSCP tagging and egress bandwidth limiting."},{"line_number":108,"context_line":"    Those are basic QoS features that while integrated in the OVS/OVN C core"},{"line_number":109,"context_line":"    are not integrated (or fully tested) in the neutron OVN mechanism driver."},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"- BGP support"},{"line_number":112,"context_line":""}],"source_content_type":"text/x-rst","patch_set":15,"id":"3fa7e38b_65a676ae","line":109,"range":{"start_line":109,"start_character":56,"end_line":109,"end_character":59},"in_reply_to":"3fa7e38b_a8b3370a","updated":"2019-10-24 18:53:48.000000000","message":"Done","commit_id":"00ae32d27a8abacf3545c08ab683cf70912372d6"},{"author":{"_account_id":9531,"name":"liuyulong","display_name":"LIU Yulong","email":"i@liuyulong.me","username":"LIU-Yulong"},"change_message_id":"1795d7d17bebe8caaf2c59aed878722d3461e7d4","unresolved":false,"context_lines":[{"line_number":106,"context_line":""},{"line_number":107,"context_line":"  * Currently ML2/OVS supports QoS DSCP tagging and egress bandwidth limiting."},{"line_number":108,"context_line":"    Those are basic QoS features that while integrated in the OVS/OVN C core"},{"line_number":109,"context_line":"    are not integrated (or fully tested) in the neutron OVN mechanism driver."},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"- BGP support"},{"line_number":112,"context_line":""}],"source_content_type":"text/x-rst","patch_set":15,"id":"3fa7e38b_a8b3370a","line":109,"range":{"start_line":109,"start_character":56,"end_line":109,"end_character":59},"in_reply_to":"3fa7e38b_f54054a4","updated":"2019-10-19 11:31:55.000000000","message":"- QoS for Layer 3 IPs\n\n * Currently neutron supports floating IP and gateway IP bandwidth limiting based on Linux TC. The networking-ovn has a on-going implementation [x] based on the meter of openvswitch [y] utilities which is supported in user spece datapath only or kernel version 4.15+ [z].\n\n[x] https://review.opendev.org/#/c/539826/\n[y] https://github.com/openvswitch/ovs/commit/66d89287269ca7e2f7593af0920e910d7f9bcc38\n[z] https://github.com/torvalds/linux/blob/master/net/openvswitch/meter.h","commit_id":"00ae32d27a8abacf3545c08ab683cf70912372d6"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"941606f2794a2f94572f1fb9a21ac1baee188d45","unresolved":false,"context_lines":[{"line_number":106,"context_line":""},{"line_number":107,"context_line":"  * Currently ML2/OVS supports QoS DSCP tagging and egress bandwidth limiting."},{"line_number":108,"context_line":"    Those are basic QoS features that while integrated in the OVS/OVN C core"},{"line_number":109,"context_line":"    are not integrated (or fully tested) in the neutron OVN mechanism driver."},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"- BGP support"},{"line_number":112,"context_line":""}],"source_content_type":"text/x-rst","patch_set":15,"id":"3fa7e38b_f54054a4","line":109,"range":{"start_line":109,"start_character":56,"end_line":109,"end_character":59},"in_reply_to":"3fa7e38b_ff24fc0e","updated":"2019-10-16 15:59:45.000000000","message":"Did you want to supply some text?  Or can I just leave this as the spec wasn\u0027t going to go into detail on everything.","commit_id":"00ae32d27a8abacf3545c08ab683cf70912372d6"},{"author":{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},"change_message_id":"47fb026771cd4b51913c9a113e3a97f582178175","unresolved":false,"context_lines":[{"line_number":107,"context_line":"  * Currently ML2/OVS supports QoS DSCP tagging and egress bandwidth limiting."},{"line_number":108,"context_line":"    Those are basic QoS features that while integrated in the OVS/OVN C core"},{"line_number":109,"context_line":"    are not integrated (or fully tested) in the neutron OVN mechanism driver."},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"- BGP support"},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"  * Currently ML2/OVS supports making a tenant subnet routable via BGP, and"}],"source_content_type":"text/x-rst","patch_set":15,"id":"3fa7e38b_f93d462c","line":110,"updated":"2019-10-07 17:56:39.000000000","message":"Question: shall we add here the support for guaranteed minimum bandwidth allocation?\nsee: https://specs.openstack.org/openstack/neutron-specs/specs/rocky/minimum-bandwidth-allocation-placement-api.html, as that is not working with agentless technologies such as networking-ovn.","commit_id":"00ae32d27a8abacf3545c08ab683cf70912372d6"},{"author":{"_account_id":8313,"name":"Lajos Katona","display_name":"lajoskatona","email":"katonalala@gmail.com","username":"elajkat","status":"Ericsson Software Technology"},"change_message_id":"92f55ae8fac2d2e36bb5e665549887a8bc06e3bd","unresolved":false,"context_lines":[{"line_number":107,"context_line":"  * Currently ML2/OVS supports QoS DSCP tagging and egress bandwidth limiting."},{"line_number":108,"context_line":"    Those are basic QoS features that while integrated in the OVS/OVN C core"},{"line_number":109,"context_line":"    are not integrated (or fully tested) in the neutron OVN mechanism driver."},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"- BGP support"},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"  * Currently ML2/OVS supports making a tenant subnet routable via BGP, and"}],"source_content_type":"text/x-rst","patch_set":15,"id":"3fa7e38b_379e7bb8","line":110,"in_reply_to":"3fa7e38b_2fff1068","updated":"2019-10-08 08:54:09.000000000","message":"Thanks, I am ok with it, I was not sure if the goal here is to list all the gaps, or just highlighting areas or groups of gaps.","commit_id":"00ae32d27a8abacf3545c08ab683cf70912372d6"},{"author":{"_account_id":4187,"name":"Ryan Tidwell","email":"rtidwell@suse.com","username":"ryan-tidwell"},"change_message_id":"bc0ff5e0387409273df49164eb80422f7c1da13d","unresolved":false,"context_lines":[{"line_number":107,"context_line":"  * Currently ML2/OVS supports QoS DSCP tagging and egress bandwidth limiting."},{"line_number":108,"context_line":"    Those are basic QoS features that while integrated in the OVS/OVN C core"},{"line_number":109,"context_line":"    are not integrated (or fully tested) in the neutron OVN mechanism driver."},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"- BGP support"},{"line_number":112,"context_line":""},{"line_number":113,"context_line":"  * Currently ML2/OVS supports making a tenant subnet routable via BGP, and"}],"source_content_type":"text/x-rst","patch_set":15,"id":"3fa7e38b_2fff1068","line":110,"in_reply_to":"3fa7e38b_f93d462c","updated":"2019-10-07 19:43:52.000000000","message":"I think there are a number of features where we don\u0027t have parity. It\u0027s not my intention to enumerate every last one in this spec as that could be a bit of a moving target. What I hope is clear is that we intend to close these gaps before deprecating ML2+OVS.\n\nSo to answer this specific question, I\u0027m fine with not calling it out specifically. But this is one of many features that we need to ensure is supported by the OVN plugin.","commit_id":"00ae32d27a8abacf3545c08ab683cf70912372d6"},{"author":{"_account_id":9531,"name":"liuyulong","display_name":"LIU Yulong","email":"i@liuyulong.me","username":"LIU-Yulong"},"change_message_id":"c13c89d9ae6001e0a9923b9d923b615988cd665e","unresolved":false,"context_lines":[{"line_number":213,"context_line":"      is the best way forward."},{"line_number":214,"context_line":"  * See [12]_ for some historical context and details"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"Configuration Impact"},{"line_number":217,"context_line":"--------------------"},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"N/A"},{"line_number":220,"context_line":""},{"line_number":221,"context_line":"CLI Impact"},{"line_number":222,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":15,"id":"3fa7e38b_bf79a4c5","line":219,"range":{"start_line":216,"start_character":0,"end_line":219,"end_character":3},"updated":"2019-10-11 08:40:15.000000000","message":"IMO, this should be deleted. Maybe someday users may consider the migration does not need any config change.","commit_id":"00ae32d27a8abacf3545c08ab683cf70912372d6"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"941606f2794a2f94572f1fb9a21ac1baee188d45","unresolved":false,"context_lines":[{"line_number":213,"context_line":"      is the best way forward."},{"line_number":214,"context_line":"  * See [12]_ for some historical context and details"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"Configuration Impact"},{"line_number":217,"context_line":"--------------------"},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"N/A"},{"line_number":220,"context_line":""},{"line_number":221,"context_line":"CLI Impact"},{"line_number":222,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":15,"id":"3fa7e38b_15fbb078","line":219,"range":{"start_line":216,"start_character":0,"end_line":219,"end_character":3},"in_reply_to":"3fa7e38b_bf79a4c5","updated":"2019-10-16 15:59:45.000000000","message":"Done","commit_id":"00ae32d27a8abacf3545c08ab683cf70912372d6"},{"author":{"_account_id":13686,"name":"Frode Nordahl","email":"fnordahl@ubuntu.com","username":"fnordahl"},"change_message_id":"1c024cfffcc54fa38542ccf5dd32a30f062aa290","unresolved":false,"context_lines":[{"line_number":190,"context_line":"    distributed ingress/egress for IPv4 and IPv6."},{"line_number":191,"context_line":"  * Compatibility with neutron-dynamic-routing for routing directly to tenant"},{"line_number":192,"context_line":"    networks [13]_."},{"line_number":193,"context_line":"  * In a completely de-centralized deployment, a router as a logical construct"},{"line_number":194,"context_line":"    doesn\u0027t need to be thought of as \"HA\" or \"distributed\" as it is inherently"},{"line_number":195,"context_line":"    both by virtue of being instantiated on each compute node."},{"line_number":196,"context_line":""},{"line_number":197,"context_line":"- Distributed SNAT"},{"line_number":198,"context_line":""}],"source_content_type":"text/x-rst","patch_set":16,"id":"3fa7e38b_9d84b05f","line":195,"range":{"start_line":193,"start_character":4,"end_line":195,"end_character":62},"updated":"2019-11-03 08:28:01.000000000","message":"While this sounds good on paper and from the point of view of a hypervisor getting rid of its traffic as soon as possible, it is important to think about the implications of doing so for the physical data center network.\n\nIn any data center you will find that there is only two or three physical locations where traffic enters or exits through border gateways. The traffic has to be transported there somehow.\n\nOVN and networking-ovn has an elegant solution to this today where only chassis with proper bridge mappings are selected for gateway routers.  This way you can enable all chassis which are actually located in the vicinity of your border gateways to act as gateways.  The chassis located elsewhere do not need direct connection to the external network, as they will tunnel any external traffic to a chassis that acts as a gateway.  This plays nicely with Layer3-only data center fabrics (as exemplified by RFC 7938).\n\nAnd please note that the chassis acting as gateways are of course not dedicated to this purpose, they still host instances and do other work as every other node in the cluster.\n\nAs it stands this behavior of OVN and networking-ovn is a huge gain over the existing ML2/OVS DVR solution, so please do not loose that in merging the projects.\n\nThe current Neutron ML2/OVS DVR setup offloads this job to the physical network by requiring every hypervisor in the cluster to have direct external connectivity.\n\nThe only way for the physical network to cope with it is to either create a globally shared Layer2 network for external connectivity or configure tunneling on the physical network equipment.  Neither of these solutions are desirable.","commit_id":"7867fc93e290b17a5eb5ee634208f7af81d27ef9"},{"author":{"_account_id":6854,"name":"YAMAMOTO Takashi","email":"yamamoto@midokura.com","username":"yamamoto"},"change_message_id":"6b85358b72cfa333f8d3f1cb76e461d0312a26cc","unresolved":false,"context_lines":[{"line_number":49,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"To address the issues previously discussed, the ML2+OVS+DVR solution will be"},{"line_number":52,"context_line":"merged with the networking-ovn solution. As a desired end state, neutron will"},{"line_number":53,"context_line":"have OVN as its reference ML2 plugin for OVS-based environments. This has the"},{"line_number":54,"context_line":"following benefits:"},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"- Neutron can take advantage of the control plane performance optimizations"}],"source_content_type":"text/x-rst","patch_set":17,"id":"3fa7e38b_6b8463d4","line":53,"range":{"start_line":52,"start_character":41,"end_line":53,"end_character":63},"updated":"2019-11-07 01:05:24.000000000","message":"does this mean, for example, if i want to expose a midonet feature via neutron api, i will need to implement it in ovn first?","commit_id":"3e14978270732eef2b9f6d351905e37860999983"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"593486c0f4118b3f8e057c6d2da02b3599264e98","unresolved":false,"context_lines":[{"line_number":49,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"To address the issues previously discussed, the ML2+OVS+DVR solution will be"},{"line_number":52,"context_line":"merged with the networking-ovn solution. As a desired end state, neutron will"},{"line_number":53,"context_line":"have OVN as its reference ML2 plugin for OVS-based environments. This has the"},{"line_number":54,"context_line":"following benefits:"},{"line_number":55,"context_line":""},{"line_number":56,"context_line":"- Neutron can take advantage of the control plane performance optimizations"}],"source_content_type":"text/x-rst","patch_set":17,"id":"3fa7e38b_a4fe4535","line":53,"range":{"start_line":52,"start_character":41,"end_line":53,"end_character":63},"in_reply_to":"3fa7e38b_6b8463d4","updated":"2019-11-22 14:46:28.000000000","message":"Yamamoto - no, I think that would be a regression in how neutron is supposed to be pluggable.  The intention in the desire to change the default is to do initial feature development in OVN, then in ML2/OVS, reverse of what is done today.","commit_id":"3e14978270732eef2b9f6d351905e37860999983"},{"author":{"_account_id":4694,"name":"Miguel Lavalle","email":"miguel@mlavalle.com","username":"minsel"},"change_message_id":"a424b8c2bc4aab2363dc17e520ecbfd17d868d1a","unresolved":false,"context_lines":[{"line_number":111,"context_line":""},{"line_number":112,"context_line":"- QoS for Layer 3 IPs"},{"line_number":113,"context_line":""},{"line_number":114,"context_line":" * Currently ML2/OVS supports floating IP and gateway IP bandwidth limiting"},{"line_number":115,"context_line":"   based on Linux TC. Networking-ovn has a prototype implementation [4]_ based"},{"line_number":116,"context_line":"   on the meter of openvswitch [5]_ utility, which is supported in user space"},{"line_number":117,"context_line":"   datapath only, or kernel versions 4.15+ [6]_."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"- BGP support"},{"line_number":120,"context_line":""}],"source_content_type":"text/x-rst","patch_set":17,"id":"3fa7e38b_92e00bce","line":117,"range":{"start_line":114,"start_character":1,"end_line":117,"end_character":48},"updated":"2019-11-05 08:05:19.000000000","message":"This paragraph was rendered a little bit weirdly: https://openstack.fortnebula.com:13808/v1/AUTH_e8fd161dc34c421a979a9e6421f823e9/zuul_opendev_logs_918/658414/17/check/openstack-tox-docs/918f38b/docs/specs/ussuri/ml2ovs-ovn-convergence.html#feature-gap-analysis. To fix it, the entire paragraph needs to be shifted one position to the right","commit_id":"3e14978270732eef2b9f6d351905e37860999983"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"593486c0f4118b3f8e057c6d2da02b3599264e98","unresolved":false,"context_lines":[{"line_number":111,"context_line":""},{"line_number":112,"context_line":"- QoS for Layer 3 IPs"},{"line_number":113,"context_line":""},{"line_number":114,"context_line":" * Currently ML2/OVS supports floating IP and gateway IP bandwidth limiting"},{"line_number":115,"context_line":"   based on Linux TC. Networking-ovn has a prototype implementation [4]_ based"},{"line_number":116,"context_line":"   on the meter of openvswitch [5]_ utility, which is supported in user space"},{"line_number":117,"context_line":"   datapath only, or kernel versions 4.15+ [6]_."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"- BGP support"},{"line_number":120,"context_line":""}],"source_content_type":"text/x-rst","patch_set":17,"id":"3fa7e38b_6e16c05b","line":117,"range":{"start_line":114,"start_character":1,"end_line":117,"end_character":48},"in_reply_to":"3fa7e38b_92e00bce","updated":"2019-11-22 14:46:28.000000000","message":"Done","commit_id":"3e14978270732eef2b9f6d351905e37860999983"},{"author":{"_account_id":6854,"name":"YAMAMOTO Takashi","email":"yamamoto@midokura.com","username":"yamamoto"},"change_message_id":"6b85358b72cfa333f8d3f1cb76e461d0312a26cc","unresolved":false,"context_lines":[{"line_number":154,"context_line":"Developer Impact"},{"line_number":155,"context_line":"----------------"},{"line_number":156,"context_line":""},{"line_number":157,"context_line":"- Move networking-ovn code to neutron repo and treat OVN as an in-tree driver"},{"line_number":158,"context_line":""},{"line_number":159,"context_line":"  * Moving networking-ovn into the neutron repository is the first step toward"},{"line_number":160,"context_line":"    supporting convergence."}],"source_content_type":"text/x-rst","patch_set":17,"id":"3fa7e38b_8b751f03","line":157,"range":{"start_line":157,"start_character":0,"end_line":157,"end_character":77},"updated":"2019-11-07 01:05:24.000000000","message":"is this really necessary?\npulling networking-ovn\u0027s requirements might not be a good idea.","commit_id":"3e14978270732eef2b9f6d351905e37860999983"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"593486c0f4118b3f8e057c6d2da02b3599264e98","unresolved":false,"context_lines":[{"line_number":154,"context_line":"Developer Impact"},{"line_number":155,"context_line":"----------------"},{"line_number":156,"context_line":""},{"line_number":157,"context_line":"- Move networking-ovn code to neutron repo and treat OVN as an in-tree driver"},{"line_number":158,"context_line":""},{"line_number":159,"context_line":"  * Moving networking-ovn into the neutron repository is the first step toward"},{"line_number":160,"context_line":"    supporting convergence."}],"source_content_type":"text/x-rst","patch_set":17,"id":"3fa7e38b_e4819dc3","line":157,"range":{"start_line":157,"start_character":0,"end_line":157,"end_character":77},"in_reply_to":"3fa7e38b_8b751f03","updated":"2019-11-22 14:46:28.000000000","message":"We talked about this at the PTG and agreed to go forward with moving the code.  When we start proposing patches we\u0027ll be able to see the scope of any new requirements and can revisit this discussion there.","commit_id":"3e14978270732eef2b9f6d351905e37860999983"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6267dde4f935de14f4de1427fcad64ded0f72f5a","unresolved":false,"context_lines":[{"line_number":73,"context_line":"procedural and technical aspects of the convergence of ML2+OVS+DVR and"},{"line_number":74,"context_line":"networking-ovn."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Feature Gap Analysis"},{"line_number":77,"context_line":"--------------------"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"This is a list of currently known gaps between ML2/OVS and OVN. It might"}],"source_content_type":"text/x-rst","patch_set":18,"id":"3fa7e38b_80945237","line":76,"range":{"start_line":76,"start_character":0,"end_line":76,"end_character":20},"updated":"2019-11-22 16:58:04.000000000","message":"there are other feature gaps when it comes to ovn supprot\nsuch as hardware offloaded ovs and ovs-dpdk\n\novn claims supprot for ovs-dpdk but its not to partiy with ml2/ovs and i dont think hardware offloaded ovs is supported offically at all.\n\nim not sure if trunk ports/vlan aware vms is supprot with ovn\nor vlan transparte networks either?","commit_id":"2420d1834e7ba4981c02e60ab14cf690e14447c8"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"33a0b97341795966f123b8071541da213e004429","unresolved":false,"context_lines":[{"line_number":73,"context_line":"procedural and technical aspects of the convergence of ML2+OVS+DVR and"},{"line_number":74,"context_line":"networking-ovn."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Feature Gap Analysis"},{"line_number":77,"context_line":"--------------------"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"This is a list of currently known gaps between ML2/OVS and OVN. It might"}],"source_content_type":"text/x-rst","patch_set":18,"id":"3fa7e38b_a18cde34","line":76,"range":{"start_line":76,"start_character":0,"end_line":76,"end_character":20},"in_reply_to":"3fa7e38b_46a0a0f3","updated":"2019-11-25 16:42:08.000000000","message":"hardware offloaded ovs been supported in ml2/ovs for 2-3 release at this point.\nit looks like ovn might have basic hardware offload ovs support https://opendev.org/openstack/networking-ovn/commit/621e3a4700564a0c493673b4086d158de5fde9d5 but that would not work with geneve as far as im aware(i dont think mellonox have genve hardware encap/decap support but the might) and im not sure how much of ovns flows will be offloaded.\n\nthe networking-ovn ml2 driver used to use vhost user in client mode which  was problematic. \n\nit looks like that got fianlly fixed\nhttps://opendev.org/openstack/networking-ovn/commit/5cbfbe6782e2b7d7b75d4be6c339ce80b1099a4e\n\nthe commit message is slightly missleadign as it talking about server/client form the point of view of ovs not qemu.\n\nthat change make qemu the server and ovs the client wich allows reconnect the vswitch to the vms if its rebooted\nwithout it a minor update of ovs would resullt in a lack of network conenctivy to all vms requiring them to be rebooted to restore it.\n\nits not clear the different qos policys that work in ml2/ovs with ovs-dpdk are supported by ovn as egress and ingress max limits work slighly different with ovs-dpdk","commit_id":"2420d1834e7ba4981c02e60ab14cf690e14447c8"},{"author":{"_account_id":23804,"name":"Daniel Alvarez","email":"dalvarez@redhat.com","username":"dalvarez"},"change_message_id":"f5dd1c8e4ca649e181ed72ef8881c5e7aaecd89b","unresolved":false,"context_lines":[{"line_number":73,"context_line":"procedural and technical aspects of the convergence of ML2+OVS+DVR and"},{"line_number":74,"context_line":"networking-ovn."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Feature Gap Analysis"},{"line_number":77,"context_line":"--------------------"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"This is a list of currently known gaps between ML2/OVS and OVN. It might"}],"source_content_type":"text/x-rst","patch_set":18,"id":"3fa7e38b_46a0a0f3","line":76,"range":{"start_line":76,"start_character":0,"end_line":76,"end_character":20},"in_reply_to":"3fa7e38b_80945237","updated":"2019-11-25 15:34:58.000000000","message":"trunk ports / vlan aware VMs are supported in OVN and exercised quite heavily by Kuryr.\n\nAbout OVS-DPDK there\u0027s not much from the OVN side aside from supporting the netdev datapath that was solved already in OVN \u003e\u003d 2.12 [0]. The rest is transparent to OVN. Can you confirm this @Numan?\n\nAbout HW offload, I can\u0027t really tell as I don\u0027t know the status of this for ML2/OVS. We can try to cover it more in detail (eg. Geneve offloading is not supported by most (any?) NICs)\n\n\n[0] https://github.com/openvswitch/ovs/commit/8ba510bf794692792e04a9d2813bd6c272a9619a#diff-3551132ea621e16dc066656d6d942d44","commit_id":"2420d1834e7ba4981c02e60ab14cf690e14447c8"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"ac0e410ab5326df0a209e7dae66e643657a93ce5","unresolved":false,"context_lines":[{"line_number":76,"context_line":"Feature Gap Analysis"},{"line_number":77,"context_line":"--------------------"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"This is a list of currently known gaps between ML2/OVS and OVN. It might"},{"line_number":80,"context_line":"not be complete. A TODO list for OVN is located at [2]_."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":"- Fragmentation and Jumbo frames support"},{"line_number":83,"context_line":""}],"source_content_type":"text/x-rst","patch_set":18,"id":"3fa7e38b_e18896c3","line":80,"range":{"start_line":79,"start_character":64,"end_line":80,"end_character":16},"updated":"2019-11-25 16:49:19.000000000","message":"I\u0027ll rewrite this section a little to make it more obvious this isn\u0027t the complete list.","commit_id":"2420d1834e7ba4981c02e60ab14cf690e14447c8"},{"author":{"_account_id":10237,"name":"Numan Siddique","email":"nusiddiq@redhat.com","username":"numansiddique"},"change_message_id":"caf461ca439e4d7c6ca767224ca595f4f254c893","unresolved":false,"context_lines":[{"line_number":92,"context_line":"    FixedIP:PortNumber of a VM, so that different services running in a VM"},{"line_number":93,"context_line":"    can be isolated, and can communicate with external networks easily."},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"  * This is a relatively new extension, support would need to be added to OVN."},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"- Security Groups logging API"},{"line_number":98,"context_line":""}],"source_content_type":"text/x-rst","patch_set":18,"id":"3fa7e38b_c32d7446","line":95,"range":{"start_line":95,"start_character":3,"end_line":95,"end_character":78},"updated":"2019-11-22 17:37:23.000000000","message":"OVN has support for native load balancing. I think that feature can be used here.\n\nOVN load balancer is expressed in OVN northbound load_balancer table. Normally the vip and its members are expressed as [1]:\n\nVIP:PORT \u003d MEMBER1:MPORT1, MEMBER2:MPORT2.\n\nThe same can be extended to this feature as \n\nFIP:FIP_PORT \u003d PRIVATE_IP:PRIV_PORT.\n\n\n[1] - https://github.com/ovn-org/ovn/blob/master/ovn-nb.ovsschema#L148","commit_id":"2420d1834e7ba4981c02e60ab14cf690e14447c8"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"67ca33f9737751b186f55f3c99d3ae960c0d61cc","unresolved":false,"context_lines":[{"line_number":92,"context_line":"    FixedIP:PortNumber of a VM, so that different services running in a VM"},{"line_number":93,"context_line":"    can be isolated, and can communicate with external networks easily."},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"  * This is a relatively new extension, support would need to be added to OVN."},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"- Security Groups logging API"},{"line_number":98,"context_line":""}],"source_content_type":"text/x-rst","patch_set":18,"id":"3fa7e38b_5bd87950","line":95,"range":{"start_line":95,"start_character":3,"end_line":95,"end_character":78},"in_reply_to":"3fa7e38b_c32d7446","updated":"2019-11-25 15:39:41.000000000","message":"thanks Numan, I will add this information here as a reference","commit_id":"2420d1834e7ba4981c02e60ab14cf690e14447c8"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"26d0753a8df34bfcad99d16dcb273fc3aecc5a37","unresolved":false,"context_lines":[{"line_number":115,"context_line":"    based on Linux TC. Networking-ovn has a prototype implementation [4]_ based"},{"line_number":116,"context_line":"    on the meter of openvswitch [5]_ utility, which is supported in user space"},{"line_number":117,"context_line":"    datapath only, or kernel versions 4.15+ [6]_."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"- BGP support"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"  * Currently ML2/OVS supports making a tenant subnet routable via BGP, and"}],"source_content_type":"text/x-rst","patch_set":18,"id":"3fa7e38b_ff1366b6","line":118,"updated":"2019-11-22 15:34:29.000000000","message":"it is missing other qos polices like min bandwith support","commit_id":"2420d1834e7ba4981c02e60ab14cf690e14447c8"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"33a0b97341795966f123b8071541da213e004429","unresolved":false,"context_lines":[{"line_number":115,"context_line":"    based on Linux TC. Networking-ovn has a prototype implementation [4]_ based"},{"line_number":116,"context_line":"    on the meter of openvswitch [5]_ utility, which is supported in user space"},{"line_number":117,"context_line":"    datapath only, or kernel versions 4.15+ [6]_."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"- BGP support"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"  * Currently ML2/OVS supports making a tenant subnet routable via BGP, and"}],"source_content_type":"text/x-rst","patch_set":18,"id":"3fa7e38b_61fee66a","line":118,"in_reply_to":"3fa7e38b_1bcbe152","updated":"2019-11-25 16:42:08.000000000","message":"ok titling it as feature gap analyse implies that it was intended to be and that this was the set of gaps that were identified.","commit_id":"2420d1834e7ba4981c02e60ab14cf690e14447c8"},{"author":{"_account_id":1131,"name":"Brian Haley","email":"haleyb.dev@gmail.com","username":"brian-haley"},"change_message_id":"67ca33f9737751b186f55f3c99d3ae960c0d61cc","unresolved":false,"context_lines":[{"line_number":115,"context_line":"    based on Linux TC. Networking-ovn has a prototype implementation [4]_ based"},{"line_number":116,"context_line":"    on the meter of openvswitch [5]_ utility, which is supported in user space"},{"line_number":117,"context_line":"    datapath only, or kernel versions 4.15+ [6]_."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"- BGP support"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":"  * Currently ML2/OVS supports making a tenant subnet routable via BGP, and"}],"source_content_type":"text/x-rst","patch_set":18,"id":"3fa7e38b_1bcbe152","line":118,"in_reply_to":"3fa7e38b_ff1366b6","updated":"2019-11-25 15:39:41.000000000","message":"This list wasn\u0027t mean to be exhaustive, but I\u0027ll add it since I\u0027m doing an update.","commit_id":"2420d1834e7ba4981c02e60ab14cf690e14447c8"}]}