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

"Nobo Akiya (nobo)" <> Thu, 05 June 2014 22:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A3C9E1A02CC for <>; Thu, 5 Jun 2014 15:44:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -115.152
X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id H0dkN7m5O0dk for <>; Thu, 5 Jun 2014 15:44:48 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0A76C1A02B5 for <>; Thu, 5 Jun 2014 15:44:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=1714; q=dns/txt; s=iport; t=1402008282; x=1403217882; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VlKk9j5it5sxajtCBumLiHeJe5+jRGgF4SqoFNVfqWo=; b=eUTtmg6YBNDL1+FGq3sKWtznn+i/KGfiW79VXkA4js/3nbzu0hbxy0dY J/FDaDUEKpZplna2oNNolxJnOldPTIGeZMi+b7kTQfIt2vVqityo8F8dF FftBwW1rdiFmJbVumwJB96yQ1jye0rABEhV2bgu4SBDbEuHU+dsduEDZ5 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="4.98,984,1392163200"; d="scan'208";a="330902967"
Received: from ([]) by with ESMTP; 05 Jun 2014 22:44:41 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s55Mie2R006751 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Jun 2014 22:44:40 GMT
Received: from ([fe80::747b:83e1:9755:d453]) by ([]) with mapi id 14.03.0123.003; Thu, 5 Jun 2014 17:44:40 -0500
From: "Nobo Akiya (nobo)" <>
To: "Bragg, Nigel" <>, Robert Raszuk <>
Thread-Topic: [Isis-wg] Request for WG adoption of draft-xu-isis-mpls-elc-00
Thread-Index: Ac9z2gorbAmJYe4UTpeoTQ6gc4g+PgIyyZiAAQ96rAAACcOIkP//x6aAgABHMjD//8tngIAADs+A///kHmA=
Date: Thu, 5 Jun 2014 22:44:40 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Thu, 05 Jun 2014 22:44:49 -0000

Hi Robert,

> I do not agree. Assume v6 SR where I advertise instead of single SID say a
> block of /96. It is still one prefix for all what forwarding needs to care about.
> What would be different for that prefix vs /128 prefix from the point of view
> of  "resources" reserved, consumed, advertised and OAM ?

In MPLS, there's no standards in load balancing. Meaning an implementation may load balance only on the top label, only on the bottom label or set of labels which may or may not be the entire label stack. To take this into account, every SID advertised will need to be advertised as a "range", even service SIDs. And what you are suggesting is that the "range" needs to be 7 or 8 bits out of 20 bits. Yes even SID advertisements can be optimized to take the "range" into account, but still a very big link/service label space & SRGB is required for this.

In addition, AFAIK, many existing implementations need specific label entry in the forwarding table, i.e. masked label entry isn't supported. So in these implementations, every advertised SIDs will exist. That will mean it is very beneficial for OAM to test every one of these SIDs. For example, if we were to use BFD to do continuity check, then we now need exploding number of BFD sessions to test every SID.

I think what you are proposing is interesting, but I do see potential some consequences that should be discussed/evaluated.

> > I still see tackling EL to be appealing :)
> Is this still more appealing then say mpls over UDP draft ;-) ?

I prefer not to get into this topic for now :)