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