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

Ihar Hrachyshka ihrachys at redhat.com
Mon Mar 23 22:39:14 UTC 2020

First, some questions as to implementation (or feasibility) of several
todo items in my list for the patch.

1) I initially thought that, because VXLAN would have limited space
for both networks and ports in its VNI, the encap type would not be
able to support as many of both as Geneve / STT, and so we would need
to enforce the limit programmatically somehow. But in OVN context, is
it even doable? North DB resources may be created before any chassis
are registered; once a chassis that is VXLAN only joins, it's too late
to forbid the spilling resources from existence (though it may be a
good time to detect this condition and perhaps fail to register the
chassis / configure flow tables). How do we want to handle this case?
Do we fail to start VXLAN configured ovn-controller when too many
networks / ports per network created? Do we forbid creating too many
resources when a chassis is registered that is VXLAN only? Both? Or do
we leave it up to the deployment / CMS to control the chassis / north
DB configuration?

2) Similar to the issue above, I originally planned to forbid using
ACLs relying on ingress port when a VXLAN chassis is involved (because
the VNI won't carry the information). I believe the approach should be
similar to how we choose to handle the issue with the maximum number
of resources, described above.

I am new to OVN so maybe there are existing examples for such
situations already that I could get inspiration from. Let me know what
you think.

More comments inline below.

On Fri, Mar 20, 2020 at 5:06 PM Ben Pfaff <blp at ovn.org> wrote:
> 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?

I am not a native speaker so it's hard for me to tell if this sounds
good for a native, but from my perspective it's 1) unique and 2) has a
metaphor behind it that makes sense. Unless other people have strong
opinions or better alternative, I am ok with following the "ramp
switch" terminology. I like it.

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

Gotcha. Any preferences as to whether to consider it a preparatory
work item; a follow-up; or a part of the VXLAN implementation? (I lean
towards handling the ramp term introduction as an independent
preparatory step.)


More information about the dev mailing list