Hi Dale, Thank you for your detailed review and many valuable suggestions. Please find responses inline below starting with [JR]. Best regards, Jeong-dong -----Original Message----- From: "Dale Worley via Datatracker" <noreply@xxxxxxxx> To: <gen-art@xxxxxxxx>; Cc: <last-call@xxxxxxxx>; <teas@xxxxxxxx>; <draft-ietf-teas-gmpls-signaling-smp.all@xxxxxxxx>; Sent: 2022-02-03 (목) 12:11:06 (UTC+09:00) Subject: [Last-Call] Genart last call review of draft-ietf-teas-gmpls-signaling-smp-10 Reviewer: Dale Worley Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-teas-gmpls-signaling-smp-10 Reviewer: Dale R. Worley Review Date: 2020-02-02 IETF LC End Date: 2020-02-03 IESG Telechat date: not known Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Minor technical issue: These end nodes, in case of a failure of the working LSP, MUST avoid trying to switch the traffic to these protection LSPs that have been configured to use the shared resources and try switching the traffic to other protection LSPs, if available. It seems like this behavior is guaranteed without this specific requirement: The node that detects the resource failure will signal "Shared resources unavailable" to the end nodes of any lower-priority LSPs that use the failed resources. Thus, the end nodes will not try to switch the traffic of the working LSP to any of "these LSPs" (lower-priority LSPs). And consequently, they will try to switch the traffic to other protection LSPs. Indeed, it seems like the intermediate node should signal "Shared resources unavailable" to the end nodes of all protecting LSPs that use the failed resource, regardless of the LSPs' priorities -- all of them are non-functional. I suspect there is some complexity here that I do not understand. It may be worth describing that more explicitly. [JR] The first paragraph in Section 5.5 is for a lower priority protecting LSP that is being preempted, and the second paragraph, which contains the text you quoted, is for any lower priority protecting LSPs that are affected by the unavailable shared resources. As you expressed, I also agree with you that the current text needs to be described more explicitly. I propose the following update for the second paragraph: OLD: When the shared resources become unavailable, including a case of the shared resources failure, the same Notify message MUST also be generated by the intermediate node to all the end nodes of the protecting LSPs that have lower SMP preemption priorities than the one that has occupied the shared resources. These end nodes, in case of a failure of the working LSP, MUST avoid trying to switch the traffic to these protecting LSPs that have been configured to use the shared resources and try switching the traffic to other protection LSPs, if available. NEW: When a protecting LSP occupies the shared resources and they become unavailable, the same Notify message MUST also be generated by the intermediate node to all the end nodes of the protecting LSPs that have lower SMP preemption priorities than the one that has occupied the shared resources. In case the shared resources become unavailable due to a failure, the same Notify message MUST be generated by the intermediate node to all the end nodes of the protecting LSPs that have been configured to use the shared resources. These end nodes, in case of a failure of the working LSP, MUST avoid trying to switch the traffic to these protection LSPs that have been configured to use the shared resources and try switching the traffic to other protecting LSPs, if available. Nits/editorial comments: 1. Introduction The recovery resources for the protecting LSPs are pre-reserved during the provisioning phase, and explicit restoration signaling is required to activate (i.e., commit resource allocation at the data plane) a specific protecting LSP instantiated during the provisioning phase. At first, I misunderstood this to have the final "during the provisioning phase" modify "explicit restoration signaling is required". After re-reading it, I think that cannot be grammatically correct, and "during the provisioning phase" is part of "instantiated during the provisioning phase". But my confusion could have been avoided if the text was amended to "... a specific protecting LSP *that* was instantiated during the provisioning phase." [JR] Sorry for the confusion. It will be corrected as you suggested. o updates the definition of the 16-bit Reserved field [RFC4873] of the PROTECTION object to take the new SMP type into account (see Section 6.3). At first sight, this doesn't make sense -- how does adding SMP change how the bits of an unused field are used? The concept is that SMP signaling *uses* that field. So it would be clearer to say e.g. o updates the definition of the 16-bit Reserved field [RFC4873] of the PROTECTION object to allocate 8 bits to signal the SMP preemption priority (see Section 6.3). [JR] Indeed, it doesn't make any sense. We forgot to correct it after we did copy & paste the text above. It was a mistake and will be corrected as you suggested. 2. Conventions Used in This Document In addition, the reader is assumed to be familiar with the terminology used in [RFC4872], RFC 4426 [RFC4426], and RFC 6372 [RFC6372]. presumably for consistency you want to say In addition, the reader is assumed to be familiar with the terminology used in RFC 4872 [RFC4872], RFC 4426 [RFC4426], and RFC 6372 [RFC6372]. Although there seems to be a style question, as the forms "RFC xyzw [RFCxyzw]" and "[RFCxyzw]" (both as nouns) are both used frequently in this document. Resolving this is probably something the Editor can handle best. [JR] The form "RFC XXXX [RFCXXXX]" is used when RFC XXXX is referenced first, and after that, the form "[RFCXXXX]" is used in the rest of the document consistently. This style was suggested by one IETF expert when I first wrote an RFC. Since then, I have stuck to this way. Yes, the Editor can handle it best. I will leave it as is for the time being. 3. SMP Definition Pre-configuring but not activating a protecting LSP allows the common link and node resources in the protecting LSP to be shared by multiple working LSPs that are physically (i.e., link, node, Shared Risk Link Group (SRLG), etc.) disjoint. If I understand this correctly, the point is that multiple working LSPs may have protecting LSPs that are not disjoint, on the assumption that only one of the protecting LSPs will be active at a time. But this wording doesn't seem to mean that to me. Perhaps: Pre-configuring but not activating protecting LSPs allows link and node resources to be shared by the protecting LSPs of multiple working LSPs (that are physically (i.e., link, node, Shared Risk Link Group (SRLG), etc.) disjoint and thus unlikely to fail simultaneously). Perhaps that could be simplified to: Pre-configuring but not activating protecting LSPs allows link and node resources to be shared by the protecting LSPs of multiple working LSPs (that are themselves disjoint and thus unlikely to fail simultaneously). [JR] Yes, your text reads better. 4. Operation of SMP with GMPLS Signaling Extension At the end of section 4, it seems desirable to further describe the processing which it seems to me must happen: If F fails to allocate the protection resource, it sends a failure message to E, which causes E to remove the protection allocation, and then send a failure message to A. And so on for further nodes in the LSP. [JR] Current SMP APS protocol has not defined a failure message sent by an intermediate node to deallocate the resources. Instead, the end node is supposed to start a procedure to release the resources. The following text can be added at the end of Section 4: If node E fails to allocate the protection resource, it MUST send a message to notify node A (see Section 5.5). Then, node A will stop bridging and selecting the traffic to/from the protecting LSP and proceed with the procedure of removing the protection allocation according to the APS protocol. 5. GMPLS Signaling Extension for SMP The following subsections detail how LSPs using SMP can be signaled in an interoperable fashion using GMPLS RSVP-TE extensions (see RFC 3473 [RFC3473]). This includes: As the first sentence is constructed, the "This" in the second sentence doesn't have a clear referent. The most plausible referent is the GMPLS RSVP-TE extensions, but those do not "include" point (5) in the following link, since the extensions aren't directly involved in activation. I think the sense would be improved if "This includes" was replaced by "This signaling [or method] system enables". [JR] It will be corrected as you suggested. Thanks. 5.1. Identifiers The LSP ID, however, MUST be different to distinguish between the protected LSP carrying normal traffic and the secondary LSP. You probably want to omit "carrying normal traffic" as it's not clear what "normal" traffic is from the preceding text in the document. It seems that it could only mean "traffic being carried by a protected LSP", and in that case it's redundant. Although perhaps "normal traffic" is a known term. [JR] The term came from the other SDO's language. "carrying normal traffic" will be omitted as you suggested. In the meantime, there are a few other places where "normal traffic" is used. They will be corrected. 5.3. Signaling Secondary LSPs Support for extra traffic in SMP is for further study. Therefore, mechanisms to set up LSPs for extra traffic are also for further study. In the second sentence, you probably want to use the conventional phrase "are outside the scope of this document" in place of "are also for further study". [JR] It will be corrected as you suggested. 5.4. SMP Preemption Priority In SMP, the Setup and Holding priorities in the SESSION_ATTRIBUTE object can be used by GMPLS to control LSP preemption, but, they are not used by the APS to resolve the competition among multiple protecting LSPs. This is probably clear to people who fully understand all of these protocols. But naively, I see that in SMP, GMPLS does not do LSP preemption. Then the interpretation is that GMPLS distributes the Setup and Holding priorities, which APS then uses to resolve competition that arises during preemption. But the last clause states that APS does not use those priorities. I suspect that "In SMP, ... can be used by GMPLS to control LSP preemption" doesn't mean what I think it does (that is, control how APS does preemption). Perhaps there is a better way of phrasing it. [JR] Indeed, the current text is miswritten and misleading. "In SMP," should be removed. When resource competition among multiple protecting LSPs occurs, the APS protocol will use their priority values to resolve the competition. Since this section introduces the priority field, it's worth stating here "A lower value has a higher priority." or appending "..., with a lower value indicating a higher priority.". [JR] Yes, the sentence you suggested will be added. In SMP, a preempted LSP MUST NOT be torn down. Perhaps "torn down" has a specific meaning, but naively, a preempted LSP has its resources de-allocated, and so is "torn down". I think you could make this clearer as In SMP, a preempted LSP MUST NOT be torn down even after its resources have been deallocated. But perhaps there is a more specific term that could be used instead of "torn down". [JR] I couldn't come up with a more specific term. Maybe a generic term might be used instead as there is an appended phrase. How about the following (I am not sure if "terminate" can be generic here): In SMP, a preempted LSP MUST NOT be terminated even after its resources have been deallocated. 5.5. Notifying Availability of Shared Resources When the shared resources become unavailable, including a case of the shared resources failure, [...] Perhaps clearer as When any shared resources become unavailable for any other reason (e.g. failure of the shared resources), [...] [JR] Please, see my previous comment and text proposal in "Minor technical issue". 5.6. SMP APS Configuration In order to allow exchange of APS protocol messages, an APS channel has to be configured between adjacent nodes along the path of the SMP protecting LSP. This should be done before any SMP protecting LSP has been set up by other means than GMPLS signaling which are therefore outside the scope of this document. This is unclear to me. Does "by other means than GMPLS signaling" modify "SMP protecting LSP has been set up", as it appears to? It seems to me to be likely that the meaning is This is done by other means than GMPLS signaling, before any SMP protecting LSP has been set up. This means is outside the scope of this document. -- Therefore, additional requirements for APS configuration are outside the scope of this document. I think this can be clarified as Therefore, there are likely additional requirements for APS configuration which are outside the scope of this document. [JR] Thank you for the text suggestion. Your text reads better and will be incorporated. 10. Contributor The following person contributed significantly to the content of this document and should be considered as a co-author. This is an unusual statement. Presumably there is a good reason the expedient of listing Yuji Tochio as a co-author has not been taken. [JR] He refused to put his name on the front page. The reason I was told was that there were limits to the extent of his role and participation in different SDOs due to his company's internal policy. [END] -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
