On Jun 13, 2014, at 4:05 AM, Xuxiaohu wrote: > Hi Stefano, >> -----Original Message----- >> From: Stefano Previdi (sprevidi) [mailto:[email protected]] >> Sent: Thursday, June 12, 2014 6:42 PM >> To: Xuxiaohu >> Cc: [email protected]; OSPF List >> Subject: 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. > > If you want to take the "SID" as a generic term which would be interpreted as > an MPLS label in the MPLS-SR case and an IPv6 address in the IPv6-SR case, > you'd better not list it with index/label in parallel (e.g., a description in > section 2.1 "...SID/Index/Label: according to the V and L flags, it > contains..." ) . Otherwise, it would be deemed as a particular format of the > segment identifier (e.g., a 32-bit SID which was specifically designed for > IPv6-SR previously, or a 128-bit SID which is currently designed for > IPv6-SR). That's my point. > > >>> 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 > > If the node-sid is an IPv6 address for sure, you'd better not say " the > Node-SID is an IPv6 prefix ". Otherwise, it would cause an unnecessary > confusion.
ok, sorry. I intended a /128 prefix but you're right and I'll fix that. >> 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." > > If so, does it mean that the prefix-sid sub-TLV would not be used in the > IPv6-SR case? not at this stage. In the future we may come back and revisit the idea of using 32bit SIDs for ipv6 as well. > Or do you still want to use it for some IPv6 prefixes with prefix-len being > shorter than 128? > >>> 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. > > A generic algorithm sub-TLV could be useful in some cases other than SR in > the future. Take the TE router-id sub-TLV of the CAPABILITY TLV as an > example, the routable address contained in such sub-TLV should have not been > coupled with the TE purpose since it is now useful in some cases other than > TE (note that this was discussed a few weeks ago in the ISIS mailing-list). > >>> 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. > > I agree that the most important goal is to keep consistency between > functionalities. However, wouldn't it be better if the consistency of > encodings between ISIS and OSPF can be kept as well without any additional > cost? I disagree. Protocols are not the same and in the encodings one protocol may require additional info while the other already has it so let's not try to do something that: 1. is not needed 2. will require substantial effort Thanks. s. > At least, it becomes more easy for implementers and operators to read these > two drafts if the consistency of encodings can be kept. > > Best regards, > Xiaohu > >> s. >> >> >>> >>> Best regards, >>> Xiaohu >>> >>> _______________________________________________ >>> OSPF mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/ospf > > _______________________________________________ > Isis-wg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/isis-wg _______________________________________________ OSPF mailing list [email protected] https://www.ietf.org/mailman/listinfo/ospf
