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. >> >> 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. >> 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. 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 > >> > > >> > >> > 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
