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

Ihar Hrachyshka ihrachys at redhat.com
Fri Mar 20 19:35:53 UTC 2020


On Fri, Mar 20, 2020 at 11:38 AM Ben Pfaff <blp at ovn.org> wrote:
>
> On Fri, Mar 20, 2020 at 01:07:11AM -0400, Ihar Hrachyshka wrote:
> > this patch is not ready, sending it to collect initial feedback on the
> > path taken. Let me know.
> >
> > Because of limited space in VXLAN VNI to pass over all three of -
> > datapath id, ingress port, egress port - the implementation ignores
> > ingress; and splits the remaining 24 bits of VNI into two chunks, 12
> > bits each - one for datapath and one for egress port.
> >
> > Limitations: because ingress port is not passed, ACLs that rely on it
> > won't work with VXLAN; reduced number of networks and ports per
> > network (max 4096 for both).
> >
> > Renamed MLF_RCV_FROM_VXLAN_BIT into MLF_RCV_FROM_VTEP_BIT to reflect
> > the new use case.
> >
> > TODO:
> > * limit maximum number of networks / ports per network for vxlan
> >   datapaths.
> > * forbid acls matching against ingress port for vxlan datapaths.
> > * update test suite.
> > * update documentation.
>
> 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.

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?)

Thanks again for the comment, let me know if there are other concerns here,
Ihar

>
> Thanks,
>
> Ben.
>



More information about the dev mailing list