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

Xuxiaohu <> Fri, 06 June 2014 03:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 08DF91A03E2 for <>; Thu, 5 Jun 2014 20:24:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.852
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iafqYKUMoVpt for <>; Thu, 5 Jun 2014 20:24:30 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AE5C91A01C5 for <>; Thu, 5 Jun 2014 20:24:27 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id BEX65140; Fri, 06 Jun 2014 03:24:20 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 6 Jun 2014 04:23:21 +0100
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 6 Jun 2014 04:24:17 +0100
Received: from ([]) by ([]) with mapi id 14.03.0158.001; Fri, 6 Jun 2014 11:24:15 +0800
From: Xuxiaohu <>
To: Robert Raszuk <>
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: <>
References: <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
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: Fri, 06 Jun 2014 03:24:32 -0000

Hi Robert,

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

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,

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