14:02:50 <liuyulong> #startmeeting neutron_l3
14:02:50 <opendevmeet> Meeting started Wed Aug 11 14:02:50 2021 UTC and is due to finish in 60 minutes.  The chair is liuyulong. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:50 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:50 <opendevmeet> The meeting name has been set to 'neutron_l3'
14:03:04 <lajoskatona> Hi
14:03:34 <liuyulong> Hi
14:03:40 <liuyulong> #topic Announcements
14:04:09 <liuyulong> It has been a long time since last l3 meeting.
14:04:21 <ralonsoh> hi
14:04:54 <liuyulong> We had a one persone L3 meeting last l3 meeting.
14:05:37 <lajoskatona> it's summer time, lots of people on PTO :-)
14:05:56 <liuyulong> So, I wonder if we should merge L3 meeting to the team meeting, since there are #bug section in team meeting.
14:06:12 <liuyulong> And mostly in L3 meeting, we are talking about bugs.
14:06:25 <ralonsoh> we can try that
14:06:51 <lajoskatona> +1 if we can cover the topics there
14:08:06 <liuyulong> OK, I will bring up this to the next team meeting to gather more ACKs.
14:08:28 <liuyulong> OK, let's move on.
14:08:33 <liuyulong> #topic Bugs
14:10:22 <liuyulong> There are too many bug list from last few weeks, so I will not paste it here.
14:10:33 <liuyulong> First one:
14:10:35 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1938191
14:12:06 <liuyulong> I did not try to reproduce this bug. But looks like this is another issue of mixed deployment of compute + dvr_snat.
14:12:34 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1934666
14:12:46 <liuyulong> In this ^ bug, wo marked it is not supported.
14:12:53 <liuyulong> s/wo/we
14:13:15 <ralonsoh> yeah, this is currently not supported
14:13:45 <liuyulong> I will leave this comment to the bug to see if the bug reporter can reconfigure the environment.
14:14:57 <ralonsoh> one qq: why do you think first bug 1938191 is related to "compute + dvr_snat" ?
14:15:06 <ralonsoh> ah, because there is a snat namespace
14:15:34 <liuyulong> Yep
14:17:05 <liuyulong> OK, next one
14:17:05 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1934912
14:17:29 <liuyulong> It has a fix https://review.opendev.org/c/openstack/neutron/+/800059 here.
14:18:07 <liuyulong> But seems there is still a ARP entry scale issue of that code.
14:20:06 <ralonsoh> right, I think we should set a hard limit there and (1) document it and (2) rise an exception if exceeded
14:20:18 <ralonsoh> we cannot set 2**16 or more ARP rules
14:20:21 <ralonsoh> that's crazy
14:20:45 <liuyulong> This is seems not easily to fix.
14:21:06 <liuyulong> So I wonder if linux support ARP proxy for IP range.
14:21:11 <ralonsoh> no
14:21:17 <ralonsoh> I checked that
14:21:22 <ralonsoh> same as for iptables
14:21:36 <ralonsoh> (I mean, something similar to ipsets is not in ARP)
14:21:37 <liuyulong> Alright...
14:22:21 <lajoskatona> the current patch proposes to use ip of cidr if /32 at maximum, that is still one IP
14:22:43 <lajoskatona> so this version is not a harm agains scale of arp entries
14:23:03 <liuyulong> One IP should be fine.
14:23:03 <liuyulong> My thougth is somthing like this.
14:23:06 <lajoskatona> but as I wrote to the spec the api-ref itself has no help what kind of cidr is accepted now
14:23:20 <lajoskatona> /spec/patch/
14:23:27 <liuyulong> ARP proxy of IP range (if support) set on router interface.
14:23:32 <ralonsoh> the patch is creating a loop, adding all IPs in this CIDR
14:23:35 <ralonsoh> if I'm not wrong
14:25:02 <liuyulong> ARP from one router interface to another router interface will be ACKed by the proxy. Add a route for the allowed_address_pair CIDR to the port fixed IP (to CIDR via port fixed_ip).
14:25:50 <liuyulong> Then packets can be send from one subnet to another.
14:26:41 <liuyulong> But this may not work if the router interfaces are from different network with differnet segments.
14:27:02 <liuyulong> Just a idea, may not be right. : )
14:27:49 <ralonsoh> we can't route ARP queries
14:27:51 <liuyulong> Anyway, let's pay attention to the patch work.
14:30:31 <liuyulong_> sorry, lost the connection...
14:30:58 <liuyulong_> Not sure if I can still chair the meeting with this nick name...
14:31:06 <liuyulong_> Next one
14:31:07 <liuyulong_> #link https://bugs.launchpad.net/neutron/+bug/1935764
14:31:18 <liuyulong_> #undo
14:31:22 <liuyulong_> wrong link
14:31:42 <liuyulong_> #link https://bugs.launchpad.net/neutron/+bug/1934948
14:31:50 <liuyulong_> [RFE] refactor of L3 resources update procedure
14:32:12 <liuyulong_> Call for volunteers : )
14:32:26 <ralonsoh> not now, sorry
14:32:55 <liuyulong_> This one should be a huge performance enhancing.
14:33:34 <liuyulong_> For L3 agent, it is retrieving router info data, full data, every time.
14:34:01 <liuyulong_> Even it is a really small action, such as floating IP associate or disassociate.
14:34:42 <liuyulong_> Neutron already has that resource cache layer and related notification mechanism.
14:35:38 <liuyulong_> We can leverage that to make L3 agent resource proccing in a more efficient way.
14:36:05 <liuyulong_> But this cloud be a giant project.
14:36:09 <opendevreview> Terry Wilson proposed openstack/ovsdbapp master: Use setkey for DbSetCommand maps  https://review.opendev.org/c/openstack/ovsdbapp/+/804252
14:37:02 <liuyulong_> Anyone wants to join this, please connact me. Let's kill this monster.
14:38:15 <liuyulong_> OK, no more bugs from me now.
14:38:37 <liuyulong> Any updates?
14:39:06 <liuyulong> OK, let's move on.
14:39:13 <liuyulong> #topic L3_RFEs
14:39:27 <liuyulong> I have one update here.
14:40:04 <liuyulong> Related to the distributed metadata datapath.
14:40:19 <liuyulong> #link https://review.opendev.org/c/openstack/neutron-specs/+/802854
14:40:26 <liuyulong> I have uploaded the spec here ^.
14:40:41 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1933222
14:40:46 <liuyulong> This is the bug link.
14:41:00 <liuyulong> So call for neutron guys to take a look at the spec.
14:41:22 <liuyulong> There is some figure which points the packets pipelines.
14:42:14 <liuyulong> Alright, next section
14:42:16 <liuyulong> #topic On demand agenda
14:42:26 <liuyulong> I have no more things to mention here.
14:42:43 <liuyulong> If you guys have, please go ahead.
14:44:30 <ralonsoh> no thanks
14:45:07 <liuyulong> OK, thank you guys for attending.
14:45:14 <liuyulong> #endmeeting