Re: [Isis-wg] draft-ietf-isis-mpls-elc

Bruno,

I have published idr draft where BGP-LS is used to signal MSD (Max SID Depth - same terminology as in PCEP SR draft which defines MSD)of an ingress node, will publish IGP drafts in a week

Regards,
Jeff

> On Sep 22, 2015, at 7:18 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
> 
> Hi Bruno,
> 
> Thanks a lot for your comments. Please see my response inline.
> 
>> -----Original Message-----
>> From: bruno.decraene@orange.com [mailto:bruno.decraene@orange.com]
>> Sent: Tuesday, September 22, 2015 11:13 PM
>> To: draft-ietf-mpls-spring-entropy-label@tools.ietf.org
>> Cc: ISIS-WG
>> Subject: draft-ietf-isis-mpls-elc
>> 
>> Hi authors, all,
>> 
>> 1) I wish the draft gave a precise definition of the RLSDC (Readable Label Stack
>> Deepth Capability). (1) It's not clear to me whether RLSDC is the number of
>> labels before the ELI label, or the position of the ELI label in the stack, or the
>> position of the EL label in the stack.
> 
> It said in the Introduction section that
> 
>  " ...it would be useful for ingress LSRs to know each LSR's capability of
>   reading the maximum label stack deepth.  This capability, referred to
>   as Readable Label Stack Deepth Capability (RLSDC) can be used by
>   ingress LSRs to determine whether it's necessary to insert an EL for
>   a given LSP tunnel in the case where there has already been at least
>   one EL in the label stack [I-D.ietf-mpls-spring-entropy-label]..."
> 
> The RLSDC is used to indicate how many labels the advertising router could read (from top to bottom) at most on the label stack of a received MPLS packet. It's one of the basic data-plane parameters for LSRs. As for how to apply this parameter to the EL usage, it's expected that the EL should occur within the RLD of all LSRs if possible and therefore multiple ELI/EL pairs may be inserted to the label stack of a given MPLS packet. For more details, please refer to [I-D.ietf-mpls-spring-entropy-label].
> 
>> 2) Also, if the ingress node has limitations in term of the number of labels that it
>> can push (e.g. in the context of SPRING), it could potentially be useful to
>> advertise whether the (EL, ELI) labels may be omitted. i.e. advertising the
>> Readable Label Stack Depth before the IP header can be read for load-balancing
>> purpose. Unfortunately the latter may be dependent on the type of
>> protocol/header following the last MPLS label (e.g. IPv4, IPv6, control word...)
>> but it may be good to have a discussion on this.
> 
> I agree it may be good to have a discussion on this in related WGs. However, since this draft is focused only on how to apply the EL concept to MPLS-SPRING networks, I wonder whether it's proper to include such discussion in this draft.
> 
>> Thanks,
>> Regards,
>> Bruno
>> 
>> (1) Alternatively, the definition could be provided in
>> draft-ietf-mpls-spring-entropy-label, but this draft is informational. Also it uses a
>> slightly different term: RLD (Readable Label Depth)
> 
> RLSD and RLD mean the same thing. "RLSD" would be replaced by "RLD" in the next version of draft-ietf-isis|ospf-mpls-elc.
> 
> Best regards,
> Xiaohu
> 
>> 
>> _____________________________________________________________
>> ____________________________________________________________
>> 
>> 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.
> 
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg