14:00:27 #startmeeting neutron_drivers 14:00:27 Meeting started Fri Jan 27 14:00:27 2023 UTC and is due to finish in 60 minutes. The chair is ralonsoh. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:27 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:27 The meeting name has been set to 'neutron_drivers' 14:00:29 hello all 14:00:29 o/ 14:00:30 o/ 14:00:35 hi 14:00:56 o/ 14:00:57 hi 14:01:14 hi 14:01:37 o/ 14:01:57 ok, I think we have quorum today 14:02:03 we have one topic in the agenda 14:02:06 #link https://bugs.launchpad.net/neutron/+bug/2002687 14:02:12 [RFE] Active-active L3 Gateway with Multihoming 14:02:20 and dmitriis is here, so please, go on 14:02:35 o/ 14:02:45 The RFE follows the earlier effort to enable multiple gateway ports 14:03:00 but with some augmentations such as having multiple gateway ports on the same network 14:03:12 and enabling ECMP for default routes inferred from subnets automatically 14:03:35 there is an associated spec with more details outlined but I am happy to discuss some of them here 14:04:04 fnordahl and I are focusing on the OVN integration for now to keep the scope limited 14:04:15 The spec: https://review.opendev.org/c/openstack/neutron-specs/+/870030 14:04:21 so the scope is limited to OVN only, right? 14:04:59 ralonsoh: yes, for now we are planning a mixin implementing the new API to be supported only with OVN 14:05:29 but I don't see red flags as far as using the L3 agent-based implementation 14:06:08 the spec has extensions not only for the API but also for router attributes 14:06:21 this is to control the ECMP behavior for default routes inferred from subnets 14:07:06 is it needed any external agent? 14:07:14 no 14:07:23 we're using only the OVN functionality 14:07:29 when it comes to handling extra routes, OVN is smart enough to check whether next-hops have an overlap with the subnets directly reachable via a logical router port 14:07:45 I didn't read whole spec yet, but can You do some short summary how this is different from the specs proposed some time ago by rubasov and other erricsson guys? 14:07:51 so if any extra routes are added, their next hops will have an overlap check and a reachability check done by OVN 14:08:00 except that they wanted to implement it for ML2/OVS and L3 agent 14:08:01 slaweq: yes, 1 min 14:08:48 the diff is mainly in: 1. supporting multiple gws with the same network id 14:08:51 does this is only coupled to OVN or will it be possible to have this supported for OVS agent? 14:08:55 2. automatically adding ECMP default routes 14:09:25 3. extending the router with new attributes to specify the ECMP and BFD policy for the inferred default routes 14:09:31 sahid: for now, it is ovn focused 14:09:56 but in ricinple could be extended to ml2/ovs 14:10:04 mlavalle, sahid: yes 14:10:17 the BFD modelling in this spec is minimal 14:10:19 ok cool it's what i wanted to understand, sorry for the interuption 14:10:40 dmitriis thx 14:10:40 does it work with distributed FIPs? is there any clash? 14:10:59 good question I was about to ask 14:12:03 so, the spec is akin to implementing multiple snat- namespaces in the l3 agent implementation terms 14:12:26 I'll try to explain a little more 14:13:18 distributed fip with OVN is currently implemented by exposing the instance mac directly on the external network, so traffic would go directly and not go through the router, so there should be no clash 14:13:25 snat- namespaces? there is no something like that in ML2/OVN 14:13:38 slaweq: yes, I am just drawing an analogy 14:13:40 slaweq: he is using an analogy 14:14:01 ah, ok 14:14:02 sorry 14:14:32 yes, so, to fnordahl's point, there's a mechanism called 'external_mac' in OVN 14:14:46 which is relied on to implement distributed FIPs 14:15:10 and it doesn't collide with having multiple gateways 14:15:27 where we see some future imporovements is in avoiding asymmetric routing 14:15:43 which can be done by utilizing conntrack and the ecmp-symmetric-reply feature in OVN 14:16:33 this feature is not fully functional with distributed routing enabled 14:16:49 so that's where there would be some selective logic to implement from what I see 14:17:00 I noted that in the spec too 14:17:18 https://review.opendev.org/c/openstack/neutron-specs/+/870030/2/specs/2023.1/active-active-l3-gateway-with-multihoming.rst#340 14:17:59 so that's only limited to GW routers 14:18:17 the ecmp-symmetric-reply - yes. But we left it out of scope for now 14:18:23 ok 14:18:27 the complexity is conntrack state synchronization 14:18:27 one last question from me (that I don't see in the spec): is it possible to update a router to have multiple GWs and in the other way around, move from multiple GWs to only one? 14:19:31 yes, via update_external_gateways 14:20:01 we'd just leave one in the list when sending an update from the client 14:20:19 I'll ask this in the spec to have more details about this 14:20:24 there is some complexity in implementing this in the API but I am working through that now 14:20:41 the main difficulty is compatibility with the current one-gateway logic 14:21:08 and making the new API smart about whether to update the gw_port_id field or not 14:21:16 I think that rubasov addressed that in his spec 14:21:20 I think this kind or architecture details can be discussed better in the spec 14:21:27 ^^ slaweq right 14:21:35 maybe You can check how it was proposed then 14:21:37 +1 14:21:52 slaweq: there was special handling for the first external_gateway_info in the list 14:22:01 imo this is a very cool RFE that I'll be very happy to continue discussing in the spec and the implementation 14:22:03 I have the same thing (adopted from the previous spec) 14:22:33 yes the first one was left special to keep backward compatibility as I remember 14:22:55 mlavalle: thanks, I'm working on the mixin implementation now to see where things could fall apart but so far I am just learning the parts of the code base I haven't worked with 14:24:10 lajoskatona: yes, the mixin I am aiming to have is going to call to the parent methods with the first item and handle similarly but without touching the gw_port_id field of the router 14:24:18 but that's details 14:24:43 ok 14:25:15 folks, do you have any other question for dmitriis and fnordahl? 14:25:24 I am happy to answer any possible questions in the spec review 14:25:43 none from me 14:25:46 it's definitely something that needs careful consideration so I am very keen on receiving critical feedback :^) 14:25:56 nothing from me. questions I had are already discussd :) 14:26:00 yeah, this is why we have the spec review 14:26:03 not from me, I started reading the spec, we can continue there I think 14:26:07 so let's vote: 14:26:20 +1 from me 14:26:21 +1 for this RFE 14:26:24 dmitriis: yeah of course we are going to carry on the conversation in the spec 14:26:28 +1 14:26:28 +1 14:26:29 +1 14:26:59 thanks for the support 👍 14:27:01 dmitriis, fnordahl thanks for your RFE, I'll update the launchpad bug now 14:27:09 the RFE is approved 14:27:17 thanks! 14:27:22 let's continue the review in the spec 14:27:31 +1 14:27:41 + 14:28:14 is there any other topic to be discussed today? 14:28:34 not from me 14:28:52 I have a question around attaching routers to segmented networks 14:29:13 dmitriis, we can have this discussion outside the meeting 14:29:20 ralonsoh: ack 14:29:35 no other questions 14:29:55 thank you all for attending, have a nice weekend! 14:30:01 tyvm 14:30:03 #endmeeting