14:01:04 <slaweq> #startmeeting neutron_drivers
14:01:05 <openstack> Meeting started Fri Apr  9 14:01:04 2021 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:06 <slaweq> hi
14:01:08 <mlavalle> o/
14:01:08 <openstack> The meeting name has been set to 'neutron_drivers'
14:01:12 <amotoki> o/
14:01:17 <lajoskatona> o/
14:01:34 <haleyb> o/
14:01:46 <gibi> \o
14:01:54 <ralonsoh> hi
14:02:07 <viveknarasimhan> o/
14:02:52 <slaweq> we have quorum so I think we can start now
14:02:56 <slaweq> #topic RFEs
14:03:03 <slaweq> we have 2 rfe for today
14:03:14 <slaweq> first one
14:03:15 <slaweq> https://bugs.launchpad.net/neutron/+bug/1922237
14:03:16 <openstack> Launchpad bug 1922237 in neutron "[RFE][QoS] Add minimum guaranteed packet rate QoS rule" [Undecided,New]
14:03:21 <gibi> yepp
14:03:26 <gibi> that is on me
14:03:29 <slaweq> and we have gibi to ask a questions :)
14:03:32 <slaweq> welcome gibi
14:03:45 <gibi> in short this is similar to what we already done with minimum bandwidth QoS rule
14:03:51 <gibi> but now with minimum packet rate
14:04:04 <gibi> the scope is
14:04:23 <gibi> only the OVS agent reports packet rate inventory
14:04:32 <gibi> (the rest of the backend can be considered later if needed)
14:04:48 <gibi> only the scheduling time guarantees are in scope, data plane enforecement can be added later
14:05:10 <gibi> after the packet rate limiter QoS policy is implemented (separate RFE from liu)
14:05:26 <gibi> we need both Neutron and Nova impact
14:05:34 <gibi> details are being worked on in two specs
14:05:38 <gibi> https://review.opendev.org/q/topic:bp/qos-minimum-guaranteed-packet-rate
14:06:39 <ralonsoh> just a couple of questions/requests:
14:06:41 <gibi> as it stands today, I will drive the implementation of both the Neutron and the Nova impact with helps from lajoskatona
14:06:45 <gibi> ralonsoh: sure
14:07:14 <ralonsoh> both APIs and DB changes (Liu's and yours) could be implemented at once
14:07:39 <gibi> ralonsoh: do you suggest to have a single API extension for both?
14:08:08 <ralonsoh> no but to submit the change at the same time
14:08:13 <slaweq> I think we should have 2 api extensions, just to be consistent with other things
14:08:23 <gibi> I agree on the separate extensions
14:08:29 <lajoskatona> +1
14:08:35 <gibi> Nova will depend on only one of them
14:08:57 <gibi> ralonsoh: I can try to sync with Liu about proposing the API impact around the same time
14:08:58 <lajoskatona> Lius speaks of qos_pps_limiter while gibi qos_min_pps
14:09:05 <ralonsoh> and about the spec, I don't see clear the driver enforcement part
14:09:12 <ralonsoh> lajoskatona, I know, this is what I said
14:09:28 <lajoskatona> ralonsoh: ok
14:09:42 <gibi> ralonsoh: right now the data plane enforcement of the min pps guarantee is out of scope
14:09:48 <ralonsoh> ok, ok
14:09:51 <gibi> that first need a pps limiter implementation from Liu
14:09:59 <ralonsoh> perfect for me then, thanks!
14:10:03 <gibi> cool
14:10:36 <gibi> is there any other question?
14:10:54 <amotoki> I understand it is not an easy thing to ensure min pps from POV of data plane. Ensuring min pps at the scheduling time sounds good.
14:11:09 <amotoki> it is straight forward proposal and it sounds reaosnable to me
14:11:09 <gibi> amotoki: yes, I agree
14:11:18 <slaweq> one more question
14:11:21 <gibi> (on the hardness of the data plane stuff)
14:11:30 <slaweq> You said in the rfe that resource_request will have to be changed now
14:11:33 <viveknarasimhan> +1 as dataplane enforcement can be taken up later
14:11:53 <gibi> slaweq: yes, we need a deeper nested structure
14:12:16 <slaweq> does it means that nova and neutron will need to be upgraded together? Or will it be somehow compatible to make it working with e.g. Neutron Xena and Nova Wallaby?
14:12:27 <slaweq> or isn't such configuration supported at all?
14:13:07 <gibi> slaweq: I can make Xena Nova work with both Xena Neutron or Wallaby Neutron by keeping the old resource_request parsing logic in Nova
14:13:21 <gibi> and selecting the parse based on which Neutron API extension is enabled
14:13:36 <gibi> s/parse/parser/
14:14:15 <gibi> I'm not sure if we really support mixing controller service versions
14:14:20 <amotoki> slaweq: is it a common case where mixed versions of nova/neutron are run except during the upgrade?
14:14:43 <slaweq> amotoki: I don't know, that's why I asked if we support that thing at all
14:14:52 <slaweq> maybe not and then there is no problem
14:14:53 <slaweq> :)
14:14:56 <ralonsoh> I don't this is supported, but server/agent version delta
14:15:05 <slaweq> ok
14:15:13 <slaweq> so that is good for me then :)
14:15:18 <rubasov> late o/
14:15:25 <gibi> I have one more practical question
14:15:42 <gibi> do you feel the need to have a short chat with the nova team around this feature during the PTG?
14:15:47 <ralonsoh> sure
14:16:23 <gibi> OK, then I will talk to slaweq separately about a timeslot
14:16:30 <slaweq> ++
14:16:37 <gibi> I don't think we need a whole hour for it
14:16:42 <mlavalle> I am good with this RFE
14:16:51 <ralonsoh> +1 to the RFE
14:16:53 <mlavalle> straightforward definition
14:16:58 <amotoki> +1
14:17:01 <slaweq> +1
14:17:16 <mlavalle> +1
14:17:27 <haleyb> +1
14:17:41 <viveknarasimhan> +1
14:18:19 <slaweq> ok, I will mark this RFE as approved and will sync with gibi to schedule some time slot to discuss that during ptg too
14:18:25 <slaweq> thx
14:18:30 <gibi> thank you folks!
14:18:51 <slaweq> second rfe
14:18:53 <slaweq> https://bugs.launchpad.net/neutron/+bug/1921461
14:18:54 <openstack> Launchpad bug 1921461 in neutron "[RFE] Enhancement to Neutron BGPaaS to directly support Neutron Routers & bgp-peering from such routers over internal & external Neutron Networks" [Undecided,New]
14:19:13 <viveknarasimhan> thanks for taking this up in PTG today
14:19:30 <viveknarasimhan> i can put a few words to describe what this RFE addresses, can i put in?
14:20:15 <slaweq> viveknarasimhan: sure
14:20:15 <ralonsoh> please
14:20:20 <viveknarasimhan> thanks slaweq
14:20:33 <viveknarasimhan> this RFE is raised to enhance our current Neutron BGPaas Service
14:20:58 <viveknarasimhan> to enable it to support BGP-Peering over Internal-Neutron-Networks and External-Neutron-Networks
14:21:36 <viveknarasimhan> the idea is to bring L3 connectivity to non-neutron service-addresses hosted inside VNFs for access by telco subscribers
14:22:05 <viveknarasimhan> the VNFs provide several services to subscribers over dedicated service-addresses and enabling such service-addresses to be available on ISP-PE-Routers
14:22:24 <viveknarasimhan> by enhancing BGPaaS to support peering to VNFs over Internal Networks
14:22:41 <viveknarasimhan> & by enhancing BGPaas to support peering towards ISP-PE-Routers over External Networks
14:23:24 <viveknarasimhan> The spec is here : https://review.opendev.org/c/openstack/neutron-specs/+/783791/
14:23:28 <manubk39> thanks Vivek for the details. there was a network flip. just joined again
14:23:49 <viveknarasimhan> the RFE proposes 3 things:
14:23:59 <viveknarasimhan> a.  Provide direct association of routers to a bgpspeaker
14:24:11 <viveknarasimhan> b. enable bgpspeakers to peer with VNFs over Neutron-Tenant-Networks
14:24:31 <viveknarasimhan> c. enable bgpspeakers to peer with ISP-PE-Routers over External-Neutron-Networks
14:24:51 <mlavalle> big changes
14:25:14 <slaweq> so IIUC You want to have bgpspeaker run inside router's namespace
14:25:27 <viveknarasimhan> it is a fair proposal, but brings in capabilities into Openstack that make it much more relevant to Telco space
14:25:33 <slaweq> and announce to the external routers IPs from the tenant network
14:25:37 <slaweq> is that correct?
14:25:53 <viveknarasimhan> slaweq: yes, once a bgpspeaker is associated to a router, the speaker will run inside the router-namespace
14:26:28 <viveknarasimhan> and speaker will connect to external(aka ISP) and internal entities (VNFs) through the routers interface in the namespace
14:26:43 <mlavalle> nothing wrong with a big change in principle
14:26:58 <viveknarasimhan> yes the speaker will recieve external router IPs enabling reachability by VNF
14:27:24 <amotoki> but from the perspective of routers outside of openstack (i.e. neutron), there is no need to run BGPspeaker in a router ns. why do you need to run a speaker in a router ns?
14:27:26 <viveknarasimhan> and same way speaker will advertise internal-non-neutron-service-addresses to ISP router for enabling reachability of such addresses by Telco subscribers on ISP side
14:27:41 <amotoki> I am not sure what VNF you mean. where is VNF run?
14:28:06 <lajoskatona> I think we can translate VNF to an application inside the VM
14:28:17 <amotoki> Is a VNF run on a VM on nova?
14:28:19 <viveknarasimhan> amotoki: VNF is a VM,  Virtual Network Function
14:28:24 <viveknarasimhan> VNF is a VM fired by Nova
14:28:31 <amotoki> okay
14:28:39 <viveknarasimhan> we use VNF as more common terminology in Telco domains rather than VMs
14:29:01 <viveknarasimhan> the router we are talking about is a Neutron Router which is also a Gateway Router
14:29:18 <amotoki> I know what is VNF. I just would like to clarify it based on OpenStack terminology :)
14:29:46 <viveknarasimhan> a Gateway Router for a DC today has capabilities like BGP, BFD,  multiple external networks. Our RFE would enable a Neutron Router to become a Neutron Gateway Router
14:29:49 <viveknarasimhan> when need be
14:30:18 <slaweq> will Your proposal be compatible with what we have now?
14:30:33 <slaweq> now there is one DrAgent on compute node IIRC
14:30:35 <viveknarasimhan> For a bgpspeaker to peer with VNFs, it can access such VNFs through the neutron router
14:30:39 <slaweq> and it is bgpspeaker
14:30:46 <slaweq> correct?
14:30:56 <viveknarasimhan> in our RFE , we won't be using the DrAgent
14:31:19 <viveknarasimhan> the L3Agent will drive the functionality of a DrAgent as the BGPSpeaker is coupled with Router
14:31:32 <amotoki> Is the API compatible with what we have now?
14:31:54 <viveknarasimhan> the API we proposed is compatible with existing API
14:32:05 <viveknarasimhan> we can associate a provider-network to a bgpspeaker today
14:32:10 <viveknarasimhan> that will remain and work as is with DrAgent
14:32:12 <manubk> yes and there will be new API which will be created for associating BGP speaker to router
14:32:27 <viveknarasimhan> when the tenant associates neutron router to a bgpspeaker,  the realization will happen through the L3Agent
14:32:45 <mlavalle> will this replace neutron dynamic routing?
14:32:55 <viveknarasimhan> BGPServicePlugin will work with L3Plugin to in turn drive the L3agent to manage BGPSpekaer
14:33:09 <viveknarasimhan> mlavelle:  it is not replacing anything
14:33:24 <viveknarasimhan> we are offering an enhanced BGPPlugin that can support network-association and router-association
14:33:33 <viveknarasimhan> similar to how BGPVPN in Openstack provides today
14:33:47 <viveknarasimhan> network-association will work through current path of ServicePlugin -> DrAgent -> Speaker
14:34:05 <viveknarasimhan> router-association will work through enhancedBGPServicePlugin -> L3Plugin -> L3agent -> Speaker
14:34:12 <amotoki> I think we need some new l3 agent ext in neutron-dynamic-routing too, right?
14:34:48 <viveknarasimhan> amotoki:  at this moment, we think neutron-dynamic-routing will have enhancement only on teh BGPplugin
14:34:57 <viveknarasimhan> but, it will need to make calls to L3Plugin
14:35:12 <viveknarasimhan> we won't bring l3agentext into neutron-dynamic-routing as we donot see that is necessary
14:35:22 <slaweq> you mean to L3 service plugin?
14:35:27 <viveknarasimhan> yes L3 service Plugin
14:35:56 <viveknarasimhan> slaweq:  we will retain L3ServicePlugin as the owner of Router,  we just enhance the BGPServicePlugin to talk to L3Plugin to accomplish BGPspeaker managed
14:36:08 <viveknarasimhan> in that namespace of the router-associated-to-bgp-speaker
14:36:27 <mlavalle> my question was poorly phrased.... do you need to make changes to neutron dynamic routing or this is only on the Neutron side? I don't think this is clarified in the RFE
14:36:33 <slaweq> I'm not sure if I understand all that concept, I though that it will require some enhancement on the agent's side
14:36:39 <slaweq> not in the server/db side
14:36:41 <viveknarasimhan> we have a prototype demo recording of how this works for the tenant, and we are willing to share the recording for upstream friends here
14:36:58 <viveknarasimhan> the enhancmeent for us is in just 3 places:
14:37:02 <viveknarasimhan> a. Enhanced BGPServicePlugin
14:37:36 <viveknarasimhan> b. Enhanced L3 Plugin as it needs to pass the BGPSpeaker-associated-to-router towards the L3Agent
14:38:02 <viveknarasimhan> c. Enhanced L3Agent that will note that the router is BGPaas-wrapped, and will manage a single BGPSpeaker for that router namespace
14:38:18 <viveknarasimhan> We are supporting only one router-to-be-associated per BGPspeaker
14:38:25 <amotoki> I have a concern on the approach regarding b and c
14:38:33 <viveknarasimhan> which is unlike networks today where we allow tons of networks to be present on a bgpspeaker
14:38:36 <amotoki> it will introduce BGP stuff in L3 plugin and L3 agent.
14:38:43 <slaweq> amotoki: exactly
14:38:52 <amotoki> theoretically it should be implemented as l3 agnet extension
14:38:59 <viveknarasimhan> amotoki:  Would it be better if BGPPlugin talks directly to L3Agent?
14:39:08 <slaweq> for c) IMO it could be l3 agent extension, like we have for fip qos or port_forwardings now
14:39:29 <viveknarasimhan> slaweq and amotoki:  The implementaation we can work out, we request your feedback about our concept
14:39:32 <lajoskatona> which will work only if ndr is enabled?
14:39:38 <viveknarasimhan> please let us know twhat you think
14:40:08 <ralonsoh> can you share the code?
14:40:12 <slaweq> viveknarasimhan: I would like to see that demo if it would be fine for You
14:40:14 <viveknarasimhan> we also want to put here that this is one of the most common use-case for 5G-service-capable-VNFs that we host for Telco providers
14:40:37 <viveknarasimhan> slaweq: Wonderful, we can forward you the demo-recorded link
14:40:38 <mlavalle> who is we?
14:41:00 <slaweq> viveknarasimhan: can You put it in the comment to the LP RFE?
14:41:20 <viveknarasimhan> mlavelle: that is great question.  We here is manubk, myself and our other co-community colleagues Lajos  & Bence
14:41:37 <viveknarasimhan> slaweq: yes we will put the demo link in the LP RFE
14:41:51 <lajoskatona> yes it is an Ericsson backed feature request
14:42:06 <mlavalle> that helps
14:42:36 <viveknarasimhan> in the near future,  most of 5G-capable-VNFs and CNFs will serve tons of addresses all of them brought through EBGP towards ISP
14:42:50 <viveknarasimhan> enabling Telco subscribers to get high-end services exposed by VNFs
14:43:07 <lajoskatona> I started to add lines of these things to the PTG etherpad, to have more feedback
14:43:11 <mlavalle> that is interesting and exciting....
14:43:58 <viveknarasimhan> mlavelle ,  slaweq,  amotoki:  we request collaboration from community as the use-case is exciting and it brings a highly scalable bgpaas for use by lot of tenants and their VNFs
14:44:35 <mlavalle> mlavalle not mlavelle
14:44:43 <mlavalle> sorry, 3rd time
14:44:48 <viveknarasimhan> sorry thanks
14:45:03 <viveknarasimhan> mlavalle:  Thanks for correcting
14:45:27 <mlavalle> as I said, I find this interesting and exciting...
14:45:42 <viveknarasimhan> thanks mlavalle
14:45:55 <mlavalle> I am inclined to explore it further, especially from the perspective of this new %G uses cases
14:46:04 <mlavalle> 5G^^^^
14:46:05 <slaweq> lajoskatona: You will add this topic to the PTG, correct?
14:46:07 <viveknarasimhan> ralonsoh: we can share the prototype code
14:46:33 <ralonsoh> perfect, that will provide some answers to amotoki questions
14:46:40 <lajoskatona> slaweq: yes, I started to list these with links, and manubr can add details where it can
14:46:43 <lajoskatona> be
14:46:56 <mlavalle> so it would be very helpful if we start working on a spec that helps us to envision these 5G use cases in more detail
14:47:06 <viveknarasimhan> the demo recording link shows you how an ISP-hosted-user is able to access a VNF neutron primary IP that is backed by Neutron Gateway Router
14:47:08 <mlavalle> and discuss them in the specing process
14:47:12 <viveknarasimhan> simply through enhanced Neutron BGPaas
14:47:21 <viveknarasimhan> please feel free to keeps questions posted in the RFE
14:47:56 <slaweq> this indeed seems like very interesting idea for me
14:48:02 <viveknarasimhan> mlavalle:  as we speak here, we are expanding the spec to provide more context to enable better collaboration
14:48:25 <mlavalle> I would be ok +1 the RFE with the understanding that we are going to have a written spec
14:48:33 <slaweq> and I'm ok to approve that rfe as a concept, and later discuss details of the implementation in the spec and code review really
14:48:33 <amotoki> it is an interestiing idea. in my understanding, the main heart of this proposal is to make a neutron router a BGP router which can talk with routers on both external/internal networks.
14:48:36 <mlavalle> that we discuss and refine in gerrit
14:48:47 <viveknarasimhan> amotoki: you caught this 100% right :)
14:48:54 <amotoki> hopefully the spec can simplify what you would like to achieve.
14:49:32 <viveknarasimhan> amotoki:  yes, we will take your and community guidance on the same
14:49:56 <amotoki> I am okay with this RFE and the spec would help us understand it more.
14:50:04 <viveknarasimhan> amotoki: the last I have worked in Openstack neutron was for Distributed Router and now its full circle for us doing Centralized-BGP-enabled-Router :)
14:50:40 <slaweq> ralonsoh: haleyb: any comments? seems like only You didn't vote yet :)
14:50:56 <ralonsoh> +1 to the RFE and waiting for this spec
14:51:11 <haleyb> no comments, +1 from me just haven't read it all yet
14:51:20 <manubk> an initial spec is ready https://review.opendev.org/c/openstack/neutron-specs/+/783791/11/specs/wallaby/bgpaas-enhancements.rst
14:51:27 <slaweq> ok, so I will mark rfe as approved
14:51:37 <slaweq> thx for the proposal viveknarasimhan and manubk
14:51:50 <slaweq> please now work on the spec and then implementation of that feature
14:52:01 <viveknarasimhan> slaweq: thanks to the community for giving us this opportunity
14:52:06 <manubk> sure, thanks
14:52:18 <slaweq> that's all what I have for today
14:52:35 <slaweq> so I will give You few minutes back today
14:52:40 <slaweq> thx a lot and have a great weekend
14:52:41 <slaweq> o/
14:52:44 <ralonsoh> bye, have a nice weekend
14:52:45 <slaweq> #endmeeting