[speaking as WG participant] Inline: GV>
From: Les Ginsberg (ginsberg) <ginsberg=40cisco....@dmarc.ietf.org> Sent: Tuesday, November 19, 2024 7:59 PM To: Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com>; Acee Lindem <acee.i...@gmail.com>; lsr <lsr@ietf.org> Subject: RE: [Lsr] Re: 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. Gunter – I would probably disagree with just about every bullet point you have below. 😊 GV> I expected nothing else 😊 GV> The explicit question raised by Acee was “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. ” GV> My answer (as participant) is “yes, we should”. But that discussion is premature. IMO what we need to agree on now is: 1)We do want to have a discussion on leader/leaderless 2)Such discussion should take place independent of any specific algorithm 3)If we agree on the above, then the distoptflood draft needs to be updated to be agnostic to the enablement mode. GV> This was not asked in this consensus call. At this stage it sounds premature to discuss. I personally have no strong preference for separate documents or a single document. There are pro’s and con’s for each approach. Once that is agreed upon we need to decide on a context (AKA draft) in which this discussion could take place. A suggestion has been made that this could be done as an update to RFC 9667 – I like that idea. But there are other ways this could be done as well. But I would like us to agree on the three points above first before diving inot the technical discussion. GV> My feeling (as participant) is that a reasonable first step would be to understand if the WG find consensus to work on a leaderless architecture or not. If the WG decide it is not feasible, then the discussion ends and we should stop spending time on the subject. G/ Les From: Gunter van de Velde (Nokia) <gunter.van_de_velde=40nokia....@dmarc.ietf.org<mailto:gunter.van_de_velde=40nokia....@dmarc.ietf.org>> Sent: Tuesday, November 19, 2024 10:35 AM To: Acee Lindem <acee.i...@gmail.com<mailto:acee.i...@gmail.com>>; lsr <lsr@ietf.org<mailto:lsr@ietf.org>> Subject: [Lsr] Re: 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" [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 <acee.i...@gmail.com<mailto:acee.i...@gmail.com>> Sent: Monday, November 18, 2024 3:40 PM To: lsr <lsr@ietf.org<mailto:lsr@ietf.org>> 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 -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
