Acee –
Thanx for starting this discussion.
I think having an open discussion about leaderless election is a good and
necessary thing.
But not in the context of a specific algorithm.
I think the points “casually mentioned” in support of leaderless:
a)Easier to deploy
b)Addresses the “blast radius” problem
don’t stand up to scrutiny.
But that’s part of the discussion we need to have – and it isn’t specific to a
particular algorithm.
So separating this discussion from the disoptflood draft is essential to my
thumbs up vote.
Les
From: Acee Lindem <[email protected]>
Sent: Monday, November 18, 2024 6:40 AM
To: lsr <[email protected]>
Subject: [Lsr] Consensus Call on LSR WG work on "Leaderless Flooding Algorithm
for Distributed Flood Reduction to allow reduced configuration, minimal blast
radius, and ease of incremental deployment"
During the IETF 121 LSR meeting, we had a very good discussion of
https://datatracker.ietf.org/doc/draft-ietf-lsr-distoptflood/
While the CDS flooding reduction algorithm itself was interesting, the main
area of the discussion was distributed flooding reduction algorithm selection
and its configuration and deployment.
Today, we have RFC 9667 “Dynamic Flooding on Dense Graphs” which provides
leader-based supporting both centralized and distributed flooding reduction
algorithm selection. With the mechanism, an area leader is selected from among
the OSPF routers in the area supporting flooding reduction and this leader
selects the flooding reduction algorithm for the area.
The question to be answered by this consensus call is whether or not we want to
work on an additional mechanism just for distributed flooding reduction to
allow for reduced configuration, minimal blast radius, and ease of incremental
deployment.
Please send your support or opposition to this list before Tuesday, December
3rd.
As WG Co-Chair,
Acee
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
