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

Thomas Graf tgraf at noironetworks.com
Tue Apr 7 18:14:29 UTC 2015


On 04/07/15 at 10:49am, Jesse Gross wrote:
> On Tue, Apr 7, 2015 at 8:29 AM, Thomas Graf <tgraf at noironetworks.com> wrote:
> > 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.

Good point.

> 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.

Certainly not needed from the start and given GRO works properly
we might not even care that much about the overhead in the end.

BTW, any particular reason you are mentioning offloading? I was
not expecting to ever see such a frame on an actual wire.



More information about the dev mailing list