Mohamed Boucadair has entered the following ballot position for draft-ietf-lsr-igp-flex-algo-reverse-affinity-07: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-flex-algo-reverse-affinity/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 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 on revere metric such as 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 routine table. However, the document does not discuss such implications, does not include guards to avoid frequent reverse link updates, does not provide a guidance about how/when it is safe to make an update, does not discuss relevant configuration matters. Worse, the document does only include an example (as part of 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? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # 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 _______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
