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

["Carlos Pignataro (cpignata)" <[e-mail]>]

Hi, Rob,

> On May 3, 2016, at 8:11 PM, Rob Shakir <[e-mail]> wrote:
> 
> [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).

I agree with the realities of hardware.

However, that’s a big assumption and design principle that I could not find mentioned in draft-ietf-mpls-spring-entropy-label. Did I miss it? (in fact, I could not find “min”).

Additionally, if RLD = min (RLDi for i=..network), what happens if there’s a single node that does not support RLD?

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

I do not disagree with that pragmatic approach. But there are implications which ought to be spelled out.

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

The paraphrasing is accurate, but I feel it does matter. Say you have a series of Adj-labels. For example (N=node, A=Adj): N1-A1-A2-A3-N2-Payload. N1 is top, N2 is bottom of stack. There’s an RLD of 4. Placing a EL/ELI after A2 or A3 is effectively of null value practically. (E.g., A2 and A3 are specific links, but N1 and N2 are long loose paths). The places where LB could happen while the packet is switched with N1 and N2 will not have an EL/ELI readable, and A2 A3 won’t use EL/ELI.

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

I think RLD lower than 3 will get us in the same place.

> - there is nothing that can be done to satisfy all requirements.

I agree, so the function is one to maximize effect, not 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.

Right — hard requirement is that an EL/ELI gets placed in a way where the receiving node will understand it. This is important or the packet gets dropped.
The rest is the best that can be done, given RLDi of nodes in the (potential) path, and given how many nodes are traveled using a single label stack entry. I think the latter is not considered or mentioned, and the former is implicitly oversimplified.

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

Absolutely agree. My point is only that those assumption should be listed as they carry operational considerations.

> The first option is assume that RLD = 1,

Sorry, here I got lost: RLD of 1 means there’s no point in inserting any EL/ELI pairs. An RLD (min RLD of the whole path or network) of 3 means insert in-between every label. Or did I misunderstood?

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

To me, and again I may be misunderstanding, RLD does not mean that a node understands Entropy Labels. A node with an RLD of 7 can still not use EL/ELI and only use the deepest readable label, conceptually.

This, I know, compounds more the complexity of the problem this draft is aiming at solving.

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

As you can see, I still have either questions or misunderstandings, or I am pointing out things that might be broken.

Please do let me know if anything I commented about is not clear.

Thanks!

— Carlos.

> r.
> 
> 
> 
>