14:00:27 <liuyulong> #startmeeting neutron_l3
14:00:27 <openstack> Meeting started Wed Jul 29 14:00:27 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:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:30 <openstack> The meeting name has been set to 'neutron_l3'
14:01:13 <ralonsoh> hi
14:01:19 <liuyulong> Hi
14:01:37 <liuyulong> OK, let's start.
14:01:38 <liuyulong> #topic Announcements
14:01:44 <liuyulong> #link http://eavesdrop.openstack.org/#Neutron_L3_Sub-team_Meeting
14:01:49 <liuyulong> #link https://review.opendev.org/#/c/741876/2/meetings/neutron-l3-sub-team-meeting.yaml
14:01:49 <patchbot> patch 741876 - opendev/irc-meetings - Change Neutron L3 Sub-team Meeting frequency (MERGED) - 2 patch sets
14:02:18 <liuyulong> I changed the L3 meetign frequency last week.
14:03:01 <slaweq> hi
14:03:01 <liuyulong> We will have it in every two weeks officially.
14:03:19 <liuyulong> slaweq, hi
14:03:56 * slaweq is updating calendar right now
14:05:13 * slaweq has calendar updated already :)
14:05:36 <liuyulong> The irc channel and the time slot are as usual, so it looks good for me now. : )
14:06:30 <liuyulong> I should send a new email to the mail list. Will do that later.
14:06:39 <liuyulong> OK, no more things from me now.
14:06:55 <liuyulong> Next topic
14:07:14 <liuyulong> #topic Bugs
14:07:29 <liuyulong> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-July/016112.html
14:07:34 <liuyulong> #link http://lists.openstack.org/pipermail/openstack-discuss/2020-July/016002.html
14:08:20 <liuyulong> We have 2 bug lists since we have bi-weekly meeting.
14:08:45 <liuyulong> Firstly, two bugs related to IPv6
14:09:03 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1888256
14:09:04 <openstack> Launchpad bug 1888256 in neutron "Neutron start radvd and mess up the routing table when: ipv6_ra_mode=not set ipv6-address-mode=slaac" [Undecided,New]
14:10:16 <liuyulong> The use case is a bit strange to me, they start a shared network with public IPv4/v6 address.
14:10:25 <liuyulong> Then directly create instance in it.
14:11:22 <liuyulong> In order to achive the metadata HA, they choose HA router related data path.
14:12:31 <liuyulong> So IMO, this case should be changed like this:
14:13:00 <liuyulong> 1. stop using the neutron router, and move the gateway to the physical world (router).
14:14:17 <liuyulong> 2. metadata data-path can be achived by dhcp namespace, DHCP instance (namespace and related process) has the auto-reschedule mechanism for the dead agent.
14:15:12 <ralonsoh> is it possible to reschedule the metadata agent to use the DHCP instead of the router?
14:16:52 <slaweq> ralonsoh: I think You need to enable isolated metadata on dhcp agent's side
14:17:05 <slaweq> ralonsoh: but I'm not sure now exactly
14:17:18 <liuyulong> 3. let the physical router send the NA out
14:17:33 <liuyulong> sorry, a bit bad network traffic...
14:18:08 <ralonsoh> that's the point, I don't know if you can do this once the agent is running in the router
14:18:11 <liuyulong> ralonsoh, for the existing VMs, they may need to change the 169.254.169.254 route rule in the VM.
14:18:54 <ralonsoh> that's done during the VM boot process
14:20:08 <slaweq> but my question is: what is exact purpose of "ipv6_ra_mode=None"?
14:20:18 <slaweq> should radvd be run in such case?
14:20:56 <ralonsoh> yes
14:21:21 <ralonsoh> no no, ipv6-address-mode=slaac and ipv6_ra_mode=not set
14:21:26 <ralonsoh> The instance receives an IPv6 address from the external router (not managed by OpenStack Networking) using SLAAC.
14:21:31 <ralonsoh> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_openstack_platform/7/html/networking_guide/sec-ipv6
14:22:04 <slaweq> ralonsoh: so why we run radvd in such case?
14:22:12 <ralonsoh> no idea...
14:22:15 <slaweq> if we wouldn't run it, there wouldn't be problem IMO
14:22:32 <slaweq> as there wouldn't be any process on our side which would inject this bad default route
14:22:39 <liuyulong> yes, no Neutron router should be added to this case
14:23:02 <ralonsoh> according to this document (similar to the OpenStack documentation)
14:23:12 <ralonsoh> when ipv6_ra_mode=not set, we don't use radvd
14:24:25 <slaweq> ralonsoh: so that seems for me like RC of this issue
14:24:26 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1888256/comments/7
14:24:27 <openstack> Launchpad bug 1888256 in neutron "Neutron start radvd and mess up the routing table when: ipv6_ra_mode=not set ipv6-address-mode=slaac" [Undecided,New]
14:24:51 <liuyulong> according to this comment, seems that "AdvSendAdvert on;" is always available.
14:25:36 <slaweq> but IMO we shouldn't have this section:
14:25:37 <liuyulong> It is hard code.
14:25:38 <slaweq> interface qr-a6d7ceab-80
14:25:40 <slaweq> {
14:25:40 <liuyulong> #link https://github.com/openstack/neutron/blob/8c80267bb6699c86e10aade13c54b715e1eae1bf/neutron/agent/linux/ra.py#L41
14:25:42 <slaweq> AdvSendAdvert on;
14:25:44 <slaweq> MinRtrAdvInterval 30;
14:25:46 <slaweq> MaxRtrAdvInterval 100;
14:25:48 <slaweq> AdvLinkMTU 1500;
14:25:50 <slaweq> };
14:25:57 <slaweq> in the radvd.conf at all if subnet is configured like that one in LP
14:26:07 <liuyulong> #link https://github.com/openstack/neutron/blob/master/neutron/agent/linux/ra.py#L41
14:26:12 <liuyulong> ^ change to master
14:26:15 <slaweq> so radvd shouldn't even listen on this interface
14:28:09 <liuyulong> I don't know, maybe because it is the gateway.
14:29:40 <liuyulong> This should be changed to as the action 1. "move the gateway to physical router."
14:30:32 <liuyulong> From my personal experiences, for such VLAN shared network, we topically did such work, the gateway will not be set on Neutron router. And there is no Neutron router.
14:31:40 <slaweq> liuyulong: if You want I can take a look into that issue locally and will write a comment and/or propose patch
14:32:35 <liuyulong> slaweq, great, go ahead, it's yours. : )
14:32:41 <slaweq> thx
14:32:51 <liuyulong> #link https://bugs.launchpad.net/neutron/+bug/1888464
14:32:52 <openstack> Launchpad bug 1888464 in neutron "IPv6 PD with DVR does not assign correct snat sg address" [Undecided,New]
14:33:02 <liuyulong> This is the another IPv6 related bug.
14:34:52 <liuyulong> Allow me to clarify the fact first, the sg-dev should have an IPv6 address from users internal subnet.
14:35:04 <liuyulong> While the qg-dev should have an IPv6 address from external network.
14:35:55 <liuyulong> So from the bug description, we can only see there is an IPv6 subnet from the external network.
14:36:10 <ralonsoh> so sg-230491ca-5b should have an internal ipv6 address
14:36:13 <ralonsoh> is that correct?
14:36:28 * slaweq is on another meeting but will be lurking here too
14:36:29 <liuyulong> So maybe this is not a bug, just because the user does not create the IPv6 subnet for there internal network.
14:37:12 <liuyulong> If the internal network has 2 subnet (v4 and v6), there should have two sg-devs.
14:39:06 <liuyulong> So, let me mark it as incomplete for now.
14:40:06 <liuyulong> ralonsoh, IMO, the user was misunderstanding the network topology.
14:40:44 <ralonsoh> I still need to review this part of the code to be 100% sure
14:40:55 <liuyulong> The subnet uuid, router uuid, fip-network uuid does not match at all.
14:41:49 <ralonsoh> you are right
14:42:33 <liuyulong> OK, no more bugs from me now.
14:42:36 <liuyulong> Any updates?
14:42:40 <ralonsoh> nope
14:43:08 <liuyulong> OK, let's move on.
14:43:16 <liuyulong> #topic On demand agenda
14:43:46 <liuyulong> #link https://review.opendev.org/#/c/658511/
14:43:46 <patchbot> patch 658511 - neutron-specs - L3 agent self-service metering - 10 patch sets
14:44:10 <liuyulong> IMO, this was approved before in drivers meeting.
14:44:22 <liuyulong> So, need more attention. : )
14:44:28 <ralonsoh> ok
14:44:44 <liuyulong> #link https://review.opendev.org/#/c/675654/
14:44:45 <patchbot> patch 675654 - neutron - L3 agent metering extension - 7 patch sets
14:44:52 <liuyulong> This is the patch for it.
14:45:02 <liuyulong> Yes, it is still in-progress
14:45:31 <liuyulong> I will continuesly work on this.
14:45:48 <slaweq> liuyulong: I will try to review it this week
14:46:28 <liuyulong> Next one should be this
14:46:29 <liuyulong> #link https://review.opendev.org/#/c/728628/
14:46:30 <patchbot> patch 728628 - neutron-specs - L3 router support ndp proxy - 17 patch sets
14:46:51 <liuyulong> After mine request, I see the author uploaded the POC to gerrit.
14:47:11 <liuyulong> #link https://review.opendev.org/#/c/743142/
14:47:11 <patchbot> patch 743142 - neutron - [WIP][PoC][Server Side] L3 router support ndp proxy - 2 patch sets
14:47:35 <liuyulong> It is all in one, IMO
14:47:52 <liuyulong> The patch is including the agent side change.
14:48:19 <liuyulong> This is good for us to understand the real proposal.
14:48:51 <liuyulong> And the details about the DVR, HA can be found in that as well.
14:49:12 <liuyulong> #link https://review.opendev.org/#/c/729532/
14:49:12 <patchbot> patch 729532 - neutron-specs - L3 router support ecmp - 28 patch sets
14:49:26 <liuyulong> Same work for this one, it also has a POC.
14:49:41 <liuyulong> #link https://review.opendev.org/#/c/743661/
14:49:41 <patchbot> patch 743661 - neutron - L3 router support ECMP - 1 patch set
14:49:46 <ralonsoh> but that wasn't approved
14:50:13 <liuyulong> No?
14:50:20 <liuyulong> I missed that.
14:50:43 <ralonsoh> https://bugs.launchpad.net/neutron/+bug/1880532 is not approved yet
14:50:44 <openstack> Launchpad bug 1880532 in neutron "[RFE]L3 Router should support ECMP" [Wishlist,New] - Assigned to XiaoYu Zhu (honglan0914)
14:51:34 <liuyulong> By the way, thing POC has no control plane related code, just some route related implementation.
14:53:19 <liuyulong> So the reuse of the exsiting route API will be the control method.
14:54:11 <liuyulong> Looks good to me, it will be small and clear.
14:55:05 <liuyulong> Last one
14:55:06 <liuyulong> #link https://review.opendev.org/#/q/topic:ovn/port_forwarding
14:55:46 <liuyulong> OVN port forwarding is good in progress.
14:56:02 <ralonsoh> yes, Flavio is working on this full time
14:57:00 <liuyulong> If anyone is interested, pleae go ahead and do code review.
14:57:07 <liuyulong> Let's narrow down the gaps. : )
14:57:44 <liuyulong> OK, no more things from me now.
14:58:15 <ZhuXiaoYu> https://review.opendev.org/#/c/743661/
14:58:15 <ZhuXiaoYu> Here is the patch
14:58:17 <patchbot> patch 743661 - neutron - L3 router support ECMP - 1 patch set
14:59:09 <liuyulong> ZhuXiaoYu, hi, I've mentioned that. : )
14:59:35 <ZhuXiaoYu> :)
14:59:51 <liuyulong> ZhuXiaoYu, by the way, it will be better if you add some test cases.
15:00:16 <ZhuXiaoYu> OK, I will.
15:00:33 <liuyulong> Alright, time is up.
15:00:34 <liuyulong> Bye
15:00:40 <ralonsoh> bye
15:00:45 <liuyulong> #endmeeting