[speaking as WG participant] Hi Acee, All,
The current draft needs some work to be better readable. It is a non-trivial read. I am convinced that when there is consensus to develop the leaderless solution that this can be worked out accordingly. In my opinion, the greatest advantage of a leaderless technology architecture is its operational simplicity, particularly because it eliminates the need for a coordinated transition or "flag day." A few benefits I see from a leaderless approach: * Enhanced Redundancy: Multiple nodes participate in flooding, reducing the risk associated with any single node failure. * Simpler Protocol Design: Eliminates the need for leader election and maintenance mechanisms, simplifying the protocol implementation. * Better Scalability: Distributes the processing load across multiple nodes, preventing bottlenecks. * Faster Convergence: Avoids delays associated with leader re-election, enabling quicker dissemination of routing updates. Some concerns I see with a flooding leader approach: * Single Point of Failure (the flooding leader becomes a critical component in the network. If the leader fails or becomes unreachable, it can disrupt the flooding process until a new leader is elected or the network converges to an alternative state) * Increased Complexity (Implementing a flooding leader requires additional mechanisms for leader election, maintenance, and failure detection) * Scalability Concerns (in large-scale or highly dynamic networks, managing a single flooding leader can become a bottleneck) * Convergence Delays (when the flooding leader fails, the network must initiate a leader re-election process) * Lack of Redundancy (relying on a single leader reduces redundancy in the flooding process) * Overhead of Leader Maintenance (continuous monitoring is required to ensure the flooding leader is operational) * Potential for Suboptimal Flooding Paths (the flooding leader may not always have the most efficient paths to all nodes, especially in dynamic topologies) * Complex Recovery Mechanisms (recovering from leader failures may involve complex procedures that differ from standard link-state protocol operations) I believe there is place for both a flooding leader and leaderless architecture. It depends upon type of network where this is implemented (for example Datacenter or Service Provider WAN). Be well, G/ From: Acee Lindem <[email protected]> Sent: Monday, November 18, 2024 3:40 PM 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" CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. 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]
