[ovs-dev] [PATCH RFC ovn] Add VXLAN support for non-VTEP datapath bindings

Ben Pfaff blp at ovn.org
Fri Mar 20 21:06:22 UTC 2020

On Fri, Mar 20, 2020 at 03:35:53PM -0400, Ihar Hrachyshka wrote:
> On Fri, Mar 20, 2020 at 11:38 AM Ben Pfaff <blp at ovn.org> wrote:
> >
> > We have a bit of a terminology problem here, which is going to add
> > confusion to the code and the documentation.  This is that VTEP, a VXLAN
> > Tunnel End-Point, has a generic definition (a node that hosts VXLAN
> > tunnels) that is different from how we use it in OVN (a physical switch
> > that connects to an OVN deployment through a simple OVSDB schema).
> >
> > This problem existed before, but before this change it was not a serious
> > problem because OVN only used VXLAN tunnels for the latter kind of "VTEP".
> > This change is going to make it worse.
> >
> > We can't change generic terminology.  I suggest that we should choose a
> > new name for what we currently call a "VTEP" in OVN parlance, and then
> > change all references to VTEP to the new name.
> Thanks for the comment. I totally agree that VTEP terminology in OVN
> is a bit confusing.
> What would be good alternatives? "Alien switch"? "Foreign switch"?
> "Remote switch"? (I saw "remote" being used for chassis - not sure how
> they relate.) Perhaps someone with better taste - and knowledge - of
> English could lend a hand here.

Naming is hard.  Here, I think that it's more important to come with a
distinct name than a good name, although I do hope to come up with one
that we like.

For me, "alien switch" and "foreign switch" seem distinct enough, but
not very descriptive.  I think that "remote switch" isn't distinct
enough because "remote" ends up being used in random places in the
documentation anyway.

Back at Nicira, sometimes we would talk about this kind of thing as an
"on-ramp" switch, meaning that it was good enough to get packets into
the system.  (I guess that in British/international English, this would
be a "slip road" switch.)  If people like it, we could adopt the term
"ramp switch".  I think that this would be a distinct name, since I've
never heard the term before, and it has a decent metaphor behind it.

What do you think?

> Assuming we pick a term to use to describe these out-of-cluster
> switches, we should consider the impact of the rename. Renaming
> internal symbols / functions is trivial. But "vtep" is used in OVN
> schema (for example, for port binding 'type' attribute). Do we want to
> rename those too? If so, what considerations should we apply when
> doing it? Any guidance as to maintaining backwards compatibility?
> Also, is such a rename something that should happen at the same moment
> when we add support for VXLAN for in-cluster communication? Or should
> it be a separate work item? (If so, do we expect it to land before or
> after the core VXLAN implementation lands?)

We can't (or at any rate should not) change the terms in the schema, but
we can change other places and point out to people in a few places that
a "ramp switch" is sometimes, confusingly, called a "vtep".

More information about the dev mailing list