Mahesh Jethanandani has entered the following ballot position for draft-ietf-lsr-igp-flex-algo-reverse-affinity-07: No Objection
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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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"? _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
