Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label

[Rob Shakir <[e-mail]>]

[readding mpls@]

> On May 3, 2016, at 14:22, Carlos Pignataro (cpignata) <[e-mail]> wrote:
> 
> There’s another unanswered piece for me, which is: All those routers are advertising ELC and RLDs. As long as R5 and R10 are ELC, then you can add EL/ELIs there.
> BUT, what is the RLD of the *loose* path R1..R5 and of the *loose* path R6..R10? 

RLD is unfortunately something that we have to deal with. There is nothing really in the MPLS specs that tells us that an assumption that one can optimise hardware to have a shallow RLD is OK AIUI, but still we have many systems that have a depth to which they can read.

To this end, the way that we have implemented things is to assume that RLD = min(network). This actually has implications for service implementations, since your customer L2VPN MTU will be impacted by the number of <ELI, EL> pairs you need to allow room for within the core. Since a customer service must work over all paths that reroute might happen over; most transport LSPs will have at least a loose backup path option; and the fact that old hardware is long-lived - then min(network) seems to be the manageable and most robust option to take. 

So, your question, to me - please correct me if you don't feel it is accurate - comes down to whether the entity processing some label can find some entropy within its readable depth. At the point that we have considered min(network) for the RLD then it does not matter whether the next label is a adjacency or node segment we know that within our RLD then there is a <ELI, EL> pair. 

Note that the problem case I see here occurs when the RLD for the network becomes sufficiently low. If it is set to 1 then we need to be able to push more labels at the head end. In the worst case, the iLER can push fewer labels than the least capable LSR can read. At this point, we are stuck - there is nothing that can be done to satisfy all requirements. The approach that the coauthors of this draft discussed tries to do the best it can to make entropy available to all systems,  since we know that not having entropy really hurts for load-sharing - but it also does not mandate that a system does not send a packet that one system in the network cannot hash properly. 

This comes back to the problem you presented around whether all systems must be upgraded or not, the answer is no, rather like the existing EL behaviours. We essentially need to make an assumption about RLDs of the nodes that do not advertise RLD. The first option is assume that RLD = 1, however, this means potentially over-inserting ELs (the worst case would be that we do not know whether they, as midpoints, even know about the EL - and insert them even though they cannot hash on them). The alternative is to assume they know how to hash themselves (or simply are expected not to hash) when EL is not present, since this has been true for systems historically. This results in some cases where we do not have entropy but would desire it. Operators need to make choices themselves as to what to do here - which may include limiting the label stack depth imposed by their policies on a head end, or doing LSP stitching or segment-expansion somewhere else in the network. 

There are many procedures here which come down to combining the various standardised and non-standardised procedures that may be available to an operator to balance their requirements for entropy against their requirements for path strictness, and the number of approaches deployed in their network. 

Please let me know if there are things here that not clear, I am happy to expand on them. 

r.