[frr] Fwd: Re: [PATCH net-next 0/4] net: mpls: Allow users to configure more labels per route

[Thomas Morin]

Hi David,

[adding my colleague Bruno to the list, he may correct things I might 
have oversimplified on segment routing, or have a idea about 12]

2017-03-25, David Ahern:
> Eric's question below is basically adding labels at tunnel ingress vs
> while traversing the LSP. I was generically increasing both to more than
> 2 labels. Opinions?

An MPLS packet may in transit receive additional labels. I most cases 
(all?), this will be most properly seen as a LSP hierarchy (tunneling 
one LSP into another LSP), so closer to a notion of ingress rather than 
something related to the initial LSP. But I don't know if the 
distinction is of importance.

The cases that comes to mind would be:
- tunneling into a fast-reroute bypass LSP (possibly a segment routing 
LSP, see segment routing TI LFA)
- seamless MPLS
- carrier's carrier type of deployment

In these cases a router could receive an MPLS packet, and possibly after 
popping the topmost, push a stack of labels onto the packet.

About the email below:
- how did 12 end up being considered "covering all currently known 
segment routing use cases" ? it seems that SR could use an arbitrary 
number of labels  (not saying 12 is a bad number, but...)
- I'm not sure what Eric's idea of "running the packet a couple of times 
through the mpls table to get all of the desired labels applied" would 
mean: after the first lookup, what data would be used as key for the 
following lookup ?
- back to your question, which seems to imply one could possibly 
increase number of labels for ingress without increasing number of 
labels for transit: isn't the same datastructure used in both to 
represent an mpls next hop (in RFC3031, both the ILM and FTN point to 
NHLFE entries, but I haven't digged enough to identify how these maps to 
the kernel implementation)
- would a concept of a linked list of mpls_nh make sense, each with one 
label to impose, make sense, so that no hard limit is put on the label 
stack depth?

-Thomas



> -------- Forwarded Message --------
> Subject: Re: [PATCH net-next 0/4] net: mpls: Allow users to configure
> more labels per route
> Date: Sat, 25 Mar 2017 14:15:54 -0500
> From: Eric W. Biederman <ebiederm at xmission.com>
> To: David Ahern <dsa at cumulusnetworks.com>
> CC: netdev at vger.kernel.org, roopa at cumulusnetworks.com, rshearma at brocade.com
>
> David Ahern <dsa at cumulusnetworks.com> writes:
>
>> Bump the maximum number of labels for MPLS routes from 2 to 12. To keep
>> memory consumption in check the labels array is moved to the end of mpls_nh
>> and mpls_iptunnel_encap structs as a 0-sized array. Allocations use the
>> maximum number of labels across all nexthops in a route for LSR and the
>> number of labels configured for LWT.
>>
>> The mpls_route layout is changed to:
>>
>>    +----------------------+
>>    | mpls_route           |
>>    +----------------------+
>>    | mpls_nh 0            |
>>    +----------------------+
>>    | alignment padding    |   4 bytes for odd number of labels; 0 for even
>>    +----------------------+
>>    | via[rt_max_alen] 0   |
>>    +----------------------+
>>    | alignment padding    |   via's aligned on sizeof(unsigned long)
>>    +----------------------+
>>    | ...                  |
>>
>> Meaning the via follows its mpls_nh providing better locality as the
>> number of labels increases. UDP_RR tests with namespaces shows no impact
>> to a modest performance increase with this layout for 1 or 2 labels and
>> 1 or 2 nexthops.
>>
>> The new limit is set to 12 to cover all currently known segment
>> routing use cases.
>
> How does this compare with running the packet a couple of times through
> the mpls table to get all of the desired labels applied?
>
> I can certainly see the case in an mpls tunnel ingress where this might
> could be desirable.    Which is something you implement in your last
> patch.  However is it at all common to push lots of labels at once
> during routing?
>
> I am probably a bit naive but it seems absurd to push more
> than a handful of labels onto a packet as you are routing it.
>
> Eric
>