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

Xuxiaohu <xuxiaohu@huawei.com> Fri, 06 June 2014 09:02 UTC

Return-Path: <xuxiaohu@huawei.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 751111A00F0 for <isis-wg@ietfa.amsl.com>; Fri, 6 Jun 2014 02:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level:
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-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 CJMqx5c1g-bs for <isis-wg@ietfa.amsl.com>; Fri, 6 Jun 2014 02:02:03 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB6A41A00A9 for <isis-wg@ietf.org>; Fri, 6 Jun 2014 02:02:02 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEX89400; Fri, 06 Jun 2014 09:01:54 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Jun 2014 10:00:59 +0100
Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Jun 2014 10:01:52 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.62]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Fri, 6 Jun 2014 17:01:47 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: Robert Raszuk <robert@raszuk.net>
Thread-Topic: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00
Thread-Index: Ac9z2gorbAmJYe4UTpeoTQ6gc4g+PgIyyZiAAPQ87gAALrz7cP//zhwA//9vIHA=
Date: Fri, 6 Jun 2014 09:01:47 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827EC79@NKGEML512-MBS.china.huawei.com>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827D488@NKGEML512-MBS.china.huawei.com> <CA+b+ERmCusprkp3nYcwUtK4F0qmiv6-DogsEQ7vcJSgPRaHuPg@mail.gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827EBC7@NKGEML512-MBS.china.huawei.com> <CA+b+ERk8cG3kuzg8POg3Kx6Xdb3GG-s9aKb+1FnstdKWvi6+Vg@mail.gmail.com>
In-Reply-To: <CA+b+ERk8cG3kuzg8POg3Kx6Xdb3GG-s9aKb+1FnstdKWvi6+Vg@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.98.134]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/Q8hEgSUXb0LPlpl9zkjrOyE7QRs
Cc: "isis-chairs@tools.ietf.org" <isis-chairs@tools.ietf.org>, "draft-xu-isis-mpls-elc@tools.ietf.org" <draft-xu-isis-mpls-elc@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: Fri, 06 Jun 2014 09:02:04 -0000


> -----Original Message-----
> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Robert Raszuk
> Sent: Friday, June 06, 2014 3:45 PM
> 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
> 
> Xu,
> 
> > Since he MPLS-based SPRING or SR architecture has no change to the
> > MPLS data-plane, why can't we apply the EL concept directly to SPRING
> > or SR architecture?
> 
> You sure can. That was not my point. My point was that we should analyze and
> also consider alternatives other then EL approach.
> 
> 
> > be orders of magnitude less in the SR concept) is true. Compare LDP
> > with the IGP-based label distribution protocol, why do you believe the
> > latter means orders of magnitude less of bindings?
> 
> 
> Because as it has been already proven in other threads number of SR nodes in a
> given domain may be much less then number of IGP nodes. (I remove the adj
> SIDs requirement for now). In the latter and in the LDP based FECs you rather
> must support signalling of ranges of FECs end to end for it to work. With SR you
> can just do it for 10 nodes in 500 node IGP domain to get pretty good results.
> That's key difference.

Oho, in the LDP case, you can use the local label allocation filtering to selectively allocate local labels for a subset of the prefixes learned from the IGP. IMHO, there is no significant difference between LDP and IGP as the label distribution protocol, especially from the mpls forwarding table scalability perspective.

> > What' the same mistakes in your mind? The entropy label concept as defined
> in RFC6790? Or allocate a single label rather than a label range for a given FEC?
> 
> Mistake that you need a new level of stack to support load balancing.
> If MPLS would provide few additional bits in the header day one Kireeti would
> not need to invent entropy labels at all. :)

>From the MPLS label stack perspective, containing few additional bits at every MPLS header of the label stack may not be ideal as well:)

> With SID range we can accomplish the same without need to touch MPLS data
> plane so it is fully backwords compatible too.

The above argument is not true unless the MPLS forwarding is based on the longest-match algorithm:) Otherwise, the MPLS forwarding table scalability issue will emerge while the load-balancing issue is solved.

Best regards,
Xiaohu

> Cheers,
> R.
> 
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg