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

Ben Pfaff blp at ovn.org
Fri Mar 20 15:38:33 UTC 2020


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,

Ben.


More information about the dev mailing list