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