Unsurprisingly, I'm in support of working on leaderless signalling option based on requirements provided by a set of large operators and I hope other voices from the previous thread supporting the need for it will chime in this official thread here again. Ideally, several operators on the sidelines that were involved in discussions outside the WG context regarding requirements will choose to speak up as well.
When/if the consensus here is declared to work on leaderless signalling, I think the document framework can be discussed further and multiple options to progress such work exist which can be outlined from my perspective. As to correctness of leaderless/leader based/any signalling I refer to draft https://datatracker.ietf.org/doc/draft-lsr-prz-interop-flood-reduction-architecture/ and until a counter example is provided (or the assumptions therein challenged) the solution should allow to support a generic framework with mix of algorithms and signaling schemes (if such a need even arises) as long every node indicates what it is configured to do or runs. As to "optimal" flooding reduction, this is largely a rathole IMO. Any CDS will basically generate the same amount of copies (which is what we optimize for primarily IMO) and arguing that a certain CDS is better than "another" CDS will lead to all kind of discussions about speed of replication depending on fanout, CPU vs. bandwidth weighting and ultimate resiliency against temporary CDS partitioning in case of node failures. We had discussions behind the scenes to e.g. take into account link BW when computing the graph, however it seems that beside causing very significant amount of computation, especially on link failures (and I don't think FRR for flood reduction is a good idea BTW ;-) such optimizations are hard to quantify. Throw into the mix different configurations/dynamic flooding speeds per link for fast flooding and we basically have NP hard entertainment on our hand of barely any practical, pragmatic value. thanks --- tony On Tue, Nov 19, 2024 at 9:06 AM <martin.hornef...@telekom.de> wrote: > Hello everyone, > > yes, I do support the discussion and development of a leaderless option. > > As an operator I see this as the only chance to get an automatic flooding > optimization into our network. > > While reduced configuration, minimal blast radius, and ease of > incremental deployment are key points for this, I’d also add complexity of > the additions to the existing protocol(s) - e.g. more TLVs and sub-TLVs - > and the need for additional state in the routing protocol as serious > obstacles to implementing anything based on RFC 9667. In our network, > this situation has even worsened since last year after a couple of IGP > related incidents. > > Best regards, Martin > > > Von: Acee Lindem <acee.i...@gmail.com> > Datum: Montag, 18. November 2024 um 15:42 > An: lsr <lsr@ietf.org> > Betreff: [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 -- lsr@ietf.org > To unsubscribe send an email to lsr-le...@ietf.org >
_______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
