14:00:32 <liuyulong> #startmeeting neutron_l3
14:00:32 <openstack> Meeting started Wed May 13 14:00:32 2020 UTC and is due to finish in 60 minutes.  The chair is liuyulong. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:35 <openstack> The meeting name has been set to 'neutron_l3'
14:01:04 <liuyulong> #topic Announcements
14:01:14 <liuyulong> #link https://releases.openstack.org/ussuri/index.html
14:01:46 <liuyulong> Ussuri Released today, congratulations!
14:05:11 <liuyulong> #link https://launchpad.net/neutron/ussuri
14:05:34 <liuyulong> Just confirmed the LP ussuri series
14:06:51 <liuyulong> Most of the are fully fixed/implemented.
14:06:53 <liuyulong> #link https://docs.openstack.org/releasenotes/neutron/ussuri.html
14:07:18 <liuyulong> This is the neutron project release note for Ussuri.
14:07:57 <liuyulong> Here are something I'd like to highlight:
14:08:13 <liuyulong> 1) Python 2 is no longer supported, this is the community goal.
14:08:30 <haleyb> hi, sorry i'm late
14:08:53 <liuyulong> 2) The networking-ovn mechanism driver is built-in now in Neutron repo.
14:10:12 <liuyulong> 3) Some long-term bug are fixed now, such as the flooding issue in ovs intergration bridge.
14:10:18 <liuyulong> haleyb, hi
14:11:09 <liuyulong> That's all from me about the information/announcement of the project, thank you all for your contribution to the community!
14:12:09 <liuyulong> I have a long bug list since we have two weeks lack of discussion. So let's move on.
14:12:23 <liuyulong> #topic Bugs
14:12:38 <liuyulong> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014660.html
14:12:46 <liuyulong> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014794.html
14:13:27 <liuyulong> These are the list from bug deputy in last two weeks.
14:13:56 <liuyulong> Thanks to Akihiro and Miguel.
14:13:59 <liuyulong> First one:
14:14:08 <liuyulong> #link  https://bugs.launchpad.net/neutron/+bug/1876092
14:14:08 <openstack> Launchpad bug 1876092 in neutron "DVR with Flat network result in ICMP reply DUP" [Undecided,In progress] - Assigned to yangjianfeng (yangjianfeng)
14:15:38 <liuyulong> This should be a nice enhancement since yangjianfeng has submitted the implementation of the Flat network support for DVR.
14:16:45 <liuyulong> #link https://review.opendev.org/#/c/726044/
14:16:45 <patchbot> patch 726044 - neutron - Make DVR router support FLAT network for ovs-agent - 7 patch sets
14:16:58 <liuyulong> This is the code.
14:17:17 <liuyulong> I have not test the code yet, but I'm OK with the approach.
14:18:03 <liuyulong> So maybe this can be raised to the drivers meeting for more discussion because this is more like a new feature for neutron.
14:19:02 <liuyulong> And another thing should be considered this may introduce a potential gap for OVN and OVS. (I don't know the status of flat network supporting for DVR in OVN deployment)
14:19:42 <liuyulong> Maybe such support can be implemented for OVN as well.
14:20:09 <liuyulong> OK, next one
14:20:11 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1877404
14:20:11 <openstack> Launchpad bug 1877404 in neutron "Add "qos_policy_id" field to "FloatingIP" OVO" [Medium,Fix released] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez)
14:20:11 <haleyb> yes, we could add it to the known gaps, think there's an in-tree doc
14:20:52 <liuyulong> haleyb, pong, +1, np
14:21:12 <liuyulong> This attribute have been added to floating IP。
14:21:37 <liuyulong> #link https://review.opendev.org/#/c/726208/
14:21:38 <patchbot> patch 726208 - neutron - Add "qos_policy_id" field to "FloatingIP" OVO (MERGED) - 4 patch sets
14:22:05 <liuyulong> We are in a efficient team. : )
14:22:40 <haleyb> yes, there is a lot of work getting done :)
14:22:51 <liuyulong> And, mostly, this attribute is for the next bug(rfe):
14:23:17 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1877408
14:23:17 <openstack> Launchpad bug 1877408 in neutron "Implement FIP QoS in OVN backend" [Medium,In progress] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez)
14:23:28 <ralonsoh> I need to address some comments there
14:23:33 <ralonsoh> (sorry for being late)
14:23:47 <ralonsoh> but seems to work
14:24:04 <ralonsoh> # https://review.opendev.org/#/c/722415/
14:24:04 <patchbot> patch 722415 - neutron - [OVN] Implement floating IP QoS in OVN backend - 9 patch sets
14:24:33 <liuyulong> For the qos support for floating IP in OVN, honestly, I've seen at least 3 different implementations. : )
14:25:03 <ralonsoh> I know
14:25:14 <ralonsoh> and, IMO, the other ones do not cover all cases
14:25:27 <ralonsoh> (policy update, port changes, etc)
14:25:49 <liuyulong> #link https://review.opendev.org/#/c/712239/
14:25:50 <patchbot> patch 712239 - neutron - [OVN]floating IP QoS. - 5 patch sets
14:26:30 <liuyulong> ralonsoh, sure, I'm adding myself to the reviewers list
14:27:37 <liuyulong> ralonsoh, so maybe you should inform the others that there are a more proper implementation for them to stop the rotation of their works.
14:27:47 <ralonsoh> liuyulong, I'll do
14:28:04 <ralonsoh> actually I'll tell them to join one single implementation
14:28:12 <ralonsoh> I don't mind which one (I prefer mine)
14:28:15 <ralonsoh> but just one
14:28:29 <ralonsoh> (adding all of them to the coders list)
14:29:22 <liuyulong> OK, cool
14:29:32 <liuyulong> Next
14:29:36 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1877447
14:29:36 <openstack> Launchpad bug 1877447 in neutron "Add TCP/UDP port forwarding extension to OVN" [Wishlist,In progress] - Assigned to Flavio Fernandes (ffernand)
14:29:54 <liuyulong> Filling gaps, so +1 to me
14:30:29 <liuyulong> #link https://review.opendev.org/#/c/723863/
14:30:29 <patchbot> patch 723863 - neutron - WIP (DNM): [ovn]: port forwarding functionality - 15 patch sets
14:30:34 <liuyulong> This is the patch set.
14:31:47 <liuyulong> So I don't this need to be discuss in drivers meeting, we can let it go forward simply and quickly. Because we are efficient. : )
14:32:32 <liuyulong> OK, next
14:32:35 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1876898
14:32:35 <openstack> Launchpad bug 1876898 in neutron "L3 agent should reports enabled extensions to the server" [Low,Fix released] - Assigned to Slawek Kaplonski (slaweq)
14:33:18 <liuyulong> It is fixed and in all stable branches now.
14:33:40 <liuyulong> Thanks to Slawek.
14:34:15 <liuyulong> Last one from the deputy's list:
14:34:17 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1877301
14:34:17 <openstack> Launchpad bug 1877301 in neutron "[RFE] L3 Router support ndp proxy" [Wishlist,Confirmed]
14:35:55 <liuyulong> I may say, few months ago, I bring up the IPv6 topic in the L3 meeting. And this should be talked once.
14:36:55 <haleyb> before we had prefix delegation there was a POC using proxy NDP, I wonder if I can find those patches if it matters
14:37:55 <liuyulong> Found it
14:37:57 <liuyulong> #link http://eavesdrop.openstack.org/meetings/neutron_l3/2019/neutron_l3.2019-09-04-14.00.log.html#l-84
14:38:49 <liuyulong> and this
14:38:50 <liuyulong> #link http://eavesdrop.openstack.org/meetings/neutron_l3/2019/neutron_l3.2019-09-11-14.00.log.html#l-87
14:40:16 <haleyb> that wasn't the patch i was thinking of, i'll have to search
14:40:20 <liuyulong> So basically, this is something mentioned in this spec:
14:40:27 <liuyulong> #link https://review.opendev.org/#/c/139731/2/specs/kilo/ipv6-floatingip.rst
14:40:27 <patchbot> patch 139731 - neutron-specs - Support Floatingip for IPv6 (ABANDONED) - 2 patch sets
14:41:35 <haleyb> yes, we're getting closer, it was Robert that sent the neutron patches
14:42:24 <haleyb> https://review.opendev.org/#/c/143917/
14:42:24 <patchbot> patch 143917 - neutron - A conceptual implementation of neutron DVR (ABANDONED) - 5 patch sets
14:42:49 <liuyulong> Yep
14:43:00 <haleyb> there is some proxy_ndp code in there.  more of a reference
14:46:16 <liuyulong> So according to the use case, this is somewhat like the floating IPv6.
14:46:51 <haleyb> and we've been trying to stay away from IPv6 NAT
14:47:12 <liuyulong> "openstack router add ndp proxy <router_id> --address <ipv6 address>" this is command from the bug.
14:47:36 <liuyulong> It has a some similar input like floating ip.
14:49:13 <haleyb> right, but there is no NAT or conntrack
14:49:19 <liuyulong> Floating IP is set on router's leg, and NAT. This new IPv6 address ndp_proxy is something like, IPv6 address is reachable on the router interface (Neigh Proxy).
14:51:31 <haleyb> yes.  and the assumption is that the upstream router will send a ND for this IPv6 address on the link where this neutron router exists
14:52:26 <haleyb> eg it as a /52 route going to this network, each neutron router using a /64 in it
14:53:22 <liuyulong> Yes, it should have a large IPv6 network plane.
14:53:36 <haleyb> the one problem with this is neighbor table explosion, for example each instance could cause an entry on this upstream router, where with PD there is only one per /64
14:55:16 <haleyb> i know with the bgp way it would be one route per instance, but i thought routers could deal with lots of routes
14:55:23 <liuyulong> I guess the bug may miss a condition which is for those unauthorized IPv6 Address, the external world should be unreachable.
14:56:03 <liuyulong> So, who have this ndp proxy, who will have access from/to the public internet.
14:56:21 <liuyulong> Yes, more like a floating IPv6 again.
14:57:14 <haleyb> today, without proxy NDP or PD, an instance can send IPv6 traffic to the Internet, it just might not receive it.  I don't think we should change that
14:57:31 <haleyb> this is assuming the address scopes, etc are valid
14:57:46 <liuyulong> But from other perspective, for the easy use, this approach could save the operation of the physical router Prefix Delegation/ bgp. It could be simple to use for small cloud deployment.
14:58:28 <haleyb> yes, i think it has a use case there
14:59:27 <liuyulong> So, maybe this can be raised to drivers meeting for further discussion.
14:59:55 <liuyulong> I'm neutral. : )
15:00:29 <haleyb> i'll add more notes to the bug
15:00:39 <liuyulong> OK, we are out of time.
15:00:48 <liuyulong> Thank you guys for attending.
15:00:53 <liuyulong> #endmeeting