Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label

[Sri <[e-mail]>]

Hi Bruno,

See inline.

On Fri, May 6, 2016 at 2:34 AM, <[e-mail]> wrote:

> Hi Sri,
>
>
>
> Thanks for the follow up.
>
> As previously asked, is RLD specific to the use of the entropy label or
> not? Let’s remember that multipath load balancing existed before EL, and
> that transit LSR not compliant with EL can still benefit from the presence
> of the EL label.
>
> If RLD is not specific to EL, I’m not certain that adding the reference to
> RFC6790 is the best way to clarify.
>

Sri> RLD is not specific to EL. RFC6790 Section 1 gives a very good
explanation of how load-balancing is done (even before it gets to EL) and
such text is not present in other RFCs. But I can understand how this
reference can be interpreted as EL specific. So I am fine with not using
that reference as I suggested.


> In all cases, this point should be stated in the document defining RLD.
> (which may be this one, of maybe the IGP extensions if draft-ietf-mpls-spring-entropy-label
> gets informational).
>
>
>
> > I have not used your suggested sentence "...both the ELI and EL MUST
> be.." since the ELI is placed above the EL and if the LSR can read the EL,
> it can obviously have read the ELI.
>
> Agreed. Yet mentioning both labels helps the reader to remember that the
> limit for the number of “useful” labels is RLD-2. (I mean useful for
> steering the packet, I’m not implying that EL is not useful). This may be
> obvious for people coming from the EL space, but less for people coming
> from the spring space, especially since the text often refers to a/the
> (i.e. one) EL label. But this points could indeed be stated elsewhere.
>
>
Sri> I see your point. I will include that.


>
>
> Thanks,
>
> -- Bruno
>
>
>
> *From:* Sri [mailto:[e-mail]]
> *Sent:* Wednesday, May 04, 2016 7:08 PM
>
> *To:* DECRAENE Bruno IMT/OLN
> *Cc:* LITKOWSKI Stephane OBS/OINIS;
> [e-mail]; [e-mail];
> [e-mail]
> *Subject:* Re: [mpls] working group last call on
> draft-ietf-mpls-spring-entropy-label
>
>
>
> Hi Bruno,
>
>
>
> Thanks for the clarification. On my first read of your last sentence under
> NEW it had seemed to me that it is placing a restriction on the ingress. On
> reading your clarification I understand that it is not your intent. So I
> accept the comment for the NEW definition but suggest that that we refer to
> RFC6790 rather than re-stating that EL is used for load-balancing. So how
> about this for sec 4 para2 (changes highlighted) -
>
>
>
>    An LSR may have a limitation on the depth of the label stack that it can read and process
>
>     in order to do multipath load balancing as described in [RFC6790].  This limitation
>
>    expressed in terms of the number of label stack entries that the LSR
>
>    can read is defined as the Readable Label Depth (RLD)
>
>    capability of that LSR.  If an EL does not occur within the RLD of an
>
>    LSR in the label stack of the MPLS packet that it receives, then it
>
>    would lead to poor load balancing at that LSR.  The RLD of an LSR is
>
>    a characteristic of the forwarding plane of that LSR's implementation
>
>    and determining it is outside the scope of this document.
>
>
>
> I have not used your suggested sentence "...both the ELI and EL MUST be.."
> since the ELI is placed above the EL and if the LSR can read the EL, it can
> obviously have read the ELI.
>
>
>
> Thanks
>
> Sri
>
>
>
> On Wed, May 4, 2016 at 7:09 AM, <[e-mail]> wrote:
>
> Hi Sri,
>
>
>
> > The definition of RLD must not specify conditions on when an EL must be
> used. RLD is a per LSR characteristic. Any recommendations on placing the
> EL must be specified outside of the definition.
>
>
>
> IMO, the goal of RLD is specifically to say that the EL needs to be within
> the RLD in order for the EL to be used for load-balancing. Otherwise, can
> you clarify the goal of signaling this RLD?
>
>
>
> (That’s a different point compared to specifying the position of the EL in
> the stack, which is a freedom of the ingress. (although a secondary goal of
> this goal seems to be to reduce this freedom))
>
>
>
> -- Bruno
>
>
>
> *From:* Sri [mailto:[e-mail]]
> *Sent:* Wednesday, May 04, 2016 3:56 PM
> *To:* DECRAENE Bruno IMT/OLN
> *Cc:* LITKOWSKI Stephane OBS/OINIS;
> [e-mail]; [e-mail];
> [e-mail]
> *Subject:* Re: [mpls] working group last call on
> draft-ietf-mpls-spring-entropy-label
>
>
>
> Hi Bruno,
>
>
>
> On Wed, May 4, 2016 at 6:45 AM, <[e-mail]> wrote:
>
> Hi Stéphane,
>
>
>
> Thanks for the quote. I had read that sentence, and I think it could be
> made more precise.
>
> e.g.
>
> OLD: This limitation expressed in terms of the number of label stack
> entries that the LSR  can read is henceforth referred to as the Readable
> Label Depth (RLD)  capability of that LSR.
>
> NEW: This limitation expressed in terms of the number of label stack
> entries that the LSR  can read. This document defines the Readable Label
> Depth (RLD) as the number of labels that a transit LSR can read for
> load-balancing purpose.  When EL is used, both ELI and EL MUST be within
> the RLD, in order for the EL to be used during load-balancing.
>
>
> The definition of RLD must not specify conditions on when an EL must be
> used. RLD is a per LSR characteristic. Any recommendations on placing the
> EL must be specified outside of the definition.
>
>
>
>
>
> Sri
>
> _________________________________________________________________________________________________________________________
>
>
>
> 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.
>
>