14:03:41 <slaweq> #startmeeting neutron_drivers 14:03:42 <openstack> Meeting started Fri Dec 18 14:03:41 2020 UTC and is due to finish in 60 minutes. The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:03:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:03:45 <slaweq> hi 14:03:45 <openstack> The meeting name has been set to 'neutron_drivers' 14:03:56 <slaweq> sorry, I started meeting in #openstack-infra channel :D 14:04:02 <ralonsoh> hahahha 14:04:02 <amotoki> o/ 14:04:06 <slaweq> thx ralonsoh for ping in correct one 14:04:07 <mlavalle> o/ 14:04:19 <rubasov> o/ 14:04:44 <mlavalle> it happened to me also once 14:05:37 <slaweq> I think we have quorum already 14:05:46 <slaweq> haleyb|away: and njohnston are on pto already IIRC 14:05:59 <slaweq> and yamamoto isn't available also on irc 14:06:01 <slaweq> so lets start 14:06:14 <slaweq> #topic RFEs 14:06:23 <slaweq> We have 2 RFEs for today 14:06:29 <slaweq> https://bugs.launchpad.net/neutron/+bug/1907089 14:06:30 <openstack> Launchpad bug 1907089 in neutron "[RFE] Add BFD support for Neutron" [Wishlist,New] - Assigned to Lajos Katona (lajos-katona) 14:06:35 <slaweq> first one from lajoskatona 14:06:51 <lajoskatona> Yes, this is to support BFD in neutron 14:08:13 <slaweq> lajoskatona: first question is: does it require support for ecmp first? 14:08:21 <amotoki> It looks related to the ECMP support. 14:08:33 <slaweq> for which spec is already in review 14:08:34 <lajoskatona> slaweq: yeah it can be related 14:09:38 <lajoskatona> not sure if we have to make it dependent, I mean the API can be added ,and even we can monitor static routes for example as 1st step 14:09:43 <rubasov> it's most useful for ecmp, but non-ecmp routed could be also monitored 14:10:22 <rubasov> routes^^^ 14:10:27 <lajoskatona> yeah the cherry on top can be to change routes based on BFD status let's say 14:10:57 <slaweq> can we also in future use it e.g. to do failover of active ha router? 14:11:13 <slaweq> if external gw is not working for example 14:11:22 <amotoki> the spec currently proposed is about ECMP support on a single neutron router, but in my understaing lajoskatona's RFE assumes a pair of neutron routers and BDF is used to monitor healthiness of paired routers. 14:11:37 <amotoki> s/BDF/BFD/ 14:11:42 <lajoskatona> slaweq: yeah, we thought about that, but left it out from this spec 14:11:48 <slaweq> k 14:12:41 <lajoskatona> yeah the usecase is comming from monitoring nexthop-destination pairs and protocols like BGP 14:12:41 <amotoki> I think active-active router pair is a new concept in neutron and it is different from our current HA router. 14:13:11 <lajoskatona> but the whole thing can be a general API that can be used to other things in best case 14:13:52 <ralonsoh> I have one question about the backend implementation: why the monitor is on the OVS port, instead of the router namespace interface? 14:14:02 <lajoskatona> amotoki: in our mind ewe have more a neutron router and another out of neutron 14:14:15 <ralonsoh> (apart from the OVS limitation to one single monitor per interface) 14:14:41 <amotoki> lajoskatona: sorry. I was confused with others... thanks for clarification 14:15:21 <lajoskatona> ralonsoh: to tell the truth during the PTG somebody suggested that OVS has this feature, why no to use it as it is already there 14:15:50 <ralonsoh> but this is a hard limitation for ECMP (when implemented) 14:15:55 <lajoskatona> ralonsoh: you suggest to use something else in the namespace? 14:16:08 <ralonsoh> FFR package (both in Ubuntu and RHEL8) 14:16:20 <lajoskatona> ralonsoh: I check it 14:16:23 <ralonsoh> (I never tested it, just read the doc) 14:16:39 <lajoskatona> ralonsoh: yeah it's new topic for me as well :-) 14:17:15 <lajoskatona> The hard thing is as I see that the router API is touched to add bfd reference to extra routes 14:17:24 <mlavalle> we are in explarotary face, so we have time to research this type of implementation things 14:18:23 <lajoskatona> mlavalle: yeah, we do not expect quick result, it seems quite a handful topic to make it really useful 14:18:47 <mlavalle> so IMO, since a spec is going to be written anyways, I'd be good +1 ing this RFE 14:19:09 <mlavalle> an we can have a detailed discussion there 14:19:21 <ralonsoh> agree 14:19:31 <lajoskatona> malavalle: Yeah that't why I started to draft a spec quickly 14:19:35 <amotoki> yeah, agree. 14:19:40 <slaweq> I'm fine with approving that rfe and continue discussion in the spec 14:19:48 <slaweq> and then in the implementation patches 14:20:15 * mlavalle realizes that he wrote face when he intended pahse.... LOL 14:20:31 <ralonsoh> (sounds similar) 14:20:36 <slaweq> :) 14:20:36 <mlavalle> phase 14:20:44 <ralonsoh> +1 to the RFE 14:20:53 <mlavalle> +1 to the RFE 14:20:57 <slaweq> so if I understood correctly we agreed to approve the rfe, right? 14:22:16 <amotoki> +1 to apprve the RFE. the request itself to add BFD monitor per router sounds good. 14:22:30 <slaweq> ok, so that was quick :) 14:22:31 <slaweq> thx 14:22:39 <amotoki> s/per router/per route/ 14:22:41 <lajoskatona> thanks, \o/ 14:22:44 <slaweq> I will mark that rfe as approved after the meeting 14:23:01 <slaweq> so lets move to the second one 14:23:03 <slaweq> https://bugs.launchpad.net/neutron/+bug/1905295 14:23:04 <openstack> Launchpad bug 1905295 in neutron "[RFE] Allow multiple external gateways on a router" [Wishlist,New] - Assigned to Bence Romsics (bence-romsics) 14:23:12 <slaweq> this one was discussed last week 14:23:20 <slaweq> and rubasov provided some new data there 14:23:57 <rubasov> yep, made some progress exploring the alternative of using router interfaces to subnets of external networks 14:25:09 <rubasov> I found a question: despite what the api-ref says do we consider this a supported use of the api? 14:25:35 <amotoki> I added some follow-up comment on my understanding on "external" just before the meeting 14:25:36 <rubasov> plus this alternative would entail other changes in neutron-dynamic-routing 14:25:37 <amotoki> https://bugs.launchpad.net/neutron/+bug/1905295/comments/12 14:25:39 <openstack> Launchpad bug 1905295 in neutron "[RFE] Allow multiple external gateways on a router" [Wishlist,New] - Assigned to Bence Romsics (bence-romsics) 14:25:54 <rubasov> amotoki: thank you, just read it a few minutea ago 14:26:33 <mlavalle> so we would use neutron-dynamic-routing somehow? 14:27:41 <rubasov> my use case does require routed being advertised via bgp 14:28:21 <amotoki> I think we can use dynamici-routing somehow. It depends on the interpretation of "external" of a network. 14:28:34 <amotoki> I mean what routes should be advertised. 14:28:34 <rubasov> and neutron-dynamic-routing does not advertise routes towards subnets of external networks today 14:29:44 <rubasov> the logic of advertised routes looks at ports with device_owner=router_gw 14:30:08 <rubasov> so that's something I need to look into to support my use case 14:30:27 <rubasov> but technically I guess that would be a different rfe 14:31:43 <mlavalle> that is fine with me. I was just asking clarifying question 14:33:16 <amotoki> so perhaps we would like to clarify what is device_owner="router_gateway" (and "external" network) 14:34:18 <amotoki> neutron uses "external" network in several context: router default gateway, floating IP pool and SNAT 14:34:50 <amotoki> I think the current behavior of neutron-dynamic-routing is good 14:35:20 <amotoki> and we keep the current behavior to advertise routes related to router-gateway only 14:36:11 <amotoki> it is easy to understand, but what happens if we go to (3) (router interface with external network) 14:36:12 <amotoki> ? 14:36:15 <slaweq> and then we should continue with rubasov's rfe as "allowing multiple external gateways" 14:36:38 <rubasov> amotoki: I was thinking of not removing any routed advertises today, just adding an option to advertise towards external=true networks too 14:37:12 <slaweq> amotoki: IMHO this direction with multiple ext gws is conceptually better 14:37:27 <slaweq> and more in line with well known neutron behaviour 14:37:38 <amotoki> slaweq: I think so 14:38:22 <amotoki> rubasov: we don't know full usage of external networks so I am not sure side effect when we advertise external networks as router interfaces. that's a conceern. 14:38:32 <mlavalle> rubasov: spec is the next step, right? 14:39:12 <rubasov> mlavalle: yes, but a spec for which alternative? :-) 14:39:52 <slaweq> my proposal is to accept rfe as a concept and continue spec in the "multiple external gateways" way 14:40:44 <mlavalle> yeah, that is what I was about to suggest 14:40:47 <amotoki> "multiple external gateways" in a router sounds most straight-forward to me 14:40:50 <slaweq> thx :) 14:40:57 <mlavalle> since we seem to have some consesnsus arounbd it 14:41:41 <amotoki> rubasov: one clarification: your RFE mentions active-active routers in a use case, but is it out of scope of the RFE, right? 14:42:07 <rubasov> amotoki: yes, out of scope here 14:42:15 <amotoki> rubasov: thanks 14:43:42 <amotoki> i'm fine to approve this RFE 14:44:07 <slaweq> ralonsoh: are You ok with approving it? 14:44:11 <ralonsoh> sure, +1 14:44:33 <mlavalle> to formalize in the record, also +1 from me 14:44:39 <slaweq> thx mlavalle :) 14:44:58 <slaweq> I assumed that You and amotoki already gave +1 but in different words :) 14:45:09 <slaweq> ok, so I will mark this one as approved too 14:45:15 <slaweq> thx a lot for the discussions 14:45:24 <slaweq> that's all what I had for today 14:45:26 <rubasov> okay, next I will write a spec and also start working with the PoC we discussed last time to explore the concerns about the complexity 14:45:34 <rubasov> thank you guys 14:45:38 <slaweq> rubasov: sounds good, thx 14:46:16 <slaweq> so as the last thing today I want to wish all of You happy holidays and happy New Year 14:46:18 <mlavalle> rubasov, lajoskatona: thanks for the proposals. It's always nice to support more use cases. You seem to be pushing the edge in L3 14:46:31 <slaweq> stay safe and see You all in the 2021 :) 14:46:41 <slaweq> I'm going to cancel meetings in december 14:46:49 <amotoki> rubasov: thanks for breaking down the issue in detail. 14:46:53 <rubasov> thanks for all the good feedback 14:46:53 <lajoskatona> Happy holidays for everybody :-) 14:46:55 <mlavalle> slaweq: same to you. More importantly, I wish a healthy and vaccinated 2021 to everybody 14:47:01 <ralonsoh> enjoy! happy holidays! 14:47:07 <amotoki> happy holidays and new years everyone :-) 14:47:20 <rubasov> happy holidays! 14:47:25 <mlavalle> and remember to be careful during your celebrations. The emergency is not over just yet 14:47:26 <slaweq> mlavalle: :) I think that will be most common wishes this year 14:47:27 <lajoskatona> mlavalle: good to learn new things that's seems to be useful :-) 14:47:33 <slaweq> "vaccinated 2021!" 14:47:55 <slaweq> o/ 14:47:59 <slaweq> #endmeeting