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

[David Ahern]

On 3/26/17 11:02 AM, Thomas Morin wrote:
> 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.

And that's my takeaway from past discussions on this topic (number of
labels).

> 
> 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 believe the consensus was 8 but Olivier had a use case for more. The
way I have this coded means the performance impact is to users adding
more and more labels - which is expected and appropriate.


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

no idea. I need him to clarify.


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

no. Ingress is handled by a lightweight tunnel infrastructure. In 'ip'
terms the route specifies lwt with mpls encap. LSP MPLS is handled as a
typical protocol family with its own route database.

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

each nexthop has its own label stack. The nexthops are essentially an
array at the end of the mpls route.