Refresh-interval Independent FRR Facility Protection
draft-ietf-mpls-ri-rsvp-frr-22
Yes
Jim Guichard
No Objection
Erik Kline
Murray Kucherawy
Orie Steele
Paul Wouters
Note: This ballot was opened for revision 17 and is now closed.
Gunter Van de Velde
Yes
Comment
(2024-05-23 for -18)
Sent
# Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-ri-rsvp-frr-18 Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/ documenting the handling of ballots. #GENERIC COMMENTS #================ ## This draft is well written and provides a good context and details of the problem space, procedures and technologies. Only few non blocking COMMENTS for consideration. #DETAILED COMMENTS #================= 253 In the topology in Figure 1, let us consider a large number of LSPs 254 from A to D transiting B and C. Assume that refresh interval has 255 been configured to be long of the order of minutes and refresh 256 reduction extensions are enabled on all routers. 258 Also let us assume that node protection has been configured for the 259 LSPs and the LSPs are protected by each router in the following way suggested a small rewrite to make te text sound more procedural and avoids the word 'us': "In the topology depicted in Figure 1, consider a significant number of LSPs (Label Switched Paths) from node A to node D, transiting through nodes B and C. Assume that the refresh interval is set to be relatively long, on the order of minutes, and that refresh reduction extensions are enabled on all routers. Additionally, assume that node protection has been configured for these LSPs. Each router protects the LSPs in the following manner: " 368 However, if a node supporting facility backup 369 protection [RFC4090] does set the RI-RSVP capability (I bit) but does 370 not support all the extensions specified in the rest of this 371 document, then it leaves room for stale state to linger around for an 372 inordinate period of time given the long refresh intervals 373 recommended by [RFC8370] or disruption of normal FRR operation. WHat about following rewrite for this text blob: "However, if a node that supports facility backup protection [RFC4090] sets the RI-RSVP capability (I bit) but does not support all the extensions specified in this document, it may result in lingering stale states due to the long refresh intervals recommended by [RFC8370]. This can also disrupt normal Fast Reroute (FRR) operations. " 1100 All assignments in this sub-registry are to be performed via 1101 Standards Action. Would "IETF Review" not be a better less restrictive fit for the IANA assignment procedure? https://www.rfc-editor.org/rfc/rfc8126.html#section-4
Jim Guichard
Yes
Deb Cooley
No Objection
Comment
(2024-05-24 for -18)
Sent
1. FIPS 180 has been up issued in 2015: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf . 2. Security Considerations: "When using RSVP Cryptographic Authentication [RFC2747], more robust algorithms [RFC2104] [FIPS-180-3] SHOULD be used when computing the keyed message digest where possible." This sentence is confusing to me. a. It would seem like the 'SHOULD' should be a 'MUST'? RFC2747 uses HMAC-MD5 which is well beyond its end of life, or HMAC-SHA1, which isn't deprecated yet, but NIST has plans to deprecate. b. In addition, the position of the references to RFC 2104 and FIPS 180 in the sentence adds to the confusion - I would suggest moving them to the end of the sentence. 3. general, and only because there is another comment on this: 'let us assume' is commonly used in mathematical proofs. However, I have no idea how common it is in the IETF RFCs, much less routing RFCs.
Erik Kline
No Objection
John Scudder
(was Discuss)
No Objection
Comment
(2024-06-27 for -21)
Sent
Thanks for your reply to my DISCUSS position. My remaining comments are captured in my reply to the DISCUSS thread, at https://mailarchive.ietf.org/arch/msg/mpls/Rq-FM8gtjky3rEbYB_EPs7AjTWo/
Murray Kucherawy
No Objection
Orie Steele
No Objection
Paul Wouters
No Objection
Roman Danyliw
(was Discuss)
No Objection
Comment
(2024-06-12 for -20)
Sent
Thanks to Reese Enghardt for the GENART review. Thank you for addressing my DISCUSS and COMMENT feedback.
Warren Kumari
No Objection
Comment
(2024-05-29 for -18)
Sent
Thank you very for writing this document - it solves an important operational issue in a clean and elegant manner. I don't have anything to add, other than supporting John Scudder's DISCUSS and also thanking him for such a comprehensive review...
Zaheduzzaman Sarker
No Objection
Comment
(2024-05-29 for -18)
Not sent
Thanks for working on this specification. I have no issues here from transport protocol point of view.
Éric Vyncke
No Objection
Comment
(2024-05-26 for -18)
Sent
# Éric Vyncke, INT AD, comments for draft-ietf-mpls-ri-rsvp-frr-185 Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Nicolai Leymann for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. *BUT* is it completely outdated as it contains `Deborah Brungard is the Responsible Area Director`.... I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Please fix the ID-NITS RFC 3936 is in the reference but I cannot find a use of this reference in the text... ## Section 4.2.1 Was `RRO` defined before ? ## Section 4.4.3 s/and should be set to eight./and MUST be set to eight./ ? Plus add some text about the receiver procedure when length is different than 8.