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
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
