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

Robert Raszuk <> Thu, 05 June 2014 13:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E480B1A0090 for <>; Thu, 5 Jun 2014 06:45:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CTMUB3V_cFH5 for <>; Thu, 5 Jun 2014 06:45:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 668801A007C for <>; Thu, 5 Jun 2014 06:45:39 -0700 (PDT)
Received: by with SMTP id h3so7548115igd.13 for <>; Thu, 05 Jun 2014 06:45:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=n6h3OmkgG46THDUyyIHGES+HCyGnMahtSncf1oA/XYU=; b=xEax03aTwrJNSCOM20np/gSAwfVOn1XvlIgPahr6Hsd1ImHlHOBYSXvdMgC1oFOoPA qbuAs1FLmZB+H630rzgDYS2hOvND3Ssk3tZeh7AnvkTgC0x5Vps1EurUZ4uPUEYHD6tb xxfIE7VXMXloSXY897yAfwIXnJatXyWjVCHvjJl+TtBXjADtVg652rtZ9hoZksK7DfTJ +QZ+Z/JEaTgSwofcbnov0V3DhHXjkHVXlAn5nJ5IK/ujxD+oVT99SqadMMXsT2yy0/q6 RmjJ9awT3y0uRzChUyoEufGoxkxmc5+8zCqs5KRqq/dGTu7Gr3LFKIuXup9vvOFRPoE+ FhcA==
MIME-Version: 1.0
X-Received: by with SMTP id eh4mr20523143igb.9.1401975932901; Thu, 05 Jun 2014 06:45:32 -0700 (PDT)
Received: by with HTTP; Thu, 5 Jun 2014 06:45:32 -0700 (PDT)
In-Reply-To: <5527_1401974709_53906FB5_5527_3538_2_9E32478DFA9976438E7A22F69B08FF9201DD5C@OPEXCLILM34.corporate.adroot.infra.ftgroup>
References: <> <> <5527_1401974709_53906FB5_5527_3538_2_9E32478DFA9976438E7A22F69B08FF9201DD5C@OPEXCLILM34.corporate.adroot.infra.ftgroup>
Date: Thu, 5 Jun 2014 15:45:32 +0200
X-Google-Sender-Auth: lhQtmxKHmjaWoQsY-4N4vjqkUtI
Message-ID: <>
From: Robert Raszuk <>
To: "<>" <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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:45:41 -0000

I really do not see anything stateful in the network with the model described.


On Thu, Jun 5, 2014 at 3:25 PM,  <> wrote:
> Robert,
> 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.
> Stephane
> -----Original Message-----
> From: Isis-wg [] On Behalf Of Robert Raszuk
> Sent: Thursday, June 05, 2014 14:25
> To: Xuxiaohu
> Cc:;;
> 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 ?
> Cheers,
> R.
> 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.
> _______________________________________________
> Isis-wg mailing list