Hi Mahesh,
thanks for your comments, please see inline (##PP):
On 06/07/2025 06:57, Mahesh Jethanandani via Datatracker wrote:
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.
##PP
I know many RFCs do these days, the question is whether that is
something that the RFC should/must do.
I have shared my perspective on that.
I have agreed to add some simple text around the stability aspect, but
IMHO what this draft introduces
is no different to any other link attribute that IGPs are flooding and
using for calculation. And any
reasonable implementation has the protection against too frequent
changes in these, that is not necessarily attribute specific.
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"?
it's the latter, I fixed it.
thanks,
Peter
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
