[ovs-dev] [PATCH v3 3/3] datapath: add layer 3 flow/port support

Jesse Gross jesse at nicira.com
Thu May 22 23:07:22 UTC 2014

On Tue, May 20, 2014 at 9:27 PM, Lori Jakab <lojakab at cisco.com> wrote:
> On 5/21/14, 4:10 AM, Jesse Gross wrote:
>> On Tue, May 13, 2014 at 7:02 AM, Lorand Jakab <lojakab at cisco.com> wrote:
>>> Implementation of the pop_eth and push_eth actions in the kernel, and
>>> layer 3 flow support.
>>> Signed-off-by: Lorand Jakab <lojakab at cisco.com>
>> Lori, can you take a look at the thread with Thomas Morin and see if
>> the outcome is reasonable to you? It seems like we've reached a
>> conclusion at this point.
> I have been following that thread, and I only submitted version 3 of my
> patches since you suggested at some point to include the Ethertype only when
> absolutely necessary.  Based on our previous discussion, it wasn't
> absolutely necessary for LISP.
> By outcome, I assume you mean this message:
>     http://openvswitch.org/pipermail/dev/2014-May/040291.html
> In that case, please confirm my interpretation of "unconditionally include
> it when it is part of the protocol" for LISP encapsulated packets: since the
> LISP encapsulation header doesn't contain the Ethertype of the packet that
> follows and it can be inferred from the first attribute in the packet (which
> can only be either IPv4 or IPv6), the Ethertype should not be included.

Yes, what you have looks conceptually right. I've been waiting until
the other thread concludes to look at the patch in more detail.

> On the other hand, there are two IETF drafts proposing multi-protocol
> support to VxLAN and LISP respectively:
>     http://tools.ietf.org/html/draft-quinn-vxlan-gpe
>     http://tools.ietf.org/html/draft-lewis-lisp-gpe
> If they get traction and get adopted/implemented, depending on a flag in the
> header, both protocols can specify the Ethertype of the following packet,
> and make both protocols able to carry arbitrary payloads.  Do we make the
> presence of the Ethertype Netlink attribute dependent on that flag?  Or
> would it be better to start sending the Ethertype unconditionally already
> (for LISP at least), as a the new tunnel attribute you propose?

I think we can leave LISP as it is for now and make the EtherType
dependent on the flag if/when the drafts are implemented. At a
minimum, there shouldn't be any of the potential problems that Thomas
listed because LISP is restricted to encapsulating IPv4/v6 as
currently defined.

More information about the dev mailing list