On 4/14/14, 11:01 AM, thomas.mo...@orange.com wrote:
Hi Lori,
2014-04-11, Lori Jakab:
On 4/11/14, 4:24 PM, thomas.mo...@orange.com wrote:
The result is the following:
- an option is added to GRE tunnel port, to allow making them OVS l3ports
My first impression is that starting with my patches and now yours there
are a lot of different places with is_layer3 or l3port type of bool
members, but I don't really have a more elegant proposal either.
Well, there is a specific need for GRE: since the protocol can traffic
both with an Ethernet header and without, it is useful to be able to
specify which behavior we want at port creation time.
I agree that it should be possible to specify the operating layer of a
GRE port at creation time.
- the vport-gre.c code is adapted to treat GRE ethertype consistently
with the type of the port (i.e. on emission the GRE ethertype is chosen
based on whether or not the skb is layer3; symmetrically on reception)
I also adapted pop_eth code, so that it strips the Ethernet and VLAN
headers, but not the MPLS headers if there is any (I only modified the
linux kernel datapath actions, the userland datapath I left untouched
for now).
This is an issue for LISP, since it cannot have MPLS headers in the
encapsulated packets.I see two solutions: 1) add an option to the
pop_eth action to specify if MPLS header(s) should stay there; or 2) or
just use pop_eth() as is and add push_mpls() actions to push the MPLS
headers back (they should be saved somehow).
Or maybe there's a better solution, I'll let the core developers to
voice their opinions.
Popping the MPLS header before sending the packet on the LISP tunnel is
actually the right solution IMO. The flow that forwards the packet on
the LISP tunnel would have a "pop_mpls" action before "output".
I would like to be able to create flows to encap LISP packets by
matching on the L3 destination address of the packet, and wildcarding
everything else. The flow now have actions
(pop_eth,set_tunnel,output). If I add pop_mpls after pop_eth, the flow
may be rejected, since there is no MPLS match. At least this is what I
understood from Jesse Gross how it should work in the datapath, but I
didn't review the patches proposed for MPLS in the datapath.
I think your approach would work if pop_mpls can be a no-op for flows
with no MPLS headers.
Implicitly popping the mpls header along with the ethernet header does
not help a lot I think; in all practical cases, assuming you need to
combine MPLS and LISP, you will need to check the MPLS header anyways
(in particular the label value). Among the reasons is that, in the
general case, you cannot assume that what is beyond the MPLS header
would be IP.
True, flows with an mpls match can't even see what's after the mpls
headers (maybe with recirculation?). Either way, since the LISP spec
only allows IPv4 or IPv6 payloads, I would only LISP encapsulate flows
matching on those L3 protocols, so that avoids the issue for me.
-Lori
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
