On Mon, Jul 7, 2025 at 10:26 AM Tim Rozet <tro...@redhat.com> wrote: > > Hey Guys, > Just catching up on this. I'm not sure if adding another layer of abstraction > would help OVNK for managing flows on br-ex. What would be the advantage to > this over what we have now? Is it enough to justify switching to this > proposal?
The main goal of my proposal was for CMS to not worry about handling the OpenFlow protocol and let the new abstraction - ovn-bridge-controller take care of it. With this abstraction, CMS doesn't need to exec "ovs-ofctl" to add or delete a flow, or to dump the existing flows to figure out what is installed and what is not. Regarding OVN-K, of course it's the OVNK community's decision to adopt this new abstraction or not :) Thanks Numan > > Tim Rozet > Red Hat OpenShift Networking Team > > > On Tue, Jul 1, 2025 at 4:35 AM Dumitru Ceara <dce...@redhat.com> wrote: >> >> On 6/30/25 6:23 PM, Numan Siddique wrote: >> > On Mon, Jun 30, 2025 at 5:34 AM Dumitru Ceara <dce...@redhat.com> wrote: >> >> >> >> Hi Numan, >> >> >> >> On 6/26/25 4:26 PM, Numan Siddique wrote: >> >>> On Thu, Jun 26, 2025 at 8:27 AM Dumitru Ceara <dce...@redhat.com> wrote: >> >>>> >> >>>> Hi Frode, >> >>>> >> >>>> On 6/26/25 1:50 PM, Frode Nordahl wrote: >> >>>>> On 25.06.2025 14:58, Dumitru Ceara wrote: >> >>>>>> On 6/23/25 6:23 PM, Frode Nordahl wrote: >> >>>>>>> Hello, All, >> >>>>>>> >> >>>>>> >> >>>>>> Hi Frode, >> >>>>>> >> >>>>>>> Apologies for being late to the discussion, but just wanted to >> >>>>>>> document >> >>>>>>> our interest in this as mentioned in the last IRC meeting and just >> >>>>>>> now >> >>>>>>> in the A/V meeting. >> >>>>>>> >> >>>>>>> >> >>>>>>> On 19.06.2025 16:18, Dumitru Ceara via dev wrote: >> >>>>>>>> Hi Numan, >> >>>>>>>> >> >>>>>>>> On 6/18/25 11:38 PM, Numan Siddique wrote: >> >>>>>>>>> On Wed, Jun 18, 2025 at 5:00 PM Dumitru Ceara <dce...@redhat.com> >> >>>>>>>>> wrote: >> >>>>>>>>>> >> >>>>>>>>>> Hi Han, >> >>>>>>>>>> >> >>>>>>>>>> On 6/18/25 7:40 PM, Han Zhou wrote: >> >>>>>>>>>>> Thanks Numan for the proposal. >> >>>>>>>>>>> >> >>>>>>>>>>> On Wed, Jun 18, 2025 at 4:27 AM Dumitru Ceara <dce...@redhat.com> >> >>>>>>>>>>> wrote: >> >>>>>>>>>>>> >> >>>>>>>>>>>> Hi Numan, Ales, >> >>>>>>>>>>>> >> >>>>>>>>>>>> On 6/10/25 4:24 PM, Numan Siddique wrote: >> >>>>>>>>>>>>> On Tue, Jun 10, 2025 at 2:04 AM Ales Musil <amu...@redhat.com> >> >>>>>>>>>>>>> wrote: >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> On Thu, Jun 5, 2025 at 9:44 PM Numan Siddique <num...@ovn.org> >> >>>>>>>>>>>>>> wrote: >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> On Thu, Jun 5, 2025 at 11:33 AM Dumitru Ceara >> >>>>>>>>>>>>>>> <dce...@redhat.com> >> >>>>>>>>>>> wrote: >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> On 6/4/25 6:24 PM, Numan Siddique wrote: >> >>>>>>>>>>>>>>>>> Hello, >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> Hi Numan, >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Hi Dumitru and Numan, >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> I think the project might be a good idea in general, just >> >>>>>>>>>>>>>> adding >> >>>>>>>>>>>>>> my opinion on some parts below. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> There's a need to configure the provider bridge with >> >>>>>>>>>>>>>>>>> specific >> >>>>>>>>>>> OpenFlow >> >>>>>>>>>>>>>>>>> rules after packets leave the OVN pipeline and enter via >> >>>>>>>>>>>>>>>>> the >> >>>>>>>>>>>>>>>>> patch >> >>>>>>>>>>>>>>>>> port. >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> To simplify this for CMS, I propose utilizing OVN logical >> >>>>>>>>>>>>>>>>> flows. >> >>>>>>>>>>> This >> >>>>>>>>>>>>>>>>> would eliminate the need for CMS to manage direct OpenFlow >> >>>>>>>>>>> connections >> >>>>>>>>>>>>>>>>> and programming. >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> This seems very interesting! >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> To achieve this, I've developed a new service within OVN >> >>>>>>>>>>>>>>>>> called >> >>>>>>>>>>>>>>>>> `ovn-pr-controller` (pr = provider). Here's a high-level >> >>>>>>>>>>>>>>>>> overview: >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> A new database, `OVN_Provider`, is created with two main >> >>>>>>>>>>>>>>>>> tables: >> >>>>>>>>>>>>>>>>> `PR_Bridge` and `Logical_Flow`. >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> `ovn-pr-controller` connects to this database, translates >> >>>>>>>>>>>>>>>>> logical >> >>>>>>>>>>>>>>>>> flows to OpenFlow rules, and programs the bridges. >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> CMS adds logical flows for managed provider bridges by >> >>>>>>>>>>>>>>>>> connecting to >> >>>>>>>>>>>>>>>>> the `OVN_Provider` database. >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> CMS can define the pipeline as needed. >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> An `ovn-prctl` utility (similar to `ovn-nbctl`) is used to >> >>>>>>>>>>>>>>>>> program >> >>>>>>>>>>>>>>>>> logical flows. >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> Example Usage: >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> # Add a provider bridge >> >>>>>>>>>>>>>>>>> `ovn-prctl add-br br-ext` >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> # Add logical flows >> >>>>>>>>>>>>>>>>> `ovn-prctl add-flow br-ext 0 100 "inport == >> >>>>>>>>>>>>>>>>> \\"patch-port\\"" >> >>>>>>>>>>>>>>>>> "ct_snat_zone = 1000; next;"` >> >>>>>>>>>>>>>>>>> `ovn-prctl add-flow br-ext 0 0 "1” "next;"` >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> `ovn-prctl add-flow br-ext 1 1000 "ip4" "ct_snat;"` >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> `ovn-prctl add-flow br-ext 2 1000 "ip4 && ct.new && ct.trk >> >>>>>>>>>>>>>>>>> && >> >>>>>>>>>>> ip4.src >> >>>>>>>>>>>>>>>>> == 10.0.0.11" "ct_snat(100.64.0.11); next;"` >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> `ovn-prctl add-flow br-ext 2 0 "ip4" "next;"` >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> `ovn-prctl add-flow br-ext 3 100 "ip4 && ip4.dst == >> >>>>>>>>>>>>>>>>> 52.92.128.0/17" >> >>>>>>>>>>>>>>>>> "tun.id = 1000; tun_ip4.dst = 10.100.100.1; eth.dst = >> >>>>>>>>>>>>>>>>> 4c:96:14:14:01:b0; outport = \\"vxlan0\\"; output;"` >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> `ovn-prctl add-flow br-ext 3 0 “1” “output;”` >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> I'd like to get the community's feedback on whether this >> >>>>>>>>>>>>>>>>> service >> >>>>>>>>>>> would >> >>>>>>>>>>>>>>>>> be a valuable addition to OVN. >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> I wonder if we need these to be separate >> >>>>>>>>>>>>>>>> databases/processes. >> >>>>>>>>>>> Wouldn't >> >>>>>>>>>>>>>>>> it make sense to expose this in the NB database directly? >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> With your proposal, these new ovn-pr-controllers would have >> >>>>>>>>>>>>>>>> to >> >>>>>>>>>>> connect >> >>>>>>>>>>>>>>>> to the central OVN_Provider database from all chassis. But >> >>>>>>>>>>>>>>>> we >> >>>>>>>>>>> already >> >>>>>>>>>>>>>>>> have the ovn-controller connection to the Southbound. >> >>>>>>>>>>>>>>>> Could we >> >>>>>>>>>>> reuse that? >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> I forgot to mention that the OVN provider ovsdb-server and >> >>>>>>>>>>>>>>> the >> >>>>>>>>>>>>>>> ovn-pr-controller needs >> >>>>>>>>>>>>>>> to be run on each chassis. >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> I see. However, I think it gives even more flexibility if the >> >>>>>>>>>>>> OVN >> >>>>>>>>>>>> provider database is centralized. Then the CMS central >> >>>>>>>>>>>> component >> >>>>>>>>>>>> (e.g., >> >>>>>>>>>>>> neutron for OpenStack) could just write "logical flows" there >> >>>>>>>>>>>> and >> >>>>>>>>>>>> rely >> >>>>>>>>>>>> on per-chassis ovn-pr-controllers to translate that to OpenFlow. >> >>>>>>>>>>>> >> >>>>>>>>>>> While it brings flexibility, we should also keep in mind that the >> >>>>>>>>>>> central >> >>>>>>>>>>> approach could introduce another choke point for scale. Even if >> >>>>>>>>>>> we >> >>>>>>>>>>> reuse SB >> >>>>>>>>>>> DB as the central component, the new ovn-pr-controllers process >> >>>>>>>>>>> would >> >>>>>>>>>>> require new connections to the SB DB. >> >>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> True, but I was not really thinking of using the SB DB as the >> >>>>>>>>>> central >> >>>>>>>>>> component for ovn-pr-controllers but rather a new database >> >>>>>>>>>> server. And >> >>>>>>>>>> I really hope it wouldn't require storing as many logical flows >> >>>>>>>>>> (and >> >>>>>>>>>> data in general) as we store in the SB today. >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> Thanks for the comments and the discussion. >> >>>>>>>>> >> >>>>>>>>> Just FYI - I thought we are in favour of having a separate >> >>>>>>>>> project. >> >>>>>>>>> So I reworked a bit and renamed the project to - ovnbr controller >> >>>>>>>>> (ovn >> >>>>>>>>> bridge controller) >> >>>>>>>>> - https://github.com/numansiddique/ovnbr/tree/initial_commits >> >>>>>>>>> >> >>>>>>>>> But I can move back the code to ovn project. So not a problem. >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>>>> Supporting both central and distributed may be an overkill at >> >>>>>>>>>>> least >> >>>>>>>>>>> as a >> >>>>>>>>>>> start, if we could decide which one is more practical from a CMS >> >>>>>>>>>>> point of >> >>>>>>>>>>> view. >> >>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> Maybe, but the "distributed" case would probably mean more work >> >>>>>>>>>> for the >> >>>>>>>>>> CMS on the node side (a per chassis CMS component is definitely >> >>>>>>>>>> required >> >>>>>>>>>> then to provision the per chassis database). >> >>>>>>>>>> >> >>>>>>>>>> I do understand however that we'd need a way to abstract >> >>>>>>>>>> chassis-specific resources (e.g., OVS ports) in the other, >> >>>>>>>>>> "centralized", case. And that might be a significant >> >>>>>>>>>> disadvantage. >> >>>>>>>>>> >> >>>>>>>>>>>> On second thought, if designed properly, there's probably no >> >>>>>>>>>>>> need >> >>>>>>>>>>>> to add >> >>>>>>>>>>>> a restriction to colocate the new database and ovn-pr- >> >>>>>>>>>>>> controller. We >> >>>>>>>>>>>> could just support both types of deployments: >> >>>>>>>>> >> >>>>>>>>> @Dumitru Ceara If I understand correctly, what you're suggesting >> >>>>>>>>> is that >> >>>>>>>>> CMS can decide to run ovnbr database either central or locally - >> >>>>>>>>> for >> >>>>>>>>> each chassis. >> >>>>>>>>> >> >>>>>>>> >> >>>>>>>> Yes, that's what I was thinking of. >> >>>>>>> >> >>>>>>> fwiw; We would be interested in the distributed database for the PR >> >>>>>>> controller. >> >>>>>>> >> >>>>>>> Our interest surfaced after a discussion with Jakub Libosvar on how >> >>>>>>> to >> >>>>>>> approach downstream OpenStack Neutron consumption of OVN native BGP >> >>>>>>> support, where he raised the following use case: >> >>>>>>> * Single NIC chassis. >> >>>>>>> * Said NIC is operated by OVS, for simplicity and purpose of >> >>>>>>> discussion, >> >>>>>>> let's say the user space data path. >> >>>>>>> >> >>>>>>> >> >>>>>>> Now let's mix this with OVN native BGP features such as: >> >>>>>>> * Learning the default gateway through route exchange. >> >>>>>>> * Routing IPv4 prefixes over IPv6 next hop (aka. BGP Unnumbered). >> >>>>>>> * BGP protocol redirect to ensure BGP next hop address is the >> >>>>>>> link-local >> >>>>>>> address of a OVN LR on the integration bridge (which may be required >> >>>>>>> for >> >>>>>>> this to work with older versions of FRR on some ToR equipment due to >> >>>>>>> lack of support for 3rd party link-local next hop). >> >>>>>>> >> >>>>>>> >> >>>>>>> With a centralized Southbound database, which a CMS such as OpenStack >> >>>>>>> deploys, we would have a chicken and egg problem, because flows are >> >>>>>>> needed in the integration bridge for the ovn-controller to connect to >> >>>>>>> the Southbound database, and ... you get the picture. >> >>>>>>> >> >>>>>>> I imagine we could make parts of this work better with a distributed >> >>>>>>> database for a OVN Provider Controller. >> >>>>>>> >> >>>>>>> I guess we could even task this distributed controller with "priming" >> >>>>>>> the integration bridge with a simple set of "static flows" enough to >> >>>>>>> get >> >>>>>>> it bootstrapped in such topologies (or could this specific task even >> >>>>>>> be >> >>>>>>> a feature of the regular controller?). >> >>>>>>> >> >>>>>> >> >>>>>> I'm just trying to make sure I understood this last part correctly. >> >>>>>> By >> >>>>>> "regular controller" do you mean "ovn-controller" or some other (CMS) >> >>>>>> node-specific component? >> >>>>> >> >>>>> I was referring to the "ovn-controller". >> >>>>> >> >>>> >> >>>> Thanks for the clarification! >> >>>> >> >>>>> The need for a L3 interface on every chassis for BGP generates a lot of >> >>>>> per-chassis configuration, which "pollutes" the Northbound database for >> >>>>> CMSs that uses centralized OVN DBs for the entire deployment. >> >>>>> >> >>>>> The idea of a distributed database for the pr-controller made me think >> >>>>> this distributed database could potentially also be consumed by the >> >>>>> ovn- >> >>>>> controller for per-chassis configuration in cases where more advanced >> >>>>> higher layer features are required, and the CMS does not want to re- >> >>>>> implement those in logical flows using the "pr-controller" themselves. >> >>>>> >> >>>> >> >>>> Wouldn't it then make sense to just use ovn-controller for managing all >> >>>> bridges (br-int and also all provider OVS bridges listed in the >> >>>> distributed "Provider Database") in all cases? >> >>> >> >>> I thought about that too. I still feel it's better to have a separate >> >>> service. >> >>> Any user can just use OVN bridge/provider controller without having to >> >>> use OVN >> >>> to program OVS bridges. >> >>> >> >> >> >> That's fair. It seems more flexible. If ever needed we can also add >> >> support in the future for ovn-controller to take over the functionality >> >> of the bridge/provider controller. >> > >> > Thanks. >> > >> > Shall I start working on proposing the patches ? With >> > - With a new service inside the ovn repo (like ovn-controller-vtep) >> > - Name of the service - ovn-br-controller >> > >> >> Sounds good to me! >> >> Regards, >> Dumitru >> >> > Thanks >> > Numan >> > >> > >> >> >> >> Regards, >> >> Dumitru >> >> >> >>> Thanks >> >>> Numan >> >>> >> >>>> >> >>>> Thanks, >> >>>> Dumitru >> >>>> >> >>>>> -- >> >>>>> Frode Nordahl >> >>>>> >> >>>>>>>>> I think that would work too. Only disadvantage is that CMS has to >> >>>>>>>>> ensure that the bridge names and physical interface names >> >>>>>>>>> have to be the same. Although we can definitely find a way to >> >>>>>>>>> handle >> >>>>>>>>> this. >> >>>>>>>>> >> >>>>>>>>> The present proposal schema - >> >>>>>>>>> https://github.com/numansiddique/ovnbr/blob/initial_commits/ovn- >> >>>>>>>>> br.ovsschema#L66 >> >>>>>>>>> has only a Bridge table and no ports defined. In the present >> >>>>>>>>> proposal >> >>>>>>>>> CMS can add >> >>>>>>>>> logical flows like - "inport == eth1 && ....." and >> >>>>>>>>> ovnbr-controller >> >>>>>>>>> expects an OVS interface - eth1 in the OVS bridge. >> >>>>>>>>> >> >>>>>>>> >> >>>>>>>> Right, we'd need a way to represent chassis specific information if >> >>>>>>>> we >> >>>>>>>> support a central ovnbr database. Probably at least: OVS ports, >> >>>>>>>> conntrack zones, provider bridge names. >> >>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>>>>> - ovn-pr-controller & database on the same chassis >> >>>>>>>>>>>> - (multiple) ovn-pr-controller connecting to a database on a >> >>>>>>>>>>>> different >> >>>>>>>>>>>> node (e.g., colocated with the Southbound) >> >>>>>>>>>>>> >> >>>>>>>>>>>>>>> This is basically to allow a CMS agent running on each >> >>>>>>>>>>>>>>> chassis >> >>>>>>>>>>>>>>> to use >> >>>>>>>>>>>>>>> logical flows >> >>>>>>>>>>>>>>> and program them in the OVN provider database, instead of >> >>>>>>>>>>>>>>> talking >> >>>>>>>>>>>>>>> OpenFlow directly. >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> OVN has a very nice way of abstracting OpenFlows using >> >>>>>>>>>>>>>>> logical >> >>>>>>>>>>>>>>> flows >> >>>>>>>>>>>>>>> and my idea is to leverage it. >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> ovnkube-node, as you know, programs the OpenFlow rules to >> >>>>>>>>>>>>>>> the >> >>>>>>>>>>>>>>> provider bridge directly by execing >> >>>>>>>>>>>>>>> "ovs-ofctl". The OVN kubernetes community could possibly use >> >>>>>>>>>>>>>>> OVN >> >>>>>>>>>>>>>>> provider controller. >> >>>>>>>>>>>> >> >>>>>>>>>>>> Another thing the CMS node component (ovnkube-node in the >> >>>>>>>>>>>> example >> >>>>>>>>>>>> above) >> >>>>>>>>>>>> needs to do is reconcile flows on the "provider" bridge on >> >>>>>>>>>>>> restart. >> >>>>>>>>>>>> >> >>>>>>>>>>>> This new OVN provider controller would also remove the need for >> >>>>>>>>>>>> the CMS >> >>>>>>>>>>>> to do that, which is an advantage. >> >>>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> It is definitely valuable, and no objection from me. But I think >> >>>>>>>>>>> it is >> >>>>>>>>>>> better to ask opinion from CMS component maintainers if the OVS >> >>>>>>>>>>> pipeline >> >>>>>>>>>>> for the provider bridge is complex enough to justify this. Also, >> >>>>>>>>>>> how much >> >>>>>>>>>>> would it help by managing logical flows through an OVSDB versus >> >>>>>>>>>>> managing >> >>>>>>>>>>> open-flow rules though ovs-ofctl. Keep in mind that the >> >>>>>>>>>>> abstraction >> >>>>>>>>>>> here is >> >>>>>>>>>>> not at the level of the NB DB which focuses on logical >> >>>>>>>>>>> topologies - >> >>>>>>>>>>> here >> >>>>>>>>>>> the abstraction is logical-flows (something at the SB level), so >> >>>>>>>>>>> the CMS >> >>>>>>>>>>> still needs to manage the pipeline rather than just logical >> >>>>>>>>>>> topology. >> >>>>>>>>> >> >>>>>>>>> That's correct. Expectation is that CMS knows what it is doing, >> >>>>>>>>> And we have the requirement to add flows in the provider bridges >> >>>>>>>>> and >> >>>>>>>>> hence thought >> >>>>>>>>> of this abstraction to >> >>>>>>>>> - leverage the OVN logical flows >> >>>>>>>>> - and to leverage the openflow handling of ovn-controller. >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> My personal preference is also to have it part of OVN so that it is >> >>>>>>>>> easier to manage. >> >>>>>>>>> >> >>>>>>>>> But as Ales mentioned, we have many logical actions like - >> >>>>>>>>> put_dhcp_opts etc (which use controller action) >> >>>>>>>>> which will not work with the ovn-bridge-controller. Probably >> >>>>>>>>> ovn-bridge-controller can maintain its own symbol table. >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> Thanks >> >>>>>>>>> Numan >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> Adding @Tim Rozet <tro...@redhat.com> @Girish Moodalbail >> >>>>>>>>>>> <gmoodalb...@gmail.com> from ovn-k8s to comment. >> >>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> Adding Jakub Libosvar too, from the neutron side, as we briefly >> >>>>>>>>>> touched >> >>>>>>>>>> on the content of this proposal in a discussion while trying to >> >>>>>>>>>> onboard >> >>>>>>>>>> the OVN BGP support in neutron. IMO a centralized "provider >> >>>>>>>>>> network >> >>>>>>>>>> database" might fit that specific use case quite well because the >> >>>>>>>>>> open >> >>>>>>>>>> flow rules that needed to be added to the provider bridge were >> >>>>>>>>>> quite >> >>>>>>>>>> generic. >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>>>>>>>> I'm not suggesting this, but just giving an example or a >> >>>>>>>>>>>>>>> potential >> >>>>>>>>>>> user. >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> I believe it could be useful, but I'm unsure if it should >> >>>>>>>>>>>>>>>>> be >> >>>>>>>>>>>>>>>>> integrated into OVN directly or be a separate project >> >>>>>>>>>>>>>>>>> within >> >>>>>>>>>>>>>>>>> `ovn-org`. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> In my opinion it would be better as a standalone project >> >>>>>>>>>>>>>> within >> >>>>>>>>>>>>>> ovn-org. There is couple of reasons why: >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> 1) Separation between ovn actions and the new ones. I suppose >> >>>>>>>>>>>>>> the >> >>>>>>>>>>>>>> ovn-pr-controller won't support like put_arp etc. in other >> >>>>>>>>>>>>>> words >> >>>>>>>>>>>>>> actions that require userspace handling. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> 2) There are certain expectations about parameters, mostly ct >> >>>>>>>>>>>>>> actions >> >>>>>>>>>>>>>> and it feels a little strange to populate a specific register >> >>>>>>>>>>>>>> in >> >>>>>>>>>>>>>> order >> >>>>>>>>>>>>>> to get the action working. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> 3) Maintenance cost to some extent, standalone project might >> >>>>>>>>>>>>>> be >> >>>>>>>>>>>>>> easier to maintain, it can be written in different language >> >>>>>>>>>>>>>> if it >> >>>>>>>>>>>>>> would be better fit. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> 4) The abstraction can be generated automatically to some >> >>>>>>>>>>>>>> extent >> >>>>>>>>>>>>>> so most of the code might be actually a way to generate the >> >>>>>>>>>>>>>> parsing >> >>>>>>>>>>>>>> etc. >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> I'm fully aware that this would require some duplication. With >> >>>>>>>>>>>>>> that >> >>>>>>>>>>>>>> said, this just my opinion and I won't block any other >> >>>>>>>>>>>>>> decision. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Hi Ales, >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Thanks for the replies. I agree with your points. I think it >> >>>>>>>>>>>>> makes >> >>>>>>>>>>>>> sense to have >> >>>>>>>>>>>>> a separate project even if the code is duplicated. >> >>>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> I'm not sure I see anything blocking the ovn-pr-controller (or >> >>>>>>>>>>>> whatever >> >>>>>>>>>>>> we decide to call it) code from being part of the ovn-org/ovn >> >>>>>>>>>>>> project. >> >>>>>>>>>>>> >> >>>>>>>>>>>> It can be a standalone daemon (similar to controller/ovn- >> >>>>>>>>>>>> controller or >> >>>>>>>>>>>> controller-vtep/ovn-controller-vtep). >> >>>>>>>>>>>> >> >>>>>>>>>>>> It can even be written in a different language (e.g., rust) if >> >>>>>>>>>>>> we >> >>>>>>>>>>>> wish. >> >>>>>>>>>>>> >> >>>>>>>>>>>> Keeping it in the same project actually reduces maintenance cost >> >>>>>>>>>>>> because >> >>>>>>>>>>>> we can just reuse the expr parsing library from OVN directly. >> >>>>>>>>>>>> We can >> >>>>>>>>>>>> also reuse all the build/test infra (if we wish). >> >>>>>>>>>>>> >> >>>>>>>>>>>> It would also mean we wouldn't have to come up with different >> >>>>>>>>>>>> release >> >>>>>>>>>>>> strategies, contribution guidelines, etc. >> >>>>>>>>>>>> >> >>>>>>>>>>>> Also, with downstream in mind, it might be (slightly) easier for >> >>>>>>>>>>>> distros >> >>>>>>>>>>>> to package this new binary if its code lived in ovn-org/ovn. >> >>>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>>> In my option it is really not good to duplicate components in >> >>>>>>>>>>> different >> >>>>>>>>>>> repos. Unless we find ways to expose logical flow translation as >> >>>>>>>>>>> a >> >>>>>>>>>>> library >> >>>>>>>>>>> and share between the projects, I am inclined to use OVN repo >> >>>>>>>>>>> directly. >> >>>>>>>>>>> >> >>>>>>>>>>> Thanks, >> >>>>>>>>>>> Han >> >>>>>>>>>>> >> >>>>>>>>>>>>> Implementing in a different language would be nice but I think >> >>>>>>>>>>>>> it >> >>>>>>>>>>>>> will >> >>>>>>>>>>>>> take a lot >> >>>>>>>>>>>>> of effort to implement expr parsing and openflow encoding. >> >>>>>>>>>>>>> >> >>>>>>>>>>>>> Thanks >> >>>>>>>>>>>>> Numan >> >>>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>>>> Thanks, >> >>>>>>>>>>>> Dumitru >> >>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> I guess it depends a bit on the approach chosen for >> >>>>>>>>>>>>>>>> implementation >> >>>>>>>>>>> but >> >>>>>>>>>>>>>>>> at a first glance this seems as a good candidate for ovn-org >> >>>>>>>>>>>>>>>> to me. >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> Three possible options are: >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> - Integrate the `OVN provider controller` into `ovn-org/ >> >>>>>>>>>>>>>>>>> ovn`. >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> - Create a separate project within `ovn-org` (which >> >>>>>>>>>>>>>>>>> would >> >>>>>>>>>>>>>>>>> require >> >>>>>>>>>>>>>>>>> duplicating some files like `lib/actions.c`). >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> - Do not pursue this. >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> Listing it here because it's on the "con" side of things. >> >>>>>>>>>>>>>>>> :) I >> >>>>>>>>>>> wonder >> >>>>>>>>>>>>>>>> if we'll end up duplicating all OVS actions into OVN logical >> >>>>>>>>>>>>>>>> flow >> >>>>>>>>>>> actions. >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Actually that's my goal. Instead of using OpenFlow rules >> >>>>>>>>>>>>>>> directly, a >> >>>>>>>>>>>>>>> user can express >> >>>>>>>>>>>>>>> their pipeline as logical flows and not worry about the >> >>>>>>>>>>>>>>> intricacies of >> >>>>>>>>>>>>>>> openflow syntax. >> >>>>>>>>>>>>>>> It does add another layer of abstraction for sure. >> >>>>>>> >> >>>>>>> >> >>>>>>> With maintenance cost in mind, we definitively prefer hosting this in >> >>>>>>> the main repository, and I think it fits nicely in there. >> >>>>>>> >> >>>>>>> -- >> >>>>>>> Frode Nordahl >> >>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> Thanks >> >>>>>>>>>>>>>>> Numan >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> I welcome your thoughts and would like to know if other OVN >> >>>>>>>>>>>>>>>>> users >> >>>>>>>>>>> have >> >>>>>>>>>>>>>>>>> similar requirements. >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> A proof-of-concept is available here: >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>> https://github.com/numansiddique/ovn/tree/ >> >>>>>>>>>>> provider_controller_support. >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> If there is a consensus in pursuing this further, I'll >> >>>>>>>>>>>>>>>>> work on >> >>>>>>>>>>>>>>>>> refining the patches and submit them as RFC to start with. >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> In general I have no objections to an RFC. (CC the rest of >> >>>>>>>>>>>>>>>> the >> >>>>>>>>>>> maintainers). >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> Thanks, >> >>>>>>>>>>>>>>>>> Numan >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> Regards, >> >>>>>>>>>>>>>>>> Dumitru >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> Thanks, >> >>>>>>>>>>>>>> Ales >> >>>>>>>>>>>>> >> >>>>>>>>>>> >> >>>>>>>>>> >> >>>>>> >> >>>>>> Thanks, >> >>>>>> Dumitru >> >>>>>> >> >>>>> >> >>>> >> >>> >> >> >> > >> _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
