[ovs-dev] OVN: Use of Tunnel Keys

[Justin Pettit]

In one of the review threads, we were discussing how we should make use of the metadata in the tunnels.  The patches that Ben has sent out goes the route of having each logical port have a unique tunnel key.  I had envisioned a different approach, so I thought it would be worth starting a thread to hash out what direction we want to go.

I was thinking that we'd use a 24-bit VNI that would identify a logical switch.  In Geneve, it would be in the VNI field, and in STT, it would be in the lower 24 bits of the 64 bit key.  The local OVS would receive packets from a particular VNI, and then look at the DMAC to figure out which logical ports should receive it.

For port security, we would add a logical port that would uniquely identify a port within a particular VNI (ie, the value is only unique for a particular VNI).  For this, the logical port would only be used to identify the ingress port, since the receiving OVS would still be responsible for local replication and enforcing policies.  We would store the logical port in a TLV extension in Geneve and in the next (let's say) 16 bits of the STT header.

There are a few benefits that I see to this approach:

	- It makes it easier to debug the system because the keys that are used match the logical network configuration.

	- It reduces replication because a broadcast or multicast packet only needs to be sent once to a hypervisor that has multiple recipients.

	- It's easy to allocate IDs, since the VNI needs to be globally unique, but the interface ID only needs to be unique within a particular VNI.  I expect interface IDs to be changing a lot more frequently than VNIs.

	- Although it shouldn't matter in practice, It may be a bit more secure because the side that is responsible for enforcing policies for its interfaces (VIFs or gateway ports) is actually doing the enforcement.  This may become an issue if third parties start implementing their own "ovn-controllers" that connect to the Southbound database (e.g., they want to implement a physical gateway that is more capable than a VTEP, but less flexible than a hypervisor running OVS.)

	- For receiving traffic *from* gateways, the enforcement needs to happen on the receiving hypervisor, since the VTEP schema probably won't provide enough fine-grained control.

Here are some drawbacks:

	- ovn-controller needs to be a bit smarter about only sending multicast packets once to a particular hypervisor.

	- The pipeline is a bit more complicated because there needs to be a receive-side pipeline, so you can't just immediately hand the packet to the specified VIF based purely on the tunnel key.

	- For receiving traffic *on* gateways, the enforcement needs to happen on the sending hypervisor, since the VTEP schema probably won't provide enough fine-grained control.

Anyway, I figure this is a good place to start the conversation, so let's go.  :-)

--Justin