Re: [OSPF] Comments on draft-ietf-isis-segment-routing-extensions-01

Hi Xiaohu,

On Jun 12, 2014, at 12:10 PM, Xuxiaohu wrote:
> 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..." 

I'm not sure I understand where the inconsistency is.

Prefix-SID goes with prefixes. Adj-SID goes with adjacencies.

Both SubTLVs may be value or index and may have local or global scope.

This is the flexibility we want to have.

> 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)?

you're right. I'll fix the text.

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

nope. The text you mentioned has been replaced by the following one:

"The Node-SID identifies a node. With SR-IPv6 the Node-SID is an IPv6 
 prefix that the operator configured on the node and that is used as 
 the node identifier. Typically, in case of a router, this is the IPv6 
 address of the node loopback interface. Therefore, SR-IPv6 does not 
 require any additional SID advertisement for the Node Segment. The 
 Node-SID is in fact the IPv6 address of the node."

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

initially, we thought about making the algorithm a generic TLV but 
later preferred to confine it to the SR context.

If there's consensus, I don't mind to enlarge the scope but I'd prefer 
not to re-invent MT.

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

I agree with you but since the binding TLV was not originally part of 
the SR proposal (i.e.: it's the merge with Hannes draft) I'd let Hannes 
to comment.

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

I disagree. Keeping encoding aligned between isis and ospf is NOT a goal. 
What is necessary is to keep consistency between functionalities.

s.

> 
> Best regards,
> Xiaohu
> 
> _______________________________________________
> OSPF mailing list
> OSPF@ietf.org
> https://www.ietf.org/mailman/listinfo/ospf