[ovs-dev] [PATCH ovn 1/3] ovn: Enforce unique tags for container interfaces.

Jesse Gross jesse at nicira.com
Tue Apr 7 17:49:55 UTC 2015


On Tue, Apr 7, 2015 at 8:29 AM, Thomas Graf <tgraf at noironetworks.com> wrote:
> On 04/07/15 at 10:20am, Russell Bryant wrote:
>> IIRC, the proposal was actually quite explicit that the tag is a VLAN
>> ID.  It's not a hidden implementation detail because something (not OVN)
>> has to set up ovs inside the VM with all of the containers attached and
>> have it tag traffic from each container.
>>
>> With that said, I'd be happy to see alternatives.  I brought it up
>> briefly here:
>>
>> http://openvswitch.org/pipermail/dev/2015-March/052584.html
>
> Thinking out loud:
>
> I remember this discussion. One alternative that comes to mind is to
> simply push a Geneve header in front of it. It would provide a lot
> more flexibility down the road and we could transmit additional metadata
> between inner and outer OVS later on.
>
> The OVN model would look the same, except that tag would be a 32 or
> 64bit Geneve option of known class and type.
>
> The disadvantages to this is obviously increased overhead but given
> that these packets never hit the wire and go straight from OVS to OVS.
> We could come up with a simplified protocol using a new ethernet type.
>
> eth + gva + ip + tcp

For what it's worth, I think something like this is inevitable at some
point for a different reason anyways. Virtual appliances like
firewalls are going to want to start consuming some of the metadata
that is available in tunneling protocols and they are going to need a
way to get at it. I think it would be easy enough to map the currently
proposed vlan tag into the 24-bit VNI in the base header to
immediately get some breathing room and then have options available
future additional metadata in the future.

It seems like it is somewhat of a pain to introduce a non-IP based
version of Geneve (from an implementation standpoint, not the
protocol) since it will need new code paths for offloading, etc. It's
possible but it would be simpler if we can avoid it.



More information about the dev mailing list