Hi Jesse,
On 5/23/14, 2:07 AM, Jesse Gross wrote:
On Tue, May 20, 2014 at 9:27 PM, Lori Jakab <loja...@cisco.com> wrote:
On 5/21/14, 4:10 AM, Jesse Gross wrote:
On Tue, May 13, 2014 at 7:02 AM, Lorand Jakab <loja...@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 <loja...@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.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
