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

[<[e-mail]>]

Hi Xuxiaohu,

Thanks for your answer.
Please see inline.  #Bruno3

> From: Xuxiaohu [mailto:[e-mail]] > Sent: Tuesday, September 29, 2015 8:33 AM
> 
> 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.

#Bruno3 ok, thanks

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

#Bruno3 ok
 
> > > > > 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],

#Bruno3  I'm not sure that we need to change the above draft:
- mpls draft is mostly discussing how to insert the EL labels (in the spring context). Here my proposition is about not inserting it. So it could be seen as independent of this mpls draft
- mpls draft is informational only. Here the proposition is to advertise some additional information. Ingress _doesn't have_ to use it.

But discussion within the MPLS WG would indeed be good.

> it makes sense to extend IGP to advertise the MPLS payload inspection-based
> load-balancing capability.

#Bruno3 ok, thanks
 
Best regards,
Bruno

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


_________________________________________________________________________________________________________________________

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.