Reviewer: Carlos Pignataro Review result: Has Nits Hi, Please find below the Routing Area Directorate (rtgdir) review for draft-ietf-mpls-ri-rsvp-frr-16. Review of draft-ietf-dnsop-dns-error-reporting Type Last Call Review Team Routing Area Directorate (rtgdir) Deadline 2024-02-14 Reviewer Carlos Pignataro I'll be happy to provide further clarifications or provide text as appropriate. I hope these are useful and clear. More Substantive: This is a very useful and clearly written document. The only potentially substantive review comment is that there are a number of lowercase "should" in the document, which might (or might not) be best served with uppercase "SHOULD". A suggest a review of those. And in this context, I wonder if a reference to RFC 8174 would also help. More Editorial: Please find some nits and editorial suggestions: RSVP-TE Fast ReRoute extensions specified in RFC 4090 defines two local repair techniques to reroute Label Switched Path (LSP) traffic over pre-established backup tunnel. CMP: "The RSVP-TE Fast Reroute ..." CMP: Note the FRR abbreviation expansion at https://www.rfc-editor.org/materials/abbrev.expansion.txt RI-RSVP-FRR: The set of procedures defined in this document to elimiate RSVP's reliance of periodic message refreshes when supporting facility backup protection [RFC4090] CMP: "eliminate" FRR [RFC8796] that enables the PLR to signal the availability of local protection to the MP. In addition, introduce PLR and MP procedures to to establish Node-ID based hello session between the CMP: "to to" -> "to" If the M-bit is set to 0, then the PathTear message MUST be processed processed as a normal PathTear message for the LSP. CMP: Repeated "processed" to the MP. The MP MUST delete the states corresponding to the LSP also also propagate the PathTear downstream thereby achieving state CMP: Repeated "also" "Refresh interval Independent FRR" or RI-RSVP-FRR refers to the set of procedures defined in this document to elimiate the reliance of periodic refreshes. The extensions proposed in RSVP-TE Summary FRR CMP: "eliminate" - As nodes supporting the RI-RSVP-FRR extensions initiate Node-ID based signaling adjacency with all immedate neighbors, such a node on the path of a protected LSP can determine whether its Phop and Nhop neighbors support RI-RSVP-FRR enhancements. CMP: "immediate" - If node protection is requested for the LSP and the Phop node along the LSP path does not support the RI-RSVP-FRR extensions, then the the node MUST reduce the "refresh period" in the CMP: Duplicate "the the" - Intead of node B, assume node C does set RI-RSVP capability in its Node-id based Hello messages even though it does not support RI- CMP: "Instead" RFC 2961 specifies mechanisms to eliminate the reliance on periodic refresh and refresh timeout of RSVP messages, and enables a router to increase the message refresh interval to values much longer than the default 30 seconds defined in RFC 2205. CMP: Remove comma before "and" Procedures specified in [RFC2961] address the above mentioned problems by eliminating dependency on refreshes for state synchronization and for recovering from lost RSVP messages, and by eliminating dependency on refresh timeout for stale state cleanup. CMP: "above-mentioned" The procedures specified in this document assume reliable delivery of RSVP messages, as specified in [RFC2961]. Therefore this document makes support for [RFC2961] a pre-requisite. CMP: "Therefore, " As the link on C, over which the LSP states are refreshed, has failed, C will no longer receive state refreshes. Consequently the protected LSP states on C will time out and C will send the tear down messages for all LSPs. CMP: "Consequently, " I hope these help and are clear and useful. Thanks! Carlos. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
