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

[<[e-mail]>]

Hi Xuxiaohu,

Thanks for your answer.
Please see inline. #Bruno

> From: Xuxiaohu [mailto:[e-mail]] > Sent: Wednesday, September 23, 2015 4:18 AM
> 
> Hi Bruno,
> 
> Thanks a lot for your comments. Please see my response inline.
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: Tuesday, September 22, 2015 11:13 PM
> > To: [e-mail]
> > 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.

#Bruno: many LSR are capable of doing Load-Balancing (LB) based on the following IP packet. Hence the maximum number of readable labels could be understood as "before the IP header used for LB". In which case, one could "expect" that the ELI, EL labels are equally easy to hash than an IP header, hence the LEI, EL labels could be placed behind the RLSDC.

> 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 

#Bruno: Sorry but "it's expected" and "should" does not seem specific enough to me for a standard track document.
Given that the purpose of this document is specifically to handle load-balancing with the entropy label, I think it should be better to indicate that both ELI and EL labels needs to be within the RLSDC. I've seen interop issues with more specific text.
I'm just asking for a normative text clarifying the meaning of RLSDC. No change on implementation.

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

#Bruno: I think your draft would be a good home for this addition, but I can understand that this is a change and considered out of scope.

Thanks
-- Bruno

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


_________________________________________________________________________________________________________________________

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.