Ballot for draft-ietf-lsr-igp-flex-algo-reverse-affinity
Discuss
Yes
No Objection
No Record
Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
Hi Peter, Jakub, and Amit, Thank you for the effort put into this specification. I was surprised that the document does not cite "similar" work such as revere metric defined in RFC8500 and RFC9339. I'm not saying this is identical, but there are similarities that are worth to acknowledge. Please find below some points that I think need to be discussed. # Stability & Lack of Operations Considerations The activation of the attributes defined in this document may have implications on the stability of the routing table. However, the document does not discuss such implications, does not include guards to avoid frequent reverse link updates, does not provide guidance about how/when it is safe to make an update, and does not discuss relevant configuration matters. Worse, the document does (only) include an example (as part of a use case) about how an operator can decide to trigger such message which relies on a threshold-based approach: Section 3: An operator might monitor metrics like CRC errors or other input-related faults at node B and apply thresholds over a defined observation period. If such a threshold is exceeded, node B may locally assign specific Extended Administrative Groups to the link in the direction from B to A. Absent robust hysteresis, it is risky to use such threshold-based approach as this may lead to instability. FWIW, draft-ietf-nmop-terminology rightfully warrant against issues that might be induced by threshold-based schemes: The use of threshold-driven Events and States (and the Alerts that they might give rise to) must be treated with caution to dampen any "flapping" (so that consistent States may be observed) and to avoid overwhelming management processes or systems. Please consider adding a discussion to cover these matters. At minimum, a reminder of the considerations in rfc9350#section-15 should be included. I suggest you also look at rfc8500#section-3.5, rfc9339#section-7, and rfc9339#section-8 to see to what extent the ops considerations discussed out there are relevant in this specific context. # IGP Flex-Algo Path Computation Rules Registry Unless I’m mistaken, this registry is not specific to this specification. What is the rationale for adding this registry here? How this registry is intended to be used/maintained? Why “Expert Review” is picked as policy for this registry, while all the steps were/are defined in PS documents? Are DEs allowed to delete/modify/merge/reorder steps? What are the implications on already specified metrics?
# Illustration examples
Consider adding some examples to illustrate the intended use.
# Sections 4/5: Simplify as the types are already assigned.
OLD:
Type (1 octet): An 8-bit field assigned by IANA to uniquely
identify the ISIS FAERAG Sub-TLV. Value 10 has been assigned by
IANA.
NEW:
Type (1 octet): 10
OLD:
Type (2 octets): A 16-bit field assigned by IANA to uniquely
identify the OSPF FAERAG Sub-TLV. Value 10 has been assigned by
IANA.
NEW:
Type (2 octets): 10
# Section 11.1: Use the correct name of the IANA registry + indicate the registry group
OLD:
IANA has assigned the following Sub-Sub-TLVs in the "ISIS Sub-Sub-
TLVs for Flexible Algorithm Definition Sub-TLV" registry:
NEW:
IANA has assigned the following Sub-Sub-TLVs in the " IS-IS Sub-Sub-TLVs
for Flexible Algorithm Definition Sub-TLV" registry under “IS-IS TLV Codepoints”
registry group:
# Section 11.2: Use the correct name of the IANA registry + indicate the registry group
OLD:
IANA has assigned the following Sub-TLVs in the "OSPF TLVs for
Flexible Algorithm Definition TLV" registry:
NEW:
IANA has assigned the following Sub-TLVs in the " OSPF Flexible
Algorithm Definition TLV Sub-TLVs" registry under “Open Shortest Path First (OSPF) Parameters”
registry group:
# Section 11.2: nit
OLD: Description: Flexible Algorithm Include-All ReverseAdmin Group
NEW: Description: Flexible Algorithm Include-All Reverse Admin Group
Cheers,
Med
** Section 11.3 This section creates a new registry with an “expert review” review registration policy but does not provide any guidance on the criteria the expert(s) should use.
** Section 11.3 The "IGP Flex-Algo Path Computation Rules Registry" specifies the ordered set of rules that MUST be used to prune links from the topology during the Flex-Algorithm path computation. Consider if the RFC2119 language needs to be here. This section shouldn’t specify protocol behavior.
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?
Thanks to PHB for their secdir review
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"?
note please remove or complete the 13. Acknowledgements Section, instead of having it as TBD.