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

["Carlos Pignataro (cpignata)" <[e-mail]>]

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?

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?

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.

Thanks!

— Carlos.


> On May 4, 2016, at 9:19 AM, [e-mail] 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: [e-mail] <mailto:[e-mail]> [mailto:[e-mail] <mailto:[e-mail]>]
> Sent: Wednesday, May 04, 2016 14:45
> To: [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> Cc: [e-mail] <mailto:[e-mail]>; 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 ([e-mail] <mailto:[e-mail]>).
> > >
> > > 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: [e-mail] <mailto:[e-mail]>
> > > Senior MPLS Expert                          [e-mail] <mailto:[e-mail]>
> > > Huawei Technologies (consultant)     phone: [phone]
> > >
> > > _______________________________________________
> > > mpls mailing list
> > > [e-mail] <mailto:[e-mail]>
> > > https://www.ietf.org/mailman/listinfo/mpls <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
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls>