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

Hi Carlos,

In your example (N1-A1-A2-A3-N2-Payload), if you consider RLD=4 network wide, with a bottom_to_top EL insertion you may have (considering no limit in push) : N1-ELI-EL-A1-A2-ELI-EL-A3-N2-ELI - EL - Payload. 
With a top_to_bottom insertion, you may have : N1-N2-ELI-EL-A1-A2-ELI-EL-N2-ELI-EL-Payload

Keeping EL for Adj-SID is still good as Adj-SID can represent a bundle of links (L2 or L3). In theory, there is a bigger advantage for Node-SID, but only if we are sure that all nodes along the path can process the ELI/EL. Now from a practical point of view, we have no insurance.

Best Regards,

-----Original Message-----
From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Carlos Pignataro (cpignata)
Sent: Sunday, May 08, 2016 03:19
To: Stewart Bryant
Cc: mpls@ietf.org
Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label

Stewart, see inline. 

> On May 7, 2016, at 16:52, Stewart Bryant <stewart.bryant@gmail.com> wrote:
> 
> 
> 
>> On 07/05/2016 18:20, Carlos Pignataro (cpignata) wrote:
>> 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.
> Why would you put an ELI in the middle of a set of adj labels? Surely you want the packet to unconditionally go through those labels?
> 

Well, that was exactly my point...

What I tried to exemplify is that the algorithm does not differentiate between Node labels and Adj labels, and I am asking if it should...

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

> - Stewart
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.