Alvaro – Responses inline.
From: Alvaro Retana <[email protected]> Sent: Wednesday, April 03, 2019 2:22 PM To: Les Ginsberg (ginsberg) <[email protected]>; [email protected] Cc: [email protected]; [email protected]; Uma Chunduri <[email protected]> Subject: RE: AD Review of draft-ietf-isis-segment-routing-extensions-22 On March 29, 2019 at 1:55:17 AM, Les Ginsberg (ginsberg) ([email protected]<mailto:[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. [Les:] Understood – thanx. 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. [Les:]I am not sure what your concern is. There is already a reference to 2.1.1.1. And the description states the settings for V/L flags – for which the defaults are different for adj-sid than prefix-sid. What do you think is still missing? (I probably should not have indicated “done” on 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... [Les:] ISO 10589 allows a system-id to be from 1-8 octets (and the value “0” is interpreted as “6” for historical reasons). But in practice only the value 6 (and its alias “0”) are used. The text you quote from RFC 1195 is part of a non-normative Appendix which is illustrating how an implementation might build tables in support of running the Dijkstra algorithm. It isn’t relevant here. I will update the text to indicate the fields are of “ID Length” (though in practice this will always be “6”). Do you want to specify any check to make sure that the System ID in fact corresponds to a valid neighbor? [Les:] No. If the neighbor cannot be found then the SID will never be used. ... > 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. [Les:] The entire section is about the encoding of the Binding TLV and sub-section 2.4 is about Mapping Server support in the Binding TLV. I am not sure what is causing the confusion on your part. ... > 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). [Les:] OK ... > 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. [Les:] Agreed – will use tables. ... 1313 This document creates the following sub-TLV Registry: ... [major] Please indicate what the range is. [Les:] Ack … 1317 Registration Procedure: Expert review [] We’re going to need Designated Experts. Volunteers? [Les:] Drafts have never addressed asking for DE volunteers – but I think you know where to find them. ☺ [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. [Les:] Ack ... 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. [Les:] OK [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? [Les:] No – this is standard text for most IS-IS drafts – referring to the authentication drafts as being applicable. [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. [Les:] Definitely NOT!! ☺ This is junk which was only added to OSPF because the Security review demanded it. It is base protocol functionality. There is nothing unique to the new TLVs that makes malformed TLVs any more or less dangerous than any other. I promise to resist such a demand if it is made in this case. ... 1415 9.1. Normative References ... [minor] I think that these references can be Informative: [Les:] As you wish… 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. ;-) [Les:] Stefano promises to rent me a room in his villa (as soon as he buys one). Les
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
