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

Lori Jakab lojakab at cisco.com
Wed May 21 04:27:15 UTC 2014


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.

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?

-Lori



More information about the dev mailing list