Hi Deccan,

On 4/22/15, 4:23 PM, "Stefano Previdi (sprevidi)" <[email protected]>
wrote:

><adding isis list>
>
>Hi Deccan,
>
>On Apr 20, 2015, at 6:03 AM, [email protected] 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.
>> 
>> 
>> 
>
>_______________________________________________
>Isis-wg mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/isis-wg

_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring

Reply via email to