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. 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: - 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. >>> 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. > 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. >>> >>> 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 > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
