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

Hi Carlos,

Sorry I missed to answer this comment …

Please find some inline comments.

From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]
Sent: Saturday, May 07, 2016 18:58
To: LITKOWSKI Stephane OBS/OINIS
Cc: DECRAENE Bruno IMT/OLN; draft-ietf-mpls-spring-entropy-label@tools.ietf.org; mpls@ietf.org; mpls-chairs@ietf.org
Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label

Hi Stephane,

I had seen this definition, and had this follow-on thought:

The RLD is defined as a node attribute (per-LSR), as the min-LSRs of all line-cards. So for a network, you have RLDi (with i a node index). However, draft-ietf-mpls-spring-entropy-label is treating RLD as a single value. That seems like something that should be deeply considered. Which RLDi is used in the pseudocode?
[SLI] Agree, we already discussed this offline and pseudocode should be enhanced to be more clear on that point.

If there’s no RLD advertised for a node, what’s assumed? Three, zero, other?

Are there FRR considerations for the calculation, since a node repair can add labels, etc?
[SLI] FRR is not taken into account. As FRR is usually a new push (except for TE DETOUR afaik), an implementation may decide to push additional EL for FRR independently. But IMO, as we can see with implementations, ECMP is not well addressed for FRR yet. Only usage of LAGs will use loadbalancing during FRR.

Also, as Bruno also pointed out, the RLD is a generic attribute beyond EL/ELI, correct? In that case, how can a node advertise that it can read deep labels to RLD, but it does not support ELC? Take a FAT-PW case for example.
[SLI] For ISIS , you have two different subTLVs. You should be able to advertise one and not the other. I agree that it’s not clearly expressed in the isis draft.

Thanks!

— Carlos.

On May 4, 2016, at 9:19 AM, stephane.litkowski@orange.com<mailto:stephane.litkowski@orange.com> wrote:

Hi,

I think RLD is clearly expressed in :
"An LSR may have a limitation in its ability to read and process the
   label stack in order to do multipath load balancing.  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.  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."

It refers to the number of label that the LSR can read. So as a consequence, if you want to be able to read the EL, ELI+EL must be within the RLD. Otherwise the also described behavior will apply (poor loadbalancing).

Is it fine ?

Thanks

-----Original Message-----
From: bruno.decraene@orange.com<mailto:bruno.decraene@orange.com> [mailto:bruno.decraene@orange.com]
Sent: Wednesday, May 04, 2016 14:45
To: draft-ietf-mpls-spring-entropy-label@tools.ietf.org<mailto:draft-ietf-mpls-spring-entropy-label@tools.ietf.org>; mpls@ietf.org<mailto:mpls@ietf.org>
Cc: mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>; Loa Andersson
Subject: RE: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label

Hi authors,

As an additional comment, I'd like a see a more normative definition of "RLD" as this is an important point for the interop.
In particular, the grey zone is whether RLD is before the ELI, or include the EL, or include both the EL and ELI. Also, is RLD only applicable when EL is used or is it also applicable when load-balancing is performed based on the hashing of a stack of labels (a stack of RLD labels)?

>From the description of the text, I think I read that both EL and ELI needs to be within the RLD. But on the other hand, there has been a discussion on the mailing list about RLD=1, which would not even allow reading the ELI label.

Thanks,
Regards,
Bruno

> From: DECRAENE Bruno IMT/OLN > Sent: Monday, May 02, 2016 2:59 PM
>
> Hi authors,
>
> Please find below some comments on the document (§4).
>
> - I would expect that network operator may need some flexibility to
> influence the placement of the EL(s) based on the set of constraints.
> - The need for load-balancing seems significantly dependent on the 1)
> relative size of the flow (which is typically egress dependent) and 2)
> the presence of ECMP paths (IOW, I may not care if node N does not see
> the EL, if node N has a single link/path toward the egress). This may
> lead to additional requirements (e.g. advertising L2 ECMP which may
> not be currently visible to the L3 ingress. For spring, eventually
> draft-ietf-isis- l2bundles may already do the job)
>
> Both points are not touched in the draft, and I think these additions
> would improve the benefit of the draft.
>
> Thanks,
> Regards,
> -- Bruno
>
> > Working Group,
> >
> > This is to initiate a two week working group last call on
> > draft-ietf-mpls-
> spring-
> > entropy-label.
> >
> > Please send your comments to the mpls wg mailing list (mpls@ietf.org<mailto:mpls@ietf.org>).
> >
> > There are no IPR disclosures against this document.
> >
> > All the authors and contributors (with one exception) have stated on
> > the working group mailing list that they are not aware of any other
> > IPRs that relates to this draft.
> >
> > This working group last call ends May 12, 2016.
> >
> >
> > /Loa
> > for the MPLS wg chairs
> > --
> >
> >
> > Loa Andersson                        email: loa@mail01.huawei.com<mailto:loa@mail01.huawei.com>
> > Senior MPLS Expert                          loa@pi.nu<mailto:loa@pi.nu>
> > Huawei Technologies (consultant)     phone: +46 739 81 21 64
> >
> > _______________________________________________
> > mpls mailing list
> > mpls@ietf.org<mailto:mpls@ietf.org>
> > https://www.ietf.org/mailman/listinfo/mpls

_________________________________________________________________________________________________________________________

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.
_______________________________________________
mpls mailing list
mpls@ietf.org<mailto:mpls@ietf.org>
https://www.ietf.org/mailman/listinfo/mpls

_________________________________________________________________________________________________________________________

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.