On March 29, 2019 at 1:55:17 AM, Les Ginsberg (ginsberg) ([email protected]) wrote:
Les: Hi! Thanks for the update. I have a couple of comments on your replies — no showstoppers. However, it looks like my original comments were truncated; I added the remaining comments at the end. I am starting the IETF LC. The remaining comments can be addressed with any other comments that are received during LC. Thanks!! Alvaro. .... > 445 V-Flag: Value flag. If set, then the Adj-SID carries a value. > 446 By default the flag is SET. > > [minor] Is the description the same at the V-Flag in §2.1? If so, then > indicating that, or at least also pointing out here that the value is > carried instead of an index would be helpful. > [Les:] Done. I think you missed this one. .... > 544 System-ID: 6 octets of IS-IS System-ID of length "ID Length" as > 545 defined in [ISO10589]. > > [major] Which System-ID? > [Les:] Text has been altered to indicate it is the system-id of the neighbor. > [major] "6 octets of...length "ID Length"" ?? > [Les:] Done. I was trying to point out that the text is confusing where it says that the System-ID, which is (from the figure) a 6-octet field, is represented by "6 octets…of length "ID Length”. Is the length 6 octets or “ID Length”? ISO10589 says: "System identifier — a variable length field from 1 to 8 octets”…RFC1195 suggests this: "N is a system identifier. In the level 1 algorithm, N is a 6 octet ID for OSI end systems, a 7 octet ID for routers, or an 8 octet IP Internal Reachability Information entry.” For both cases, it the length of the System ID is > 6 octets, which bits are expected to be in the sub-TLV? If the system ID is < 6 octets (which I doubt, but just to cover ISO10589), what next? Maybe I’m just confused... Do you want to specify any check to make sure that the System ID in fact corresponds to a valid neighbor? .... > 812 The other flags defined in Section 2.1 are not used by the Mapping > 813 Server and MUST be ignored at reception. > > [major] How does the receiver know that the sub-TLV was originated by a > Mapping Server? Is it the case that it would originate a Binding TLV? > IOW, would the other flags always be ignored when the sub-TLV is included > in the Binding TLV (but not other TLVs)? Does this apply also to the > Multi-Topology SID/Label Binding TLV (§2.5)? > [Les:] "Yes" to all of your questions. Please add some text to clarify. .... > 1075 3.3. SR Local Block Sub-TLV > > 1077 The SR Local Block (SRLB) Sub-TLV contains the range of labels the > 1078 node has reserved for local SIDs. Local SIDs are used, e.g., for > 1079 Adjacency-SIDs, and may also be allocated by other components than > 1080 IS-IS protocol. As an example, an application or a controller may > 1081 instruct the router to allocate a specific local SID. Therefore, in > 1082 order for such applications or controllers to know what are the local > 1083 SIDs available in the router, it is required that the router > 1084 advertises its SRLB. > > [nit] s/than IS-IS protocol/than the IS-IS protocol [Les:] Done. > > > ... > 1122 The originating router MUST NOT advertise overlapping ranges. > > [major] What should the receiver do if the ranges overlap? I'm assuming > the same thing as what was specified before...please be specific. > [Les:] Similar question is relevant to SRGB and the behavior has been specified in https://tools.ietf.org/html/draft-ietf-spring-segment-routing-mpls-18#section-2.3 and this draft references it. I would do the same here, but the SR MPLS draft does not specify behavior for SRLB - even though the referenced section is entitled "Segment Routing Global Block and Local Block". Best solution I would think is to update SR MPKS draft so that a reference to it could be added here. Please go ahead and add the reference. I’ll make sure to address the issues when that document comes to the IESG (should be soon as it already finished IETF LC). .... > 1190 5. IANA Considerations > > 1192 This documents request allocation for the following TLVs and subTLVs Hmmm…. It looks like my comments were truncated (I’ve seen this happen a couple of times). :-( Here’s the rest: 1190 5. IANA Considerations 1192 This documents request allocation for the following TLVs and subTLVs.. [minor] IANA may be ok, but I find the formatting below a little confusing. A table may be a better option. .... 1313 This document creates the following sub-TLV Registry: .... [major] Please indicate what the range is. … 1317 Registration Procedure: Expert review [] We’re going to need Designated Experts. Volunteers? [major] Are there specific instructions/considerations that the DEs should be aware of when assigning from this new registry? If so, please add some text. .... 1333 6. Security Considerations 1335 With the use of the extensions defined in this document, IS-IS 1336 carries information which will be used to program the MPLS data plane 1337 [RFC3031]. In general, the same types of attacks that can be carried 1338 out on the IP/IPv6 control plane can be carried out on the MPLS 1339 control plane resulting in traffic being misrouted in the respective 1340 data planes. However, the latter may be more difficult to detect and 1341 isolate. Existing security extensions as described in [RFC5304] and 1342 [RFC5310] apply to these segment routing extensions. [nit] Maybe break up the paragraph into multiple ones with independent points. [major] With the last sentence, are you implying that authentication is required when IS-IS is carrying SR extensions? If so, please be explicit. Why would these extensions be different than any other extension? [minor] The companion OSPF documents added the following paragraph to the Security Considerations as a result of one of the reviews...perhaps consider including something similar: Implementations MUST assure that malformed TLV and Sub-TLV defined in this document are detected and do not provide a vulnerability for attackers to crash the OSPFv2 router or routing process. Reception of malformed TLV or Sub-TLV SHOULD be counted and/or logged for further analysis. Logging of malformed TLVs and Sub-TLVs SHOULD be rate-limited to prevent a Denial of Service (DoS) attack (distributed or otherwise) from overloading the OSPF control plane. .... 1415 9.1. Normative References .... [minor] I think that these references can be Informative: 1463 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1464 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1465 2008, <https://www.rfc-editor.org/info/rfc5305>. 1467 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1468 DOI 10.17487/RFC5308, October 2008, 1469 <https://www.rfc-editor.org/info/rfc5308>. .... 1527 Les Ginsberg (editor) 1528 Cisco Systems, Inc. 1529 IT [nit] I didn't know you had moved. ;-)
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
