On 7/10/26 10:30 AM, Dumitru Ceara wrote: > On 7/9/26 10:18 PM, Mark Michelson wrote: >> Hi, Dumitru, thanks for the proposal! >> >> On Thu, Jul 9, 2026 at 8:04 AM Dumitru Ceara <[email protected]> wrote: >>> >>> Hi all, >>> >>> The currently established terminology we use in OVN for various types of >>> routers and router ports is: >>> >>> - gateway routers >>> - distributed routers >>> - these can optionally have "distributed gateway ports" (DGP) >>> >>> Our architecture docs describe them to some extent: >>> https://github.com/ovn-org/ovn/blob/main/ovn-architecture.7.xml#L619-L752 >>> >>> However, while established contributors/users might be used to the >>> terminology and how the different types of routers/ports behave in >>> practice, the naming is in my opinion extremely confusing. >>> >>> Let's start with the "Gateway Router": >>> >>> At a first glance one might think that this is the only type of router >>> that can be used as a gateway out of the cluster. That's not true, we >>> also can use DGPs (I'll go to those later). I didn't check but I assume >>> the naming was chosen back when the implementation for such routers was >>> added and it was the only way to implement OVN gateways. But that's not >>> necessarily true anymore. >>> >>> The way they work is through a NB database >>> logical_router.options:chassis configuration which specifies on which >>> chassis the router is "bound". That means the router's logical pipeline >>> only gets executed on that chassis. Whenever traffic that's being >>> processed on a different hypervisor needs to logically enter the >>> "gateway router's" pipeline, the traffic will be tunneled towards the >>> chassis the router is bound to. >>> >>> Then the DGP, "distributed gateway port": >>> >>> At a first glance one might think that the port (and corresponding >>> router pipeline) implementation is somehow distributed across multiple >>> OVN hypervisors. >> >> I think the reason is that "distributed gateway port" is a confusing >> shortening of "distributed [router's] gateway port" or "gateway port >> on a distributed router". In other words, the port itself is not >> distributed, but the router is. >> >>> >>> That's definitely not true, it's actually the opposite. This is a >>> router port that's part of a distributed router with the restriction >>> that traffic that needs to be logically forwarded out that port and >>> traffic that is received on that port will be first tunneled to the >>> chassis the DGP is "bound" to. Binding the DGP to a chassis happens >>> either by configuring a NB.Gateway_Chassis or a NB.Ha_Chassis_Group (for >>> HA) for that port. >>> >>> Then there's the "gateway" part of the DGP name. I didn't check the >>> history closely but I assume this is something that was chosen just >>> because processing traffic on that router port is very similar to the >>> "Gateway Router" case. >>> >>> Moreover, we know we have users that configure DGPs that are not really >>> gateways out of the cluster. >>> >>> For example, ovn-kubernetes configures uses a distributed "cluster >>> router" (in ovn-kubernetes terminology) whose main purpose is to connect >>> per-node logical switches together. The router ports attached to those >>> switches are all configured as DGPs for the sole purpose of reducing the >>> amount of local datapaths ovn-controllers on each node need to create >>> OpenFlow rules for. In the ovn-kubernetes case, there are actually >>> dedicated "gateway routers", one per node, that are used as real >>> gateways out of the OVN cluster. >>> >>> This brings me to the proposal part.. >>> >>> Would it make sense to update the terminology across the OVN tree's >>> documentation (and code) and stop using "gateway router" and >>> "distributed gateway port"? >> >> YES!! As you have pointed out, there is much confusion about the term, >> and it's not just gatewaying that such ports have use for. >> >>> >>> We could instead use (and encourage our users to do the same) more >>> explicit alternatives based on the real behavior of the router/router ports. >>> >>> One that comes to mind is: >>> - "pinned" router/router-port >>> >>> Alternatives could be: >>> - "chassis-specific" router/router-port >>> - "chassis-local" router/router-port >>> >>> Looking forward to hearing opinions from the community! >> >> I would steer clear of any options that use the word "local" since we >> already have terminology like "localnet" and "localport". There's also >> the issue of local vs. remote ports when talking about ovn-ic setups. >> Therefore, I think "local" is overloaded and doesn't need to be >> expanded further. >> >> I think "chassis-specific" gets the point across better than "pinned", >> but "chassis-specific" is also more of a mouthful than "pinned". I >> would be happy if either of these were chosen. >> >> Another option might be to use the word "bind/bound" for these >> options, since we already use this term for other types of ports. In >> my view, binding a VIF logical switch port to a chassis is not really >> any different than binding a logical router port or logical router to >> a specific chassis. The method is different, but the result is the >> same. That's another option to consider. >> > > I agree, it's probably better than "pinned", so: > > - "bound router" > - "bound router-port" > > Right? OTOH the acronym would potentially become confusing. /o\ > > BR > BRP
Yeah, BR may be confusing. Maybe "chassis-bound" ? CBR, CBP/CBRP ? Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
