[ovs-dev] adding an option for GRE tunneling without an Ethernet header

[thomas.morin at orange.com]

Hi Lori,

2014-04-14, Lori Jakab:
> On 4/14/14, 11:01 AM, thomas.morin at orange.com wrote:
>> 2014-04-11, Lori Jakab:
>>> On 4/11/14, 4:24 PM, thomas.morin at 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.

Good.

>>>> - 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.

Well, as you suggest below, if the Ethernet payload is MPLS, then, until 
you have popped an MPLS label and recirculated the packet, you will not 
have access to the L3 destination address anyway (assuming there is an 
IP packet somewhere inside).

And you need to keep in mind that, typically, in the general case, with 
an MPLS dataplane, you cannot derive anything (including a tunnel 
destination) from an MPLS-encapsulated IP packet IP addresses without 
also checking which was the value of the MPLS label.

> 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.

Well, you could just match on dl_type=0x0800 (IPv4) or dl_type=0x86dd 
(IPv6), in that case, you know you don't have an MPLS label and you can 
forward the IP packet in a LISP tunnel.

The day you have a valid case (which is not entirely obvious) for 
forwarding an MPLS IP payload over LISP without checking the value of 
the MPLS label, you can test that traffic is mpls in your flow in a 
similar manner before doing a pop_mpls,outout:<lisptunnelport>.


> I think your approach would work if pop_mpls can be a no-op for flows
> with no MPLS headers.

See above, if you apply your LISP tunnel output action to a flow which 
only matches IP packets, you're good.


>> 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?).

You are correct that only recirculation would provide that.
And recirculation won't happen until you explicitly change (typically 
pop) the label stack.

> 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.

It seems that we agree, right ?

-Thomas
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.