Re: [Lsr] Working Group Last Call for "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using ISIS" - draft-ietf-isis-mpls-elc-07

[Peter Psenak <[e-mail]>]

Hi Bruno,

On 02/09/2019 11:59, [e-mail] wrote:
> Support.
> 
> This is needed for using MPLS Entropy Label in SR-MPLS.
> 
> Please find below some proposed comments. Please feel free to silently 
> discard.
> 
> §1 Introduction
> 
> OLD:
> 
> “This capability, referred to as Entropy
> 
> Readable Label Depth (ERLD) as defined in
> 
> [I-D.ietf-mpls-spring-entropy-label  <https://tools.ietf.org/html/draft-ietf-isis-mpls-elc-07#ref-I-D.ietf-mpls-spring-entropy-label>] may be used by ingress LSRs to
> 
> determine whether it's necessary to insert an EL for a given LSP in
> 
> the case where there has already been at least one EL in the label
> 
> stack [I-D.ietf-mpls-spring-entropy-label  <https://tools.ietf.org/html/draft-ietf-isis-mpls-elc-07#ref-I-D.ietf-mpls-spring-entropy-label>].”
> 
> NEW:
> 
> This capability, referred to as Entropy
> 
> Readable Label Depth (ERLD) as defined in
> 
> [I-D.ietf-mpls-spring-entropy-label  <https://tools.ietf.org/html/draft-ietf-isis-mpls-elc-07#ref-I-D.ietf-mpls-spring-entropy-label>] may be used by ingress LSRs to
> 
> determine the position of the EL label in the stack, and whether it's 
> necessary to insert multiple EL at different depth.

What about the slightly modified wording:

"This capability, referred to as Entropy Readable Label Depth (ERLD) as
defined in <xref target="I-D.ietf-mpls-spring-entropy-label"/> may be
used by ingress LSRs determine the position of the EL in the stack, and 
whether it's necessary to insert multiple ELs at different position in 
the label stack."

> 
> §7Security Considerations
> 
> “This document does not introduce any new security risks.”
> 
> Incorrectly setting the E flag (ELC capable) (during origination, 
> propagation, redistribution) may lead to black-holing the traffic on the 
> egress node. I believe this risk should be mentioned.

done.

thanks,
Peter
> 
> Regards,
> 
> --Bruno
> 
> *From**:*Lsr [mailto:[e-mail]] *On Behalf Of * Les Ginsberg 
> (ginsberg)
> *Sent:* Monday, September 2, 2019 6:48 AM
> *To:* Acee Lindem (acee); [e-mail]
> *Cc:* [e-mail]; [e-mail]; [e-mail]
> *Subject:* Re: [Lsr] Working Group Last Call for "Signaling Entropy 
> Label Capability and Entropy Readable Label-stack Depth Using ISIS" - 
> draft-ietf-isis-mpls-elc-07
> 
> I support moving forward with these drafts.
> 
> There are clearly use cases for this functionality and the solution has 
> been vetted with providers who intend to deploy this.
> 
>     Les
> 
> *From:*Lsr <[e-mail]> *On Behalf Of *Acee Lindem (acee)
> *Sent:* Friday, August 30, 2019 12:44 PM
> *To:* [e-mail]
> *Cc:* [e-mail]; [e-mail]; [e-mail]
> *Subject:* [Lsr] Working Group Last Call for "Signaling Entropy Label 
> Capability and Entropy Readable Label-stack Depth Using ISIS" - 
> draft-ietf-isis-mpls-elc-07
> 
> We’ve gone through a number of iterations with these ELC drafts and I 
> believe they are ready and meets all the use case requirements. Note 
> that “Entropy Label for Spring tunnels” – 
> draft-ietf-mpls-spring-entropy-label-12 is on the RFC editor’s queue.
> 
> This begins a two week last call for the subject draft. Please indicate 
> your support or objection on this list prior to 12:00 AM UTC on Sept 
> 14^th , 2014. Also, review comments are certainly welcome.
> 
> Thanks,
> Acee
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
>