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