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]
