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

[Jesse Gross]

On Wed, Jun 18, 2014 at 9:45 PM, Jesse Gross <jesse at nicira.com> wrote:
> 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.

Hi Lori,

Would you mind sending out a rebased version of this series?