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.