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