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