[frr] Fwd: Re: [PATCH net-next 0/4] net: mpls: Allow users to configure more labels per route
thomas.morin at orange.com
Sun Mar 26 13:02:15 EDT 2017
[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
> -------- 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.
More information about the dev