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

[Xuxiaohu <[e-mail]>]

Hi Bruno,

Sorry for my late response. 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Thursday, September 24, 2015 9:04 PM
> To: Xuxiaohu
> Cc: ISIS-WG; [e-mail]
> Subject: RE: draft-ietf-isis-mpls-elc
> 
> Hi Xuxiaohu,
> 
> Please see inline. #Bruno2
> 
> [...]
> 
> > > > > From: [e-mail] >
> > > > > [mailto:[e-mail]]
> > > > > Sent: Tuesday, September 22, 2015 11:13 PM
> > > > >
> > > > > 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.
> >
> > Understood. Would you please provide any text for clarifying the
> > meaning of RLSDC?
> 
> #Bruno2
> I'd propose to define it in §4, following "The  Value field is set to the maximum
> readable label stack deepth in the range between 1 to 255."
> By adding: "Both ELI and EL labels needs to be within the RLSD in order for the
> load-balancing to use the Entropy Label."

That text looks good to me.

> Note: given this definition, the value "1" (may be even "2") looks possibly invalid.
> Indeed, if you support EL as egress, you're supposed to be able to receive a
> tunnel termination packet with label stack < ELI, EL, TL> <remaining  packet
> header> and forward it based on the TL label. Hence you need to read 3 labels.

IMHO, the RLD value of 1 or 2 should be valid for some particular LSRs. Of course, those LSRs could not support EL-based load-balancing. In other words, the RLD is an intrinsic property of any LSR regardless of its load-balancing capability.

> > > > 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.
> >
> > If I understood your point correctly, you wanted to make the ingress
> > to take into account the MPLS payload inspection-based load-balancing
> > capabilities of all other LSRs when inserting ELs into the label stack
> > of a given packet. If so, wouldn't it make the EL insertion algorithms
> > [I-D.ietf-mpls-spring-entropy- label] more complex?
> 
> #Bruno2
> I wanted ingress to be able to know the MPLS payload inspection-based
> load-balancing capabilities of all other LSRs.

> (Just like your draft advertises the MPLS EL based load-balancing capability).
> That way, the ingress has additional information that it may use (or not, this is
> fully optional).
> 
> That way, the ingress is able to know that downstream LSR are capable of
> loadbalancing:
> - based on the EL if EL is below RSLD labels
> - based on payload if payload is below RSLD2 labels
> 
> If RSLD2>= (RSLD-2) (e.g. if RSLD2=RSLD) then the ingress may push less labels
> by not sending the ELI, EL labels (given that the downstream are capable of Load
> Balancing without EL). As a consequence, it saves 2 labels which may be used for
> other purposes (service, explicit routing in the spring context...)

If the MPLS WG community could reach a consensus on the above change to the EL insertion algorithm as described in [I-D.ietf-mpls-spring-entropy- label], it makes sense to extend IGP to advertise the MPLS payload inspection-based load-balancing capability.

Best regards,
Xiaohu

> Thanks,
> Best regards,
> Bruno
> 
> >
> > Best regards,
> > Xiaohu
> >
> > > 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.
> 
> 
> _____________________________________________________________
> ____________________________________________________________
> 
> 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.