14:01:21 <slaweq> #startmeeting neutron_drivers
14:01:22 <openstack> Meeting started Fri Dec 11 14:01:21 2020 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:23 <slaweq> hi
14:01:25 <openstack> The meeting name has been set to 'neutron_drivers'
14:01:26 <mlavalle> o/
14:01:26 <ralonsoh> hi
14:01:28 <rubasov> o/
14:01:29 <amotoki> hi
14:01:32 <lajoskatona> Hi
14:01:33 <bpetermann> hi
14:02:05 <slaweq> we are still waiting for njohnston: haleyb and yamamoto
14:02:12 <njohnston> o/
14:02:14 <slaweq> lets give them few more minutes to join
14:02:16 <slaweq> :)
14:02:39 <haleyb> hi
14:03:40 * haleyb has to leave early about :30
14:03:57 <slaweq> ok, I think we can start, yamamoto isn't available on irc even so probably he will not join
14:04:02 <slaweq> #topic RFEs
14:04:10 <slaweq> agenda for the meeting is at https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
14:04:25 <slaweq> first RFE is from rubasov
14:04:27 <slaweq> https://bugs.launchpad.net/neutron/+bug/1905295
14:04:28 <openstack> Launchpad bug 1905295 in neutron "[RFE] Allow multiple external gateways on a router" [Wishlist,New] - Assigned to Bence Romsics (bence-romsics)
14:06:03 <rubasov> I have little experience around l3 in neutron, so let me know please what you think about this
14:06:26 <mlavalle> rubasov: unacceptable after the ascii art got messed up.... ;-)
14:06:50 <rubasov> this etherpad has the original: https://etherpad.opendev.org/p/neutron-multiple-external-gateways
14:06:52 <rubasov> :-)
14:07:31 <rubasov> (beyond the better figure nothing new there, I just prepared the rfe in here)
14:07:32 <mlavalle> ahhh, much nicer, thanks!
14:08:17 <amotoki> I dropped my comment just before the meeting. I think we can break down the problem into pieces. The problem statement includes several points: multiple ext gws, ECMP and/or router protocols
14:10:36 <rubasov> yes, bgp and ecmp is related and I tried to separate one sub-problem of the whole setup here
14:12:24 <haleyb> and you raised two good points - how do NAT and floating IP work in this scenario?  for example, on a failure of one link does NAT just stop for the down GW?  can the floating IP successfully use the other network?
14:12:37 <haleyb> amotoki did that is
14:14:48 <rubasov> my main use case would always have enable_snat=False, since bgp would make floating ips unnecessary
14:15:00 <slaweq> haleyb: I'm not sure if I understand - how FIP from one external network can work in the other one? Or both such gateways should be from the same neutron network?
14:15:50 <haleyb> slaweq: right, that was my point, although i'm sure with BGP it could be done but not otherwise.  just thinking of issues
14:16:46 <slaweq> haleyb: ok
14:16:48 <slaweq> :)
14:17:34 <lajoskatona> so it can be only done with dynamic-routing like the FIP for routed networks stuff recently?
14:17:54 <lajoskatona> or only worth doing it I mean
14:18:17 <ralonsoh> FIP for routed networks is still not merged
14:18:32 <amotoki> if we have multiple external networks we need routing protocols to advertise the route for FIP.
14:18:38 <lajoskatona> yeah, that's true, but quite close to it
14:19:27 <haleyb> amotoki: right, one network with multiple subnets for FIP is fine, but two networks not so much
14:19:30 <amotoki> if we have multiple gateways on a single external network, i think what we need is to configure multiple next hops with equal cost in a neutron router.
14:21:23 <ralonsoh> should be the BGP the one assigning this next hop for each FIP?
14:21:31 <ralonsoh> shouldn't*
14:21:32 <slaweq> rubasov: You wrote there about potential alternative, which is to allow announcing routes from the networks plugged to the router as internal networks
14:21:40 <slaweq> did You explore this more?
14:22:32 <rubasov> slaweq: one part I still don't know unfortunately
14:23:08 <slaweq> rubasov: for me it looks like easier, and less intrusive change maybe, no?
14:23:14 <rubasov> whether neutron-dynamic-routing uses the network external bit or the router's external_gw_info on generating the list of advertized routes
14:24:50 <rubasov> slaweq: that alternative looks like a smaller change, but also introduces some conceptual confusion about what's internal and what's external
14:25:00 <slaweq> true
14:25:25 <mlavalle> so you are striving for the functionality and conceptual clarity
14:26:06 <mlavalle> would a PoC help to clarify some of the lingering questions from the team?
14:26:07 <rubasov> yes, unless it's impossible (or too expensive to do)
14:27:11 <mlavalle> and the complexity issue raised by Yulong
14:27:39 <rubasov> we are open to that if the team is interested in it
14:28:06 <mlavalle> the complexity issue is not minor. L3 is pretty complex as it is today
14:28:17 <slaweq> ++
14:28:28 <amotoki> I wonder what kinds of requirements you would like to achieve. redundancy of next hop? redundancy of external networks? or more.
14:28:32 <amotoki> a neutron router is hosted on a single node, so is there any difference between multi next hop on a single network and multi networks.
14:28:39 <amotoki> ?
14:28:52 <lajoskatona> What happens if we do it gradually, I mean like do PoC for legacy router, and see if it's possible?
14:29:38 <slaweq> speaking about graduality - there is also ovn which has got own l3 implementation :)
14:29:43 <rubasov> amotoki: one router may fail out of R1-R2
14:29:48 <mlavalle> and that might provide an incentive to clarify the use case requirementes
14:29:57 <rubasov> one router may fail out of R3-R4
14:30:03 <mlavalle> as amotoki seems to be suggesting with his questions
14:30:43 <amotoki> rubasov: the proposal does not talk about R1-R2 relationship. my quesion comes from here.
14:30:48 <haleyb> slaweq: sorry, i have to run, this is a good discussion though...
14:31:01 <slaweq> haleyb: sure, see You
14:31:35 <rubasov> amotoki: that's a valid point, will add it to the rfe
14:32:30 <rubasov> R1-R2 are two sides of an active-active HA router
14:32:32 <mlavalle> so it seems we might be able to take two next steps: clarify the RFE and some sort of PoC?
14:33:02 <amotoki> mlavalle: agree
14:33:34 <slaweq> mlavalle: and explore this alternative mentioned by rubasov
14:34:01 <rubasov> slaweq: maybe that's a poc variant
14:34:09 <slaweq> rubasov: yes
14:34:22 <slaweq> just wanted to make sure that it will not be forgotten :)
14:34:35 <rubasov> ack :-)
14:34:57 <mlavalle> yeap... I think it is an interesting proposal. We need to clarify it a bit. I think a question to explore is whether we can do something with neutron dynamic routing to cover this use case. Maybe tweaking it a bit
14:35:14 <slaweq> so it seems that we have a plan for next steps with that
14:35:30 <rubasov> looks like to me too
14:35:32 <slaweq> and we will get back to that discussion when we will have that additional info
14:35:35 <slaweq> thx rubasov
14:35:42 <rubasov> thanks everyone
14:35:49 <slaweq> I will sum it up in the LP's comment after the meeting
14:35:53 <mlavalle> rubasov: thanks for the proposal!
14:36:13 <amotoki> yeah, it is an interesting topic
14:36:34 <slaweq> ok
14:36:36 <rubasov> will get back to you as soon as I have some results
14:36:39 <slaweq> so, we have next one https://bugs.launchpad.net/neutron/+bug/1905391
14:36:41 <openstack> Launchpad bug 1905391 in neutron "[RFE] VPNaaS support for OVN" [Medium,Triaged] - Assigned to Bodo Petermann (bpetermann)
14:37:33 <mlavalle> ahhh, good that we have enough time to give the stage to bpetermann. I didn't want him to show up for nithing :-)
14:37:46 <mlavalle> nothing^^^
14:38:21 <slaweq> we don't have folks from ovn subteam here probably but we can still discuss that here
14:38:36 <bpetermann> We want to offer VPNaaS in our new region which will use OVN so we started an implementation
14:38:43 <slaweq> I know that e.g. lucasgomes was looking into that rfe and he didn't had anything against
14:39:23 <mlavalle> bpetermann: who's your employer?
14:39:29 <bpetermann> SysEleven
14:39:36 <mlavalle> ack
14:40:01 <slaweq> bpetermann: I'm now reading amotoki's comment in LP - is there any API change needed for that?
14:41:01 <bpetermann> No, the VPN API will work the same way as before and no additions needed in Neutron either. Only maybe something if you want to manually fiddle with the VPN agent
14:41:31 <mlavalle> seems to be just a "change of driver", to simplify the proposal, right?
14:41:52 <mlavalle> API remains the same
14:42:08 <bpetermann> and configure a different VPN plugin
14:42:09 <mlavalle> am I correct?
14:42:23 <bpetermann> API remains the same, right
14:43:03 <mlavalle> yeah, change of plugin or driver. I was using the terms interchangeably
14:43:23 <amotoki> in my understanding, we need a separate VPN agent to run *swan so I think we need some scheduling for load balancing.
14:43:28 <amotoki> At least the proposed impl in gerrit has an API for manual scheduling and collect agent mapping.
14:43:56 <amotoki> this is what I commented about the new API.
14:44:19 <amotoki> I see no change in the user-facing VPNaaS API.
14:44:23 <slaweq> amotoki: ok :)
14:44:24 <bpetermann> the scheduler code in the proposed code will automatically choose some agent.
14:44:25 <slaweq> I see now
14:45:27 <slaweq> in general I think that we can approve that RFE
14:45:41 <slaweq> of course there will be many things to discuss regarding implementation details
14:46:06 <bpetermann> sure, waiting for your input..., thanks
14:47:03 <mlavalle> I agree that we can +1 this RFE
14:47:20 <mlavalle> with the understanding that there are details to clarify
14:47:35 <ralonsoh> agree +1
14:47:38 <amotoki> I agree to approve the RFE.
14:47:52 <mlavalle> bpetermann: great proposal. Thanks for working on it
14:47:59 <slaweq> njohnston: any thoughts?
14:48:01 <amotoki> my comment is just to try to clarify what are remaining parts.
14:48:13 <mlavalle> amotoki: ++
14:48:29 <njohnston> It makes sense to me, I don't have any additional questions.  I am generally appreciative of the continued vitality in the vpnaas project.
14:49:05 <mlavalle> unlike fwaas
14:49:13 <njohnston> sigh
14:49:18 <slaweq> amotoki: I think that Your last comment in LP is great summary of what else we will need
14:49:27 <slaweq> do You think we need specs for that?
14:49:28 <mlavalle> seems security groups were enough to cover that aspect
14:51:34 <amotoki> it is nice to have some doc which explains the relationship between standalone agent and OVN. it will help reviewing codes but  I am okay with either a spec or a in-repo doc.
14:52:00 <slaweq> amotoki: in-repo doc would be IMO "closer" for the users later to use
14:52:09 <slaweq> but that's just my opinion about it
14:53:02 <bpetermann> I could add some doc soon
14:53:16 <amotoki> slaweq: good point. so do we have a small spec doc?
14:53:40 <bpetermann> it's not committed yet
14:54:37 <slaweq> ok, so I will mark this RFE as approved and we will discuss implementation details in the review of the patches
14:54:53 <slaweq> and bpetermann will also propose some doc with details about this new implementation
14:55:00 <slaweq> ok for everyone?
14:55:06 <amotoki> sounds good
14:55:09 <ralonsoh> yes
14:55:14 <njohnston> +1
14:55:21 <bpetermann> yes
14:56:01 <mlavalle> +1
14:56:07 <slaweq> ok, thx
14:56:10 <slaweq> so that is done
14:56:16 <slaweq> we have one more rfe on the list
14:56:23 <slaweq> but we have just few minutes left today
14:56:41 <slaweq> and we have one more meeting this year, so I think we can simply start with lajoskatona's rfe next week
14:56:47 <slaweq> are You ok with that?
14:56:56 <lajoskatona> yeah I can wait one week :-)
14:57:22 <slaweq> thx
14:57:30 <slaweq> ok, so thanks for attending the meeting
14:57:35 <slaweq> and see You next week
14:57:40 <slaweq> have a great weekend :)
14:57:44 <njohnston> you too!
14:57:44 <slaweq> #endmeeting