Subject: [spring] some questions for SR-ISIS

From: [email-masked]
Date: Mon, 20 Apr 2015 12:03:56 +0800

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. Another way may directly advertise global 
label, but it's not appropriate for distribution network.
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?

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?

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.

---

From: "Stefano Previdi (sprevidi)" <[email-masked]>
Date: Wed, 22 Apr 2015 10:53:48 +0000

<adding isis list>

Hi Deccan,

On Apr 20, 2015, at 6:03 AM, [email-masked] wrote:
> I have some questions when study draft-ietf-isis-segment-routing-extensions-03 
> 
> 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.