Re: [Isis-wg] some questions for SR-ISIS

"Stefano Previdi (sprevidi)" <> Wed, 22 April 2015 10:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 81A7C1B340C; Wed, 22 Apr 2015 03:53:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Xw3JKz7VhgNv; Wed, 22 Apr 2015 03:53:04 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BBD121A90F6; Wed, 22 Apr 2015 03:53:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4020; q=dns/txt; s=iport; t=1429699985; x=1430909585; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6VLjVbfN/s1Hwgropc7IMyvijwD++8MUSZL1XC3cqv8=; b=JHK8Ca1PmuXa5zk8gmrDhPVMdNhjSPIwd3JpxZrKZ39hZqkZVwPjjH2A pIdSlkDTF777uJs4INQXvfz7TYOW1/LkaqZp2Df6Mir6v9Z/2o+ZD8iEx 5gvKxNzkZTv5ipys/2iyrPDBlrYVDBipSuJsiKcnUX+UV+I2ysctWgz85 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.11,623,1422921600"; d="scan'208";a="413832124"
Received: from ([]) by with ESMTP; 22 Apr 2015 10:53:04 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t3MAr3WO015823 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Apr 2015 10:53:04 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Wed, 22 Apr 2015 05:53:03 -0500
From: "Stefano Previdi (sprevidi)" <>
To: "" <>
Thread-Topic: some questions for SR-ISIS
Thread-Index: AQHQex8QBOvYnUBhzEmpCFpBHaG1op1ZMpUA
Date: Wed, 22 Apr 2015 10:53:48 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="gb2312"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, " list" <>
Subject: Re: [Isis-wg] some questions for SR-ISIS
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: Wed, 22 Apr 2015 10:53:06 -0000

<adding isis list>

Hi Deccan,

On Apr 20, 2015, at 6:03 AM, wrote:
> hi Stefano and other SR-ISIS authors, 
> I have some questions when study draft-ietf-isis-segment-routing-extensions-03 
> 1) for Prefix-SID Sub-TLV 
> It seems that we cannot support Prefix-SID Propagation with local label inside the level, because each node cannot change the received flooding information such as the label value before it propagate again, otherwise packet inconsistency will occur in some remote nodes. 
> So, the only way to create the SR LSP inside the level is to advertise prefix-sid with INDEX type.

indeed. note that since most of the implementors agreed to use the same SRGB space for SR, we're pretty close to the concept of global labels... oops, no, sorry, I went too far...

> Another way may directly advertise global label,

you said that, not me... ;-)

> but it's not appropriate for distribution network. 

"not appropriate", yes, let's put it this way... 

> In the case of propagation between levels, although in the document it says the level-1-2 router can change the flooding information, but the same problem is there, the total SR LSP can not be building with local label advertisement. 
> Is it right? 

ok, jokes apart, the reason why indexes have been defined is to cope with the local scope of mpls labels. I think it's good not to brake an architecture but I also think it's good to focus on practical problems to solve and the index gives you the best of both worlds: they don't brake mpls architecture and allows you to play with global (index) values.

> 2) for Adj-SID Sub-TLV 
> In the document is says that an adjacency-sid can set the S-flagļ¼Œbut it is possible that an adjacency can join many adjacency group. It is difficult for the ingress node to process the received Adj-SID Sub-TLV for the same specific remote adjacency with different  adjacency-sid value with S-flag set, whether adj-sid 200 can overwrite adj-sid 100 or they indicate different groups? 
> It seems that we need add ADJACENCY-GROUP-NAME information in the Adj-SID Sub-TLV. 
> Is it right? 

sorry, I'm not sure I understand your point. The S bit tells you that the value may be shared among other adjacencies. This will tell you what you call "group".


> Regards, 
> deccan 
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.