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

<bruno.decraene@orange.com> Wed, 04 May 2016 13:45 UTC

Return-Path: <bruno.decraene@orange.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0058C12D1CC; Wed, 4 May 2016 06:45:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.608
X-Spam-Level:
X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGZxNXqRAd-c; Wed, 4 May 2016 06:45:20 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F4F712D0F4; Wed, 4 May 2016 06:45:19 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 0E9B43B4EBF; Wed, 4 May 2016 15:45:18 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.31]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id D63A44C048; Wed, 4 May 2016 15:45:14 +0200 (CEST)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0294.000; Wed, 4 May 2016 15:45:10 +0200
From: bruno.decraene@orange.com
To: LITKOWSKI Stephane OBS/OINIS <stephane.litkowski@orange.com>, "draft-ietf-mpls-spring-entropy-label@tools.ietf.org" <draft-ietf-mpls-spring-entropy-label@tools.ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label
Thread-Index: AQHRpgLPLvEkwF22aU2JkdPYBO7ORZ+owhSAgAABXpA=
Date: Wed, 04 May 2016 13:45:09 +0000
Message-ID: <28277_1462369514_5729FCEA_28277_10459_1_978925b5-4e17-4253-ac27-564e15e3bd5a@OPEXCLILM22.corporate.adroot.infra.ftgroup>
References: <571B29F8.1060301@pi.nu> <6755_1462365901_5729EECD_6755_4861_1_53C29892C857584299CBF5D05346208A0F8956EC@OPEXCLILM21.corporate.adroot.infra.ftgroup> <9E32478DFA9976438E7A22F69B08FF921BB4735A@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
In-Reply-To: <9E32478DFA9976438E7A22F69B08FF921BB4735A@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: multipart/alternative; boundary="_000_978925b54e174253ac27564e15e3bd5aOPEXCLILM22corporateadr_"
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.5.4.132417
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/qszvoGPAbsGPdgv57WFVTL2EPqU>
Cc: "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>
Subject: Re: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 May 2016 13:45:23 -0000

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.



Additionally, you did not answer my second related question:

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



A related point is whether a transit LSR not supporting EL, MAY/SHOULD/MUST NOT advertise the RLD.  (because transit LSR don't need to support EL to benefit from the improved load-balancing  provided by EL)



The question could further be refined when MPLS carry an IP packet and the LSR perform load-balancing based on some hashing of this inner IP packet.



Thanks,

--Bruno

From: LITKOWSKI Stephane OBS/OINIS
Sent: Wednesday, May 04, 2016 3:20 PM
To: DECRAENE Bruno IMT/OLN; draft-ietf-mpls-spring-entropy-label@tools.ietf.org; mpls@ietf.org
Cc: mpls-chairs@ietf.org; Loa Andersson
Subject: RE: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label


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.