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

<stephane.litkowski@orange.com> Thu, 05 June 2014 14:02 UTC

Return-Path: <stephane.litkowski@orange.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE731A018B for <isis-wg@ietfa.amsl.com>; Thu, 5 Jun 2014 07:02:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sICv414O-WZ1 for <isis-wg@ietfa.amsl.com>; Thu, 5 Jun 2014 07:02:47 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 531901A018C for <isis-wg@ietf.org>; Thu, 5 Jun 2014 07:02:45 -0700 (PDT)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id D697B18C150; Thu, 5 Jun 2014 16:02:37 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id E26F635C06D; Thu, 5 Jun 2014 16:02:36 +0200 (CEST)
Received: from OPEXCLILM34.corporate.adroot.infra.ftgroup ([169.254.4.19]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0181.006; Thu, 5 Jun 2014 16:02:36 +0200
From: <stephane.litkowski@orange.com>
To: Robert Raszuk <robert@raszuk.net>
Thread-Topic: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00
Thread-Index: AQHPgMRrbAmJYe4UTpeoTQ6gc4g+PptiiZRA
Date: Thu, 5 Jun 2014 14:02:35 +0000
Message-ID: <29719_1401976957_5390787C_29719_1584_3_9E32478DFA9976438E7A22F69B08FF9201DDCC@OPEXCLILM34.corporate.adroot.infra.ftgroup>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827D488@NKGEML512-MBS.china.huawei.com> <CA+b+ERmCusprkp3nYcwUtK4F0qmiv6-DogsEQ7vcJSgPRaHuPg@mail.gmail.com> <5527_1401974709_53906FB5_5527_3538_2_9E32478DFA9976438E7A22F69B08FF9201DD5C@OPEXCLILM34.corporate.adroot.infra.ftgroup> <CA+b+ERkSxrAdcp6eQOqGpP4Ai58fTxiJeP4xG9Qn+EsgdJhzBQ@mail.gmail.com>
In-Reply-To: <CA+b+ERkSxrAdcp6eQOqGpP4Ai58fTxiJeP4xG9Qn+EsgdJhzBQ@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.3]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.6.4.92121
Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/IKmWPgntB8rTciQvbbvPjp3Y984
Cc: "draft-xu-isis-mpls-elc@tools.ietf.org" <draft-xu-isis-mpls-elc@tools.ietf.org>, "isis-chairs@tools.ietf.org" <isis-chairs@tools.ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Subject: Re: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jun 2014 14:02:51 -0000

As far as I understand your proposal, you need to create forwarding entries "per flow" in all nodes, that's creating more states ...
Moreover, SIDs are bound to links and prefixes (not really node), so for Prefix SID, it's quite similar to a FEC , except that you can bind multiple SIDs to the same prefix. But each Prefix SID you are adding, adds a new forwarding state in the whole IGP domain.


-----Original Message-----
From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Raszuk
Sent: Thursday, June 05, 2014 15:46
To: LITKOWSKI Stephane SCE/IBNF
Cc: Xuxiaohu; isis-chairs@tools.ietf.org; draft-xu-isis-mpls-elc@tools.ietf.org; isis-wg@ietf.org
Subject: Re: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00

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

Cheers,
R.

On Thu, Jun 5, 2014 at 3:25 PM,  <stephane.litkowski@orange.com> 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 [mailto:isis-wg-bounces@ietf.org] On Behalf Of Robert 
> Raszuk
> Sent: Thursday, June 05, 2014 14:25
> To: Xuxiaohu
> Cc: isis-chairs@tools.ietf.org; draft-xu-isis-mpls-elc@tools.ietf.org; 
> isis-wg@ietf.org
> 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 <xuxiaohu@huawei.com> wrote:
>> Hi WG co-chairs,
>>
>> This draft (http://tools.ietf.org/html/draft-xu-isis-mpls-elc-00) describes how to advertise the MPLS Entropy Label Capability (ELC) using IS-IS in SPRING networks. Since (http://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-00) 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@ietf.org
>> https://www.ietf.org/mailman/listinfo/isis-wg
>
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg
>
> ______________________________________________________________________
> ___________________________________________________
>
> 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
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg

_________________________________________________________________________________________________________________________

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.