Re: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00

<> Thu, 05 June 2014 13:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4E6F11A0075 for <>; Thu, 5 Jun 2014 06:25:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id osAaVE8yeW2w for <>; Thu, 5 Jun 2014 06:25:17 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 998351A00C6 for <>; Thu, 5 Jun 2014 06:25:17 -0700 (PDT)
Received: from (unknown [xx.xx.xx.2]) by (ESMTP service) with ESMTP id CBC4832433D; Thu, 5 Jun 2014 15:25:09 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown []) by (ESMTP service) with ESMTP id A04C127C06F; Thu, 5 Jun 2014 15:25:09 +0200 (CEST)
Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([]) with mapi id 14.03.0181.006; Thu, 5 Jun 2014 15:25:09 +0200
From: <>
To: Robert Raszuk <>, Xuxiaohu <>
Thread-Topic: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00
Thread-Index: Ac9z2gorbAmJYe4UTpeoTQ6gc4g+PgIyyZiAAQDPlAAABhOUUA==
Date: Thu, 5 Jun 2014 13:25:08 +0000
Message-ID: <5527_1401974709_53906FB5_5527_3538_2_9E32478DFA9976438E7A22F69B08FF9201DD5C@OPEXCLILM34.corporate.adroot.infra.ftgroup>
References: <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2014.6.5.105118
Cc: "" <>, "" <>, "" <>
Subject: Re: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Jun 2014 13:25:20 -0000


I would tend to disagree with you.
With your model, loadbalancing becomes "stateful" so you need to create new forwarding states on your nodes to achieve the granularity you want and you will never be able to the same level of granularity that you have today with hop by hop hashing approach. I agree that hop by hop approach may also have some drawbacks like polarization.
IMHO, loadbalancing must be kept "stateless" as much as possible.

But nothing says that one model must kill the other (ingress lb vs hop by hop lb) and both may be used in the same network for different reason.


-----Original Message-----
From: Isis-wg [] On Behalf Of Robert Raszuk
Sent: Thursday, June 05, 2014 14:25
To: Xuxiaohu
Subject: Re: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00

Hi Xu,

Actually let me express an opinion that while for other MPLS signalling protocols the concept of entropy label as describe in RFC
6790 may be useful I would rather question if the same applies to segment routing architecture.

Fundamental difference here is that other MPLS signalling protocols bind labels to FECs. SR on the other hand binds SIDs (which one of the special case of can be label) to nodes or links. That means that number of such bindings will naturally be orders of magnitude less in the SR concept.

That means that perhaps one could really analyze if the tuple ELI + EL (one or many) is that much needed as opposed to advertise wider range of SIDs and simply use those in flat layer for loadbalancing reasons ?
Just mapping different flows on ingress to different label from said range.

Also that not only can accomplish egress node loadbalancing, but also all via nodes will have no problem with such input to a hash function regardless if they are SR capable or not ?

Maybe rather then copying all fixes of MPLS original architecture to SR its better to adjust SR architecture to at least not repeat the same mistakes we have already made in the past ?

Comments ?


On Sat, May 31, 2014 at 10:05 AM, Xuxiaohu <> wrote:
> Hi WG co-chairs,
> This draft ( describes how to advertise the MPLS Entropy Label Capability (ELC) using IS-IS in SPRING networks. Since ( has been adopted as a WG draft, as co-authors of draft-xu-isis-mpls-elc-00, we hope you could consider the WG adoption for this draft as well.
> Best regards,
> Xiaohu (on behalf of all-authors)
> _______________________________________________
> Isis-wg mailing list

Isis-wg mailing list


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.