Dear authors: I just finished reading this document. I have several comments and concerns that I included inline below.
One item that I want to highlight here is the lack of specific procedures defined to handle the cases of multiple advertisements (in both §2 and §3). Please take a look at my specific comments below -- in short, a clear specification is required for proper interoperability. I will wait for (at least) this item to be addressed before starting the IETF LC. Thanks! Alvaro. [The line numbers came from the idnits output.] .... 76 1. Introduction .... 95 links in the network MSD is relevant, MSD capabilites should be 96 advertised by every IS-IS router in the network. [nit] s/capabilites/capabilities .... 109 or SIDs associated with another dataplane e.g., IPv6. Although MSD 110 advertisements are associated with Segment Routing, the 111 advertisements MAY be present even if Segment Routing itself is not 112 enabled. [minor] Given that you're using Normative language... It would be nice if you expanded on the use of the MSD in a non-SR network. Something simple such as "a SID and a label are the same thing" would be enough. 114 1.1. Conventions used in this document 116 1.1.1. Terminology [minor] Except for BMI/MSD, the other terms are not definitions, just expansions. Some of the abbreviations are already included in the RFC Editor Abbreviations List [1]. In general, it would be better to just expand on first use (BGP-LS, for example, is used *before* this section) than to have this section with expansions. [1] https://www.rfc-editor.org/materials/abbrev.expansion.txt .... 147 2. Node MSD Advertisement .... 156 0 1 157 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Type | Length | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | MSD-Type | MSD Value | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 // ................... // 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | MSD-Type | MSD Value | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 Figure 1: Node MSD Sub-TLV 171 Type: 23 (allocated by IANA via the early assignment process) 173 Length: variable (minimum of 2, multiple of 2 octets) and represents 174 the total length of value field. [nit] ...in octets (?). 176 Value: field consists of one or more pairs of a 1 octet MSD-Type and 177 1 octet MSD-Value. [nit] There is no "Value" field illustrated above. You might want to reword a little. [nit] The figure says "MSD Value", but the text talks about "MSD-Value". .... 191 If there exist multiple Node MSD advertisements for the same MSD-Type 192 originated by the same router, the procedures defined in [RFC7981] 193 apply. [major] Does this text refer to multiple node MSD sub-TLVs (inside the same, or different, IS-IS Router CAPABILITY TLV), or to the same MSD-Type (included multiple times in a node MSD sub-TLV), or both? [major] The only relevant text I can find in rfc7981 is this: Where a receiving system has two copies of an IS-IS Router CAPABILITY TLV from the same system that have conflicting information for a given sub-TLV, the procedure used to choose which copy shall be used is undefined. I then don't know how to handle the multiple advertisements. Please point me in the right direction. 195 3. Link MSD Advertisement 197 The link MSD sub-TLV is defined for TLVs 22, 23, 25, 141, 222, and 198 223 to carry the MSD of the interface associated with the link. MSD 199 values may be learned via a hardware API or may be provisioned. [nit] A reference to the appropriate RFCs would be nice. 201 0 1 202 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Type | Length | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | MSD-Type | MSD Value | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 // ................... // 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | MSD-Type | MSD Value | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 Figure 2: Link MSD Sub-TLV 216 Type: 15 (allocated by IANA via the early assignment process) 218 Length: variable (minimum of 2, multiple of 2 octets) and represents 219 the total length of value field. [nit] ...in octets (?). 221 Value: consists of one or more pairs of a 1 octet MSD-Type and 1 222 octet Value. [nit] There is no "Value" field illustrated above. You might want to reword a little. [nit] The figure says "MSD Value", but the text talks about "Value". .... 235 If multiple Link MSD advertisements for the same MSD Type and the 236 same link are received, the procedure used to select which copy is 237 used is undefined. [major] Does this text refer to multiple link MSD sub-TLVs (inside the same, or different, IS-IS Router CAPABILITY TLV), or to the same MSD-Type (included multiple times in a link MSD sub-TLV), or both? [major] Without a procedure "it is unlikely that multiple implementations of the specification would interoperate" [2]. [2] https://www.ietf.org/blog/discuss-criteria-iesg-review/ 239 4. Using Node and Link MSD Advertisements [major] After reading this section, I still don't know how do use the advertisements. What should a receiver do with the values? Maybe the use is constrained to a controller...maybe the exact operation is our of the scope of this document. Either way, please say something. 241 When Link MSD is present for a given MSD type, the value of the Link 242 MSD MUST take preference over the Node MSD. When a Link MSD type is 243 not signalled but the Node MSD type is, then the Node MSD type value 244 MUST be considered as the MSD value for that link. [nit] s/signalled/signaled .... 258 5. Base MPLS Imposition MSD 260 Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS 261 labels a node is capable of imposing, including all 262 service/transport/special labels. 264 Absence of BMI-MSD advertisements indicates solely that the 265 advertising node does not support advertisement of this capability. [major] The MSD Types are applicable for both nodes and links, right? The description above only talks about nodes -- what about links? 267 6. IANA Considerations 269 This document requests IANA to allocate a sub-TLV type for the new 270 sub TLV proposed in Section 2 of this document from IS-IS Router 271 Capability TLV Registry as defined by [RFC7981]. [minor] The registry is called "Sub-TLVs for TLV 242 (IS-IS Router CAPABILITY TLV)". [3] [3] https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-242 .... 303 This document requests creation of an IANA managed registry under a 304 new category of "Interior Gateway Protocol (IGP) Parameters" IANA 305 registries to identify MSD types as proposed in Section 2 and 306 Section 3. The registration procedure is "Expert Review" as defined 307 in [RFC8126]. Suggested registry name is "IGP MSD Types". Types are 308 an unsigned 8 bit number. The following values are defined by this 309 document [nit] s/under a new category/under the category [major] This creation of the registry needs to include the "required documentation and review criteria, giving clear guidance to the designated expert" -- please see §4.5 in rfc8126. 311 Value Name Reference 312 ----- --------------------- ------------- 313 0 Reserved This document [major] 0 is not Reserved, but has a specific meaning (from §2 and §3). 314 1 Base MPLS Imposition MSD This document 315 2-250 Unassigned This document 316 251-254 Experimental This document 317 255 Reserved This document 319 Figure 6: MSD Types Codepoints Registry 321 7. Security Considerations 323 Security considerations as specified by [RFC7981] are applicable to 324 this document. 326 Advertisement of the additional information defined in this document 327 that is false, e.g., an MSD that is incorrect, may result in a path 328 computation failing, having a service unavailable, or instantiation 329 of a path that can't be supported by the head-end (the node 330 performing the imposition). [major] rfc7981 says that "specifications based on this mechanism need to describe the security considerations around the disclosure and modification of their information". I think that the paragraph above applies also to modification. What about disclosure? .... 364 10.2. Informative References [major] rfc8126 should be Normative. .... 390 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 391 Writing an IANA Considerations Section in RFCs", BCP 26, 392 RFC 8126, DOI 10.17487/RFC8126, June 2017, 393 <https://www.rfc-editor.org/info/rfc8126>.
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
