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.