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

Robert Raszuk <robert@raszuk.net> Thu, 05 June 2014 13:43 UTC

Return-Path: <rraszuk@gmail.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 046781A00C6 for <isis-wg@ietfa.amsl.com>; Thu, 5 Jun 2014 06:43:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9nKE6GukKgd for <isis-wg@ietfa.amsl.com>; Thu, 5 Jun 2014 06:43:11 -0700 (PDT)
Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0A311A0115 for <isis-wg@ietf.org>; Thu, 5 Jun 2014 06:43:11 -0700 (PDT)
Received: by mail-ie0-f178.google.com with SMTP id rl12so889596iec.37 for <isis-wg@ietf.org>; Thu, 05 Jun 2014 06:43:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=97KTroq5Z8gXqpdbbLdmmW+DRImcHXRIWsCWIb90Vxk=; b=UNO4QeGblq0HmCa96sbgglBIhNjykws5XnsS0a5FLFmrxytinqq+UTEMI+GIPRTwyV JfyTLyBvYpMOcJeEYelCpkRSsI537AUIHjGfQFKtZJ6gBGhvnptP/riR9EOQMhwnCp4O orpwANfYlPuV5iJVamJruE2LP9qzVJOvehsNtzos076YQEl03rKTV3yyNRJgnfeCXJGX LF5n6yTVyKS8VfGAFKTu7btS7wUsGhkdcJkWvf2rtsvmrM/2Va925BYbzmc0v5vyX9qm Pq2UQXoExUxeoJ2UHjQeaBBC/VrKbUDEdj1dxFMzFoVJZJxh9WTytnyQIBsa75dAjf1b yDhg==
MIME-Version: 1.0
X-Received: by 10.50.62.40 with SMTP id v8mr20274326igr.21.1401975785186; Thu, 05 Jun 2014 06:43:05 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.64.242.198 with HTTP; Thu, 5 Jun 2014 06:43:05 -0700 (PDT)
In-Reply-To: <CECE764681BE964CBE1DFF78F3CDD3941E1D8412@xmb-aln-x01.cisco.com>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827D488@NKGEML512-MBS.china.huawei.com> <CA+b+ERmCusprkp3nYcwUtK4F0qmiv6-DogsEQ7vcJSgPRaHuPg@mail.gmail.com> <CECE764681BE964CBE1DFF78F3CDD3941E1D8412@xmb-aln-x01.cisco.com>
Date: Thu, 05 Jun 2014 15:43:05 +0200
X-Google-Sender-Auth: qMKp2e4ZEPiOc686vi3hMRLt7OU
Message-ID: <CA+b+ERndrSVcWmWWhHBOP==oub+V0gcMeLZ9X1dyKd9AfYHvXg@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
To: "Nobo Akiya (nobo)" <nobo@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/JsNeKlMaMjq5nCGOKS8BBo_gNSE
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 13:43:13 -0000

Hi Nobo,

Well the range size would be as big as most ECMP paths you have. Say
32 or 64 as example.

As to the forwarding table size in the core it is rather
implementation dependent .. you really do not need to do exact match
for all labels in a range (unlike with atomic 20 bit wide MPLS label)
it is still much less then you have entries on the ingress and egress
.. as those are in millions.

Cheers,
R.


On Thu, Jun 5, 2014 at 3:15 PM, Nobo Akiya (nobo) <nobo@cisco.com> wrote:
> Hi Robert, Xu,
>
>> 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.
>
> That's an interesting idea, but I'd like to highlight one down side. "wider range of SIDs" will likely have to be fairly large/wide to have good probability of good ECMP distribution throughout the network, and that will likely result in a significant increase in forwarding table in every network nodes. Obvious side effects include increased SRGB, increased memory usage, debugging difficulty, increased number in in-band-OAM to test all forwarding entries.
>
> Considering above, perhaps fitting in EL to MPLS based SR is still a reasonable option to discuss. It's not a trivial topic, but I think this is an important topic that has lacked attention.
>
> Xu, I think draft-xu-isis-mpls-elc should have a reference to draft-kini-mpls-spring-entropy-label. And I agree with Stephane, there's minimal benefit in progressing draft-xu-isis-mpls-elc before draft-kini-mpls-spring-entropy-label.
>
> Thanks.
>
> -Nobo
>
>> -----Original Message-----
>> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Robert Raszuk
>> Sent: Thursday, June 05, 2014 8:25 AM
>> 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