Re: [mpls] Poll 2: New SPL vs re-purposed ELI for carrying Network Action Indicators

[[e-mail]]

Hello Adrian,

Thank you for taking the time to answer and clarify. 
Please see inline [Bruno]
 
> From: Adrian Farrel <[e-mail]> 
> Sent: Thursday, June 9, 2022 11:09 AM
> 
> Hello Bruno,
> 
> > Clarification questions.
> 
> You are welcome.
[Bruno] Thank you.

> 
> >>> (2) re-purposing the ELI SPL?
> >> 
> >> No way! 😊
> >> 
> >> Bruno and Zafar cast this as "extending" the ELI. In other words, in their view, this
> >> approach is backwards compatible with existing ELI deployments. This may be
> >> technically possible,
> >
> > Would it be fair to say that you don't see technical objections to raise on this approach?
> 
> Hmmm, I don't think I have looked at it in sufficient detail to say that.

[Bruno] OK, sure. I meant to say "as of today, you don't see obvious technical objections to raise on this approach".
I did not meant to ask you for a definite answer requiring a thorough analysis work. 

> I mean, if I don't look before I step off the sidewalk, I can honestly say that I don't see any trucks coming down the street. So that > is probably not the right question to be asking.
[Bruno] I don't think that the analogy is that good. Not looking before stepping off the sidewalk mostly means that you have no/very little information. While on MPLS standards, you do have a large and deep knowledge. (I'm trying to phrase it to not offend your modesty, nor to bind you to saying "it works"; all that with little ability to express such subtility in English. So if it's badly formulated, I rely on your Forward  Error Correction capability )
 
> I reiterate, that it is technically possible to use the ELI for indicating all of the Network Actions. But it is technically possible to > do a lot of things - 
[Bruno] Thank you for the clarification.


> 
> >> but I still don't like it because I don't think it is a clean separation of functions.
> >
> > Can you clarify what you mean by "clean separation of functions"?
> > (because a naïve interpretation would be that you don't want to mix
> > entropy/load balancing with Network Actions)
>  
> Well, the naïf view might be missing something.
[Bruno] The naïf is there to allow for the knowledgeable to share their knowledge and clarify the details 😉. I see this as useful 

 
> It's true that the entropy label is a sort of Network Action. It is one that is optional to action at any hop, and that does not have to > be actioned specifically when the ELI appears in the stack. And the ancillary data is encoded in-stack in the EL.
> 
> My concern is the flip of what you suggest. I don't like the idea of "overloading" (you say "extending") entropy/load balancing with the > full set of Network Actions. When I see an ELI, I want to know that it is an ELI not an NAI.
[Bruno] In my view, the definition of a Entropy Label Control field as per [1] is not overloading anything but extending bits/fields whose current semantics are defined the way reserved field are (IOW those fields are not used and extendable)
[1] https://datatracker.ietf.org/doc/html/draft-decraene-mpls-slid-encoded-entropy-label-id-03#section-2

When seeing the ELI, you would know whether it has NAI or not.


Thank you,
Best regards,
--Bruno
> 
> Curiously, I am happy with the converse which is that (eventually, and if people want to go that way) we retire the ELI and move entropy > to be "just another" Network Action. But, introducing the NAI does not mandate deprecating the ELI.
> 
> >> Conversely, some people see this as reclaiming the ELI for a new purpose.
> >> If the ELI is to be "reclaimed" then we need to go through a careful round of surveying
> >> implementations and a "cool-off" period during > which the label is marked as deprecated.
> >> If we think we don't need the ELI, we should start this now, but it is a separate action.
> 
> Cheers,
> Adrian
>

Orange Restricted

_________________________________________________________________________________________________________________________

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.