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

Lori Jakab lojakab at cisco.com
Tue Jun 17 19:21:40 UTC 2014


Hi Jesse,

On 5/23/14, 2:07 AM, Jesse Gross wrote:
> 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.

Now that I think we can consider the other thread concluded, can you 
please take a look at the patch?  In my understanding, the conclusion 
was that LISP as-is should not send Ethertype information over Netlink, 
not even in the tunnel metadata, since the protocol itself doesn't send 
it on the wire.  Once we implement GPE (see below), we can change that 
for GPE-enabled LISP tunnels.

-Lori

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