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
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.
_______________________________________________
mpls mailing list
mpls@xxxxxxxx
https://www.ietf.org/mailman/listinfo/mpls
|
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
