Dear WG, > For some of us, discussing enablement mechanisms in the context of a specific flooding algorithm is nonsensical.
No so fast ... I think when we are discussing this we need to consider two fundamental approaches to run your flooding in link state protocols Approach A - Fully automated Approach B - Configuration driven Approach A - in band - is what leader election and algorithm push by elected leader(s) suggest. Approach B - out of band - Example: Netconf push which algorithm should be used by all nodes (analogy to today's mesh groups) I think operators are comfortable with B today. Sure you can compare a leader election to DIS election, but recognizing how many people run ISIS on p2mp media today does not look like sound justification. I am of the opinion that ideally each proposed flooding reduction algorithm should provide in the draft/RFC approach B (and attach YANG model with it). For approach A that seems independent work which could go on in parallel. Thx, R. On Wed, Nov 20, 2024 at 12:04 AM Les Ginsberg (ginsberg) <ginsberg= [email protected]> wrote: > Gunter – > > > > For some of us, discussing enablement mechanisms in the context of a > specific flooding algorithm is nonsensical. > > While you are correct that Acee did not mention this is his original post, > it has been highlighted by several of us as a key constraint in our > (otherwise supportive) responses. > > Please do not ignore this. > > > > Les > > > > *From:* Gunter van de Velde (Nokia) <gunter.van_de_velde= > [email protected]> > *Sent:* Tuesday, November 19, 2024 11:52 AM > *To:* Les Ginsberg (ginsberg) <[email protected]>; Acee Lindem < > [email protected]>; lsr <[email protected]> > *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" > > > > [speaking as WG participant] > > > > Inline: GV> > > > > *From:* Les Ginsberg (ginsberg) <[email protected]> > *Sent:* Tuesday, November 19, 2024 7:59 PM > *To:* Gunter van de Velde (Nokia) <[email protected]>; Acee > Lindem <[email protected]>; lsr <[email protected]> > *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) < > [email protected]> > *Sent:* Tuesday, November 19, 2024 10:35 AM > *To:* Acee Lindem <[email protected]>; lsr <[email protected]> > *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 <[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] >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
