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

peng.shaofu@zte.com.cn Thu, 23 April 2015 07:53 UTC

Return-Path: <peng.shaofu@zte.com.cn>
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 0FA3D1B2F4D; Thu, 23 Apr 2015 00:53:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.61
X-Spam-Level:
X-Spam-Status: No, score=-103.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 BPOMMctKJJxY; Thu, 23 Apr 2015 00:53:46 -0700 (PDT)
Received: from mx6.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 298861B2F52; Thu, 23 Apr 2015 00:53:45 -0700 (PDT)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 317BE633A42BF; Thu, 23 Apr 2015 15:53:39 +0800 (CST)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 52905263D6083; Thu, 23 Apr 2015 15:53:38 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id t3N7rL0Q033466; Thu, 23 Apr 2015 15:53:21 +0800 (GMT-8) (envelope-from peng.shaofu@zte.com.cn)
To: sprevidi@cisco.com, psarkar@juniper.net
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OFB1002EFD.AC2B3520-ON48257E30.0024C8EF-48257E30.002B581D@zte.com.cn>
From: peng.shaofu@zte.com.cn
Date: Thu, 23 Apr 2015 15:53:17 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2015-04-23 15:53:22, Serialize complete at 2015-04-23 15:53:22
Content-Type: multipart/alternative; boundary="=_alternative 002B581A48257E30_="
X-MAIL: mse02.zte.com.cn t3N7rL0Q033466
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/NHZwe0GcfNehOnz0vPAeRjPgwAs>
Cc: spring@ietf.org, isis-wg@ietf.org
Subject: Re: [Isis-wg] [spring] some questions for SR-ISIS
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: Thu, 23 Apr 2015 07:53:50 -0000

hi Stefano, Pushpasis

Thanks for your answers.
The first question is now unambiguous.
For the second question, Pushpasis's example shows that I made a mistake.

Yes, it is no problem like the following advertisement format as 
Pushpasis's example shows
A1: 100(S=0), 1000(S=1),
A2: 200(S=0), 1000(S=1), 2000(S=1)
A3: 300(S=0), 2000(S=1)

The Key behaviour is that all adj-sids for a adjacency is advertised 
together. 

So, if adjacency's original node changes the configuration, for example, 
it changes the adj-sid value for adjacency group <A1,A2> from 1000 to 
1500, it just re-advertise:
A1: 100(S=0), 1500(S=1),
A2: 200(S=0), 1500(S=1), 2000(S=1)

When ingress node received the new advertisement, it can compare with the 
existing data, and know A1 & A2 leave group-1000 and join group-1500.

But if all adj-sids for a adjacency is not advertised together, there 
would bring some difficulty.
For example, if we advertise A2 like this: 
A2: 200(S=0)
A2: 1500(S=1)
A2: 2000(S=1)
Then, ingress node never knows whether A2 join two adjacency 
group(group-1500 and group-2000) or only one adjacency group(group-2000 
will overwrite group-1500). 
Fortunately, it is just an null hypothesis.

Regards,

deccan

-------------------------------------------parting 
line----------------------------------
Hi Deccan,

On 4/22/15, 4:23 PM, "Stefano Previdi (sprevidi)" <sprevidi at cisco.com>
wrote:

><adding isis list>
>
>Hi Deccan,
>
>On Apr 20, 2015, at 6:03 AM, peng.shaofu at zte.com.cn 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".
>
>s.
[Pushpasis] I think you are trying to refer to a case where the same
adjacency is part of two adjacency-sets. I guess the same adjacency will
advertise 3 adjacency-sids, one for the indvidual link itself (S-Flag set
to 0) and one for each adjacency sets it belongs to (S-Flag set to 1). The
adjacency-sids in this cases will be additive and not overwrite each
other. The Adjacency-SID associated with adjacency set itself will act as
the group-identifier. There should not be a separate name needed. The same
Adjacency-SID will be advertised by all adjacencies that are part of it.

So if are 3 adjacencies A1, A2, A3 with individual sids 100, 200, 300
respectively. And there are following two Adjacency sets

Set 1: adjacencies A1 and A2, SID: 1000
Set 2: adjacencies A2 and A3, SID: 2000

Then following are the adjacency-Sids advertised by each adjacencies

A1: 100(S=0), 1000(S=1),
A2: 200(S=0), 1000(S=1), 2000(S=1)
A3: 300(S=0), 2000(S=1)

Hope my understanding was correct :)

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