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

Xuxiaohu <xuxiaohu@huawei.com> Fri, 06 June 2014 03:24 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 08DF91A03E2 for <isis-wg@ietfa.amsl.com>; Thu, 5 Jun 2014 20:24:32 -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 iafqYKUMoVpt for <isis-wg@ietfa.amsl.com>; Thu, 5 Jun 2014 20:24:30 -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 AE5C91A01C5 for <isis-wg@ietf.org>; Thu, 5 Jun 2014 20:24:27 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEX65140; Fri, 06 Jun 2014 03:24:20 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Jun 2014 04:23:21 +0100
Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Jun 2014 04:24:17 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.62]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Fri, 6 Jun 2014 11:24:15 +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+PgIyyZiAAPQ87gAALrz7cA==
Date: Fri, 6 Jun 2014 03:24:15 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827EBC7@NKGEML512-MBS.china.huawei.com>
References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0827D488@NKGEML512-MBS.china.huawei.com> <CA+b+ERmCusprkp3nYcwUtK4F0qmiv6-DogsEQ7vcJSgPRaHuPg@mail.gmail.com>
In-Reply-To: <CA+b+ERmCusprkp3nYcwUtK4F0qmiv6-DogsEQ7vcJSgPRaHuPg@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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/d7mO5-sQwbWAa0SVPTVGGs7dPTg
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 03:24:32 -0000

Hi Robert,

> -----Original Message-----
> From: rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert
> Raszuk
> Sent: Thursday, June 05, 2014 8:25 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
> 
> 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.

I'm a bit confused with the above argument. The EL usage (i.e., the data-plane processing of ELs) is completely independent from the signaling protocols for ELs. In other words, assume operators choose to manually configure the ELC of egress LSRs on a given ingress LSR, the EL trick can be used without any problem. The signaling protocol just provides a way to automatically discovery the ELC of egress LSRs. This situation has no difference from RFC5512. Without RFC5512, do you believe that the MPLS-in-GRE or MPLS-in-IP tunnels couldn't be used between PE pairs? 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? 

> 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.

In this thread, we are just talking about the MPLS-based SRPING or SR case. In that case, I don't believe the above argument (i.e., that number of such bindings will naturally
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?

> 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.

It seems that the above approach you mentioned has been denied by RFC6790 (See section 2 of RFC6790).

> 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 ?

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?

Best regards,
Xiaohu

> 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