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

[Jesse Gross]

On Tue, Jun 17, 2014 at 12:21 PM, Lori Jakab <lojakab at cisco.com> wrote:
> 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.

Yeah, it seems like the we're all set on this issue. I'll take a look
at the patch tomorrow.