I support adoption of this draft.
This is a useful extension to the tools available for flex-algo.
A couple of comments:
1)Section 4 states:
" 3. Flapping suppression: If frequent changes in the IGP-
advertised link packet loss rate are detected, a timer can be
implemented to delay the update process, thereby stabilizing the
routing computation."
I think this is an inappropriate suggestion. As is discussed in RFC 8570
(Sections 5 and 6) , it is the responsibility of each node to ensure that
advertisements of any of the link attributes defined there are "well behaved".
Link loss is not special in this regard.
If this is violated, I would think a more appropriate response on the part of
receivers would be to ignore the updates for that particular attribute - not to
negatively impact the responsiveness of the implementation to all SPF triggers.
2)It seems that the authors have chosen to "squat" on an IS-IS codepoint
(Section 5.1). Please do not do that.
Once the document becomes a WG document, you will then be eligible for early
allocation of a codepoint using the procedures defined in RFC 7370.
Les
>-----Original Message-----
>From: Acee Lindem <[email protected]>
>Sent: Friday, May 29, 2026 8:03 AM
>To: lsr <[email protected]>
>Cc: [email protected]
>Subject: [Lsr] WG Adoption Call for "IGP Flexible Algorithm with Link Packet
>Loss" - draft-wang-lsr-flex-algo-link-loss-05
>
>LSR WG,
>
>
>This begins the LSR WG Adoption Call for "IGP Flexible Algorithm with Link
>Packet Loss" - draft-wang-lsr-flex-algo-link-loss-05. Please indicate your
>support of objection on this list by Saturday, June 13th, 2026.
>
>Thanks,
>Acee
>
>
>_______________________________________________
>Lsr mailing list -- [email protected]
>To unsubscribe send an email to [email protected]
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
