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 > [email protected] > https://www.ietf.org/mailman/listinfo/ospf _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
