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]
