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

[<[e-mail]>]

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

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.


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

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.