Re: [mpls] Rtgdir last call review of draft-ietf-mpls-ri-rsvp-frr-16

[Chandrasekar Ramachandran <[e-mail]>]

Hi Carlos,
Thanks for the review & apologies for the delay. I have addressed all your review comments in version 17 of the draft.
https://author-tools.ietf.org/iddiff?url2=draft-ietf-mpls-ri-rsvp-frr-17

Thanks,
Chandra.



Juniper Business Use Only

From: Carlos Pignataro via Datatracker <[e-mail]<mailto:[e-mail]>>
Date: Sat, Feb 10, 2024 at 1:35 AM
Subject: [mpls] Rtgdir last call review of draft-ietf-mpls-ri-rsvp-frr-16
To: <[e-mail]<mailto:[e-mail]>>
Cc: <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>, <[e-mail]<mailto:[e-mail]>>


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<https://urldefense.com/v3/__https:/www.rfc-editor.org/materials/abbrev.expansion.txt__;!!NEt6yMaO-gk!CJPlEc8Gdwzu2i7TVLXNQoyassTJIsSfzxBbCCE-0rgmPCtXg0_l8mDkZgA1quHJ4BFLJ9hpz-IR8WTOXBm1$>

   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.


_______________________________________________
mpls mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!CJPlEc8Gdwzu2i7TVLXNQoyassTJIsSfzxBbCCE-0rgmPCtXg0_l8mDkZgA1quHJ4BFLJ9hpz-IR8fGSWcvf$>