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

<bruno.decraene@orange.com> Wed, 04 May 2016 12:50 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 7B76212B046; Wed, 4 May 2016 05:50:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.915
X-Spam-Level:
X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=unavailable 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 f6wGjkjfifDJ; Wed, 4 May 2016 05:50:29 -0700 (PDT)
Received: from relais-inet.orange.com (relais-nor36.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CDBE12D69C; Wed, 4 May 2016 05:45:03 -0700 (PDT)
Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id F30E0C096B; Wed, 4 May 2016 14:45:01 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.57]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id BBD791A005D; Wed, 4 May 2016 14:45:01 +0200 (CEST)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0294.000; Wed, 4 May 2016 14:45:01 +0200
From: bruno.decraene@orange.com
To: "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: AQHRnTVMcteLha4FPUqiNKIUGrWdS5+lpwIwgAMhh0A=
Date: Wed, 04 May 2016 12:45:01 +0000
Message-ID: <6755_1462365901_5729EECD_6755_4861_1_53C29892C857584299CBF5D05346208A0F8956EC@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <571B29F8.1060301@pi.nu>
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: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/-IAY031KtO2aPgzHROgYjdxHe0g>
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 12:50:30 -0000

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).
> >
> > 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
> > Senior MPLS Expert                          loa@pi.nu
> > Huawei Technologies (consultant)     phone: +46 739 81 21 64
> >
> > _______________________________________________
> > mpls mailing list
> > 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.