IGP Flexible Algorithms Reverse Affinity Constraint
draft-ietf-lsr-igp-flex-algo-reverse-affinity-12
Yes
Gunter Van de Velde
No Objection
Andy Newton
Éric Vyncke
Erik Kline
Gorry Fairhurst
Jim Guichard
Orie Steele
Note: This ballot was opened for revision 06 and is now closed.
Gunter Van de Velde
Yes
Ketan Talaulikar
Yes
Comment (2025-07-04 for -07) Sent
Thanks to the authors and the WG for this straightforward extension for IGP Flex-Algorithm feature. I have a few comments to offer : 1) Even if it is obvious to OSPF implementors, please mention in the introduction section that the term OSPF is used to cover both OSPFv2 and OSPFv3 protocols. 2) Please correct the IANA considerations for OSPF code points to indicate that the allocations done via early allocation process need to be made permanent. 3) Regarding the IGP Flex-Algorithm Path Computation Rules registry, I believe IANA would require a number limit say 1 - 255 to start with? While I agree with Med that "Standards Action" would be a more suitable registration policy, I also understand the authors reasoning for "Expert Review". There is likely a technical oversight/guidance needed in ensuring that the ordering is proper while performing assignments (something that calls for a DE). So, perhaps "Standards Action with Expert Review" is an option to consider?
Mohamed Boucadair
(was Discuss) Yes
Comment (2025-08-01 for -11) Sent
Hi Peter, LSR WG, Thank you for the constructive discussion and addressing my comments in my previous [1]. The changes made since then look good to me [2]. Will leave it to you and Gunter about how to track: * Adding draft-ietf-lsr-flex-algo-bw-con to the update list, once published as RFC * Indicating that “experimental algos/attributes are not related to the calculation rules defined in this registry.” The first point can be addressed as a note to the RFC Editor. Having a note in the registry would make sense for the second point. # Section 13.3: point to the guidance for the guidance: OLD: This document creates a new registry called "IGP Flex-Algorithm Path Computation Rules Registry" within the "Interior Gateway Protocol (IGP) Parameters" registry group. The registration procedure for the new registry is "Expert Review". NEW: This document creates a new registry called "IGP Flex-Algorithm Path Computation Rules Registry" within the "Interior Gateway Protocol (IGP) Parameters" registry group. The registration procedure for the new registry is "Expert Review". Section 12 provides guidance for Designated Experts. Some minor nits spot when reviewing the latest versions: # Section 12 ## OLD: is specified in section Section 13.3 NEW: is specified in Section 13.3 ## OLD: This section provides the guidance for designated expert NEW: This section provides the guidance for designated experts Cheers, Med [1] https://mailarchive.ietf.org/arch/msg/lsr/3iiwRqNN8rmHE0sUHYCHWlLElAU/ [2] https://author-tools.ietf.org/iddiff?url1=draft-ietf-lsr-igp-flex-algo-reverse-affinity-07&url2=draft-ietf-lsr-igp-flex-algo-reverse-affinity-11&difftype=--html
Andy Newton
No Objection
Deb Cooley
No Objection
Comment (2025-06-30 for -07) Not sent
Thanks to PHB for their secdir review
Éric Vyncke
No Objection
Erik Kline
No Objection
Gorry Fairhurst
No Objection
Jim Guichard
No Objection
Mahesh Jethanandani
No Objection
Comment (2025-07-05 for -07) Sent
Sometime after Section 10, paragraph 6 Peter, I read your response to Med's DISCUSS about not having any text around possible operational considerations. Thank you for sharing your perspective. While I appreciate your emphasis on the primary role of RFCs in ensuring interoperability, I believe it's important to differentiate between protocol interoperability and practical operational deployment. While RFCs are not implementation guides, many IETF documents — especially those introducing new behaviors or influencing protocol dynamics — routinely include Operational Considerations and Guidance to avoid instability, even when they don't strictly define new protocol mechanics. In this draft, the proposed extensions indirectly influence routing behavior, as they alter inputs that affect path computation. Regardless of whether new attributes are defined, modifying the use or semantics of existing ones (such as Extended Administrative Groups) for novel use cases can create new operational risks, especially when dynamic updates are driven by live network conditions (e.g., CRC error thresholds). RFCs like [RFC 8570] (or others you may want to cite) provide examples where operational guidance was added to maintain network stability even when only existing mechanisms were reused in new contexts. Having an implementation at hand should enable the authors to write this up, including, if true, that there are no additional considerations to be had by including the reverse path. ------------------------------------------------------------------------------- NIT ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. "Introduction", paragraph 1 > 50] allows IGPs to compute a constraint-based paths. Several mechanisms to in > ^^^^^^^^^^^^^^^^^^^^^^^^ The plural noun "paths" cannot be used with the article "a". Did you mean "a constraint-based path" or "constraint-based paths"?
Orie Steele
No Objection
Paul Wouters
No Objection
Comment (2025-07-07 for -07) Sent
note please remove or complete the 13. Acknowledgements Section, instead of having it as TBD.
Roman Danyliw
(was Discuss) No Objection
Comment (2025-07-28 for -10) Sent
Thank you for addressing my DISCUSS and COMMENT feedback.