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

[Lori Jakab]

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.

Ok, looking forward to the detailed review.

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

Sounds good.