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.
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?
-Lori
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
