So, this is exactly why the current content of the draft, which combines both the definition of a flooding algorithm with the definition of a new mechanism to control which algorithm(s) are used is problematic.
Regarding the new control mechanism, my opinion is much the same as Tony Li - I think it is problematic. Acee - it seems that you feel otherwise. But I suspect all three of us can agree that the new flooding algorithm (defined in Section 2 of the draft) is something that is desirable. By combining the two into a single draft, the WG is forced to gives a thumbs up/down on both - which is not logical since even the draft itself allows that the algorithm (Section 2) can be deployed by using either the procedures defined in https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/ or by the new procedures defined in Section 1 of this draft. Please give the WG the opportunity to evaluate and progress (or not) these two logically independent elements in separate drafts. Les > -----Original Message----- > From: Tony Li <[email protected]> On Behalf Of Tony Li > Sent: Friday, August 16, 2024 8:06 AM > To: Acee Lindem <[email protected]> > Cc: lsr <[email protected]> > Subject: [Lsr] Re: Consensus Call on "IS-IS Distributed Flooding Reduction" - > draft-ietf-lsr-distoptflood-05 > > > Hi Acee, > > I beg to differ. Without a consistent, uniform algorithm selection, havoc > will > necessarily ensue. The algorithm itself can be distributed. The decision of > which algorithm to use cannot be inconsistent. > > For this reason, I oppose moving forward as the document currently stands. > > Tony > > > > On Aug 16, 2024, at 7:48 AM, Acee Lindem <[email protected]> wrote: > > > > Speaking as WG member: > > > > From a technical standpoint, I don’t have a problem with the addition of the > flooding signaling (though I’m not fond of the prunner/zero prunner > terminology). > > > > The existing area leader election and flooding algorithm selection > (https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/) was > originally targeted at centralized flooding reduction. While it has been made > to > work for distributed flooding reduction, electing an area leader is not > needed. > Rather, the described one-hop signaling is all that is needed to assure > correct > operation and more suited to distributed flooding reduction algorithms. > > > > Thanks, > > Acee > > > >> On Aug 2, 2024, at 2:06 PM, Acee Lindem <[email protected]> wrote: > >> > >> > >> The subject draft was adopted as a WG document containing only the > flooding reduction algorithm (section 2). > >> > >> Procedures and signaling have been added to the current version allowing > concurrent operation within an IS-IS area of IS-IS routers running different > flooding reduction algorithms or no flooding reduction at all (section 1). > >> > >> WG members are questioning if this extra requirement needs to be met and > included in this document. There was an extensive discussion during the IETF > 120 LSR meeting and a MeetEcho show-of-hands poll was taken - > https://notes.ietf.org/notes-ietf-120-lsr > >> > >> Please indicate your preference and reasoning amongst the following > options by August 17, 2024: > >> > >> 1) The document remains in its current form describing both the > >> flooding > reduction algorithm signaling/procedures and the new flooding reduction > algorithm. > >> 2) The flooding reduction algorithm and procedures will be split into a > separate document with its own LSR WG adoption call. > >> 3) Some other resolution? > >> > >> Thanks, > >> Yingzhen, Chris, and Acee (LSR Chairs) > > > > > > _______________________________________________ > > 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] _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
