[Isis-wg] Comments on draft-ietf-isis-segment-routing-extensions-01

[Xuxiaohu <[e-mail]>]

Hi all, 

The following are some comments on draft-ietf-isis-segment-routing-extensions-01 (Note that the former four comments are applicable to draft-psenak-ospf-segment-routing-extensions-05 as well.):

1. Terminology inconsistency issues

The first example is about the semantics of the SID. According to the following description in section 2.1 "...SID/Index/Label: according to the V and L flags, it contains...", the SID would be something other than label and index. However,  in the same section, it said "... Multiple Prefix-SIDs Sub-TLVs MAY appear on the same prefix in which case each SID is encoded as a separate Sub-TLV....", here the SID seems to be a generic terminology, which could be index, label or SID. 

The second example is about the length of the SID (here the SID is something other than index and label). In section 2.1, it said "...A variable length SID (e.g.: an IPv6 address SID)...." However, in section 2.3, it said "... SID/Label: if length is set to 3 then the 20 rightmost bits represent a MPLS label.  If length is 4 then the value represents a 32 bits SID..." 


2. The uncertain usage of the 32-bit SID

It said in draft-previdi-6man-segment-routing-header-01 that "In Segment Routing IPv6 the SID is an IPv6 address". Therefore, what's the usage of the 32-bit SID (see section 2.3, it said "... SID/Label: if length is set to 3 then the 20 rightmost bits represent a MPLS label.  If length is 4 then the value represents a 32 bits SID)?


3. The uncertain usage of the 16-octect SID in the Prefix-SID sub-TLV

In IPv6-SR case, since the SID is an IPv6 address, what's the usage of the prefix-SID sub-TLV? It has been said in draft-previdi-6man-segment-routing-header-00 that " When Segment Routing is applied to IPv6, segments are encoded as 128-bit IPv6 addresses.  This implies that, in the IPv6 instantiation of SR, the SID values are in fact the prefixes advertised in the IPv6 control-plane.  Hence there's no need to advertise any additional specific identifier (other than IPv6 prefix) for the purpose of SR. This simplifies the introduction of IPv6 Segment Routing in existing protocols (i.e.: IS-IS, OSPF and BGP). "
I noticed that the above statement has been disappeared in the -01 version. Did that mean that the co-authors of that draft have changed their minds significantly?


4. Suggestion on the algorithm field in the prefix-SID sub-TLV

It seems that using various algorithms in the best path computation could also be applicable to some cases other than SR. For instance, use different algorithms for different topologies [rfc5120]. Therefore, it seems better to decouple the best path computation algorithm advertisement from the SR-specific advertisement. In this way, the algorithm is just coupled with the topology while the labels advertised through the prefix-sid sub-TLVs could be used to determine to which topology the received SR-MPLS packet belongs to. This behavior is much similar to the LDP and the LDP-MT. In other words, the SR-specific IGP extension just plays the role of label distribution protocol which shouldn't have any impact on the path computation behavior. 

5. The lack of MT-ID field in the SID/Label Binding TLV

I had suggested to add an MT-ID field in the SID/Label Binding TLV and Stefano had agreed to that suggestion. But it seems that the MT-ID field has not been added yet.

6. Suggestion on SR-Capabilities Sub-TLV
The SR-Capabilities Sub-TLV is used to advertise: 1) data-plane capability; 2) range of SID/Label values. It seems better to advertise these two capabilities via two separate sub-TLVs, e.g., DP-Capability sub-TLV and SID/Label Range sub-TLV. In the way, the role of SID/Label Range sub-tlv is consistent with the counterpart in OSPF extensions (i.e., SID/Label Range TLV). Anyway, it seems better to keep the ISIS and OSPF extensions for the same function as consistent as possible. 

Best regards,
Xiaohu