14:01:45 #startmeeting neutron_l3 14:01:45 Meeting started Wed Apr 7 14:01:45 2021 UTC and is due to finish in 60 minutes. The chair is liuyulong. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:47 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:49 The meeting name has been set to 'neutron_l3' 14:02:43 After reading the bug list, IMO, there were two quiet weeks. 14:03:07 Let's start 14:03:15 #topic Bugs 14:03:22 #link http://lists.openstack.org/pipermail/openstack-discuss/2021-March/021375.html 14:03:27 #link http://lists.openstack.org/pipermail/openstack-discuss/2021-April/021613.html 14:04:05 First one 14:04:05 hi 14:04:07 #link https://bugs.launchpad.net/neutron/+bug/1920975 14:04:08 Launchpad bug 1920975 in neutron "neutron dvr should lower proxy_delay when using proxy_arp" [Medium,In progress] - Assigned to Edward Hope-Morley (hopem) 14:04:20 #link https://review.opendev.org/c/openstack/neutron/+/782570 14:04:28 ^^ It has a patch here. 14:04:46 I left some comments, but no response for now. 14:05:25 Make the constant name more accurate. 14:06:07 But my final idea is to hide that kernel algorithm, all we want is to delay no longer than 50ms. 14:06:54 But the unit jiffies is not fixed value. 14:07:03 It is based on the kernel config of HZ. 14:07:20 (^^ a long story, please take a look at https://github.com/torvalds/linux/blob/master/include/linux/jiffies.h) 14:07:22 * slaweq will be back in few minutes 14:07:41 So, let's  wait until the author's response. 14:09:05 Next 14:09:10 #link https://bugs.launchpad.net/neutron/+bug/1922653 14:09:11 Launchpad bug 1922653 in neutron "[L3][Port forwarding] multiple floating_ip:port to same internal fixed_ip:port (N-to-1 rule support)" [Undecided,New] 14:09:19 It was reported by me. 14:09:43 This is coming from our customers, they want to set such N-1 rules. 14:09:53 But it is not available for neutron now. 14:10:44 After some deep looking at this constraint, IMO, it is a bit rigid. 14:11:08 We can remove that constraint for multiple floating_ip:port to same internal fixed_ip:port. 14:11:51 My local testing shows that all works fine. It will be a quite simple change of DB migration script only. 14:12:21 No real code change needed for  L3 DB, port forwarding plugin and L3 agent. 14:12:52 OK, no more bugs from me now. 14:13:01 But, we have some RFEs. 14:13:13 #topic L3_RFEs 14:13:54 #link https://bugs.launchpad.net/neutron/+bug/1921126 14:13:58 Launchpad bug 1921126 in neutron "[RFE] Allow explicit management of default routes" [Wishlist,New] - Assigned to Bence Romsics (bence-romsics) 14:14:11 It was approved, and the spec has been uploaded. 14:14:39 #link https://review.opendev.org/c/openstack/neutron-specs/+/781475 14:15:10 Looks good to me now, just some questions about how to deal with the original default route. 14:15:43 It can be used to fix the bug https://bugs.launchpad.net/neutron/+bug/1901992 14:15:44 Launchpad bug 1901992 in neutron "Original default route in DVR SNAT namespace is not recovered after creating and deleting /0 extraroute" [Medium,Triaged] - Assigned to gao yu (gaoyublack) 14:17:05 Next 14:17:07 #link https://bugs.launchpad.net/neutron/+bug/1921461 14:17:08 Launchpad bug 1921461 in neutron "[RFE] Enhancement to Neutron BGPaaS to directly support Neutron Routers & bgp-peering from such routers over internal & external Neutron Networks" [Undecided,New] 14:17:48 It is BGP related request for neutron router, the spec is here: https://review.opendev.org/c/openstack/neutron-specs/+/783791 14:20:07 It looks like the neutron router will run BGP daemons after this. 14:20:51 Something like neutron-dynamic-routing agent do, maybe this can be achived by this: 14:21:44 1. Add API to neutron like this spec described 14:21:52 It's a huge topic, and perhaps it can be later cut to smaller specs 14:22:39 2. Let the L3 agent and the bgp-dr-agent has some interact to learn/broadcast the routes. 14:22:58 lajoskatona, yes, it is 14:24:24 For now, based on the spec, I may say the request has many functions similar to neutron-dynamic-routing. 14:25:03 exactly, I am not sure that all can fit to ndr code base or some core Neutron changes are necessary for it 14:25:30 So let's wait and comment the spec until it get sharping. 14:26:06 Not sure if it was discussed on drivers meeting 14:26:21 perhaps it was not due to Easter time 14:26:29 Yes, no response in LP for now. 14:26:32 so there it can have some more feedback 14:27:02 OK, next one, https://bugs.launchpad.net/neutron/+bug/1922716, it looks duplicated to https://bugs.launchpad.net/neutron/+bug/1907089 14:27:05 Launchpad bug 1922716 in neutron "[RFE] BFD for BGP Dynamic Routing" [Undecided,New] 14:27:06 Launchpad bug 1907089 in neutron "[RFE] Add BFD support for Neutron" [Wishlist,New] - Assigned to Lajos Katona (lajos-katona) 14:27:37 Yeah BFD for BGP is from Manu as well (He is from Ericsson/EST as well) 14:28:13 So maybe you guys can share some thoughts during the PTG. :) 14:28:13 For BFD support in neutron I am working on to have a working prototype, but I think that is now independent of the proposed API in the spec 14:28:37 yeah, I plan to add section to the etherpad and ask Manu as well to join :-) 14:29:42 Cool 14:31:10 One note, the real use case is essential for this proposal. Manu's idea, IMO, is to monitor the BGP routes. 14:31:23 Your spec is now for ECMP routes? 14:31:55 But, basically, all for L3 router's route entries. 14:32:04 not just ECMP, but for extra/static routes 14:32:34 yes as You say 14:33:57 OK, no more RFEs from me now. 14:34:17 #topic On demand agenda 14:34:33 #link https://review.opendev.org/q/topic:%22bp%252Fdistributed-dhcp-for-ml2-ovs%22+(status:open%20OR%20status:merged) 14:35:26 slaweq, hi, I guess no feature freeze now, could please remove the -2 for these series of patches. 14:35:44 +1 14:35:51 liuyulong: sure, I will do it in about 20 minutes 14:35:55 I'm in the meeting now 14:36:55 OK, cool. 14:39:35 Alright, let's end here. Have a nice day guys. 14:39:39 Bye 14:39:46 #endmeeting