[Lsr] Re: Mahesh Jethanandani's No Objection on draft-ietf-lsr-igp-flex-algo-reverse-affinity-07: (with COMMENT)

[Peter Psenak <[e-mail]>]

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

>
>
>
>