On Thu, Feb 04, 2016 at 09:49:35AM +0000, Ofer Ben-Yacov wrote:
> The tunnel key in decoupled from the actual implementation of the tunnel.
> The only tunnel protocol that is currently supported in this schema is
> VxLAN. (the encapsulation is set by enum with single value:
> vxlan_over_ipv4 ). This is fine and the new key field can be used to set
> the VIN of the VxLAN tunnel. In the future, when the schema will have more
> encapsulations (need to add more values to the encapsulation_type enum),
> the key still will be used as all tunnels use some kind of key for
> segmentation (NVGRE, Geneve or even MPLS label is a kind of a key). The key
> is optional anyway so if someone will what to use the schema with a
> key-less tunnel it still can be used.
>
> I actually did not add something that was not thought before. If you look
> at the hardware VTEP document (http://openvswitch.org/docs/vtep.5.pdf),
> under Logical_Switch section it is written:
>
> *Per Logical_Switch+Physical_Locator pair. That is, each logical switch may
> be assigned a different tunnel key on every Physical_Locator. This model is
> especially flexible. In this model, Physical_Locator carries the tunnel
> key.*
>
> Can you point me to where the version is set? I will change it to 1.5.0 as
> you suggested.
>
> We are using this new field to enable connection of multiple tunnels that
> each use different tunnel key. We use it for inter-cloud connection. It is
> a new feature that I'm adding to the L2 Gateway. You can see the spec here:
>
> https://review.openstack.org/#/c/270786/
>
> The new code depend on the ability to use different keys in multiple
> tunnels in the same logical switch.
OK, I understand now.
I posted a v4:
http://openvswitch.org/pipermail/dev/2016-February/065759.html
Will you review it and ensure that it properly reflects your intent?
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
