Hi Tony, > On Apr 28, 2025, at 7:29 PM, Tony Przygienda <[email protected]> wrote: > > > > On Mon, Apr 28, 2025 at 7:48 PM Acee Lindem <[email protected]> wrote: > Speaking as WG member: > > I support adoption. > > thanks Acee > > > I do think draft terminology could be improved. > > Despite the risk of confusion with AI-based landscaping, I've resigned myself > to you using "pruner". > However, for a node that is not preforming any flooding reduction, this > should be a "non-pruner" rather than > a "zero-pruner" or, worse yet, "zero". > > "non-prunner" I think is OK a term we could go with if people think that > makes it more readable than "zero prunner". > > We can even move away from "pruner" for this class of algorithms if someone > has a significantly better term that crosses their minds. > > Additionally, I think the term "connected set" for a group of routers running > the same flooding reduction algorithm > is a poor choice. You say these are "colloquially often" called "flooding > topologies" which is exactly what they > should be called. If we're going to come up a clever term, I'd suggest "Flood > Uniform Clique" since the routers > in one such grouping can reduce their LSP advertisement without regard to > what is being done in another such > grouping. > > Those are not "clever" terms. Those are terms used for many, many years in > graph theory and describing "precisely" what the "thing" has to be to work. > Also, clique is a term used in the context of graphs and means something > rather different than a "connected component".
The alternate term wasn't really serious. > > AFAIS nothing prevents people from calling the stuff "flooding topology" of > course as long we have a framework in place making it clear that means a > "edge dominating set allowing cycles/loops" rather than having later to > discuss in future in context of subtle algorithms what a "flooding topology" > really is. Hence the document spells that stuff out. > > > Finally, I don't see the need to optimize the output to the non-ASCII test > format when this is not > the default you get when the draft is displayed in the datatracker - > https://datatracker.ietf.org/doc/draft-ietf-lsr-distoptflood/ > > I fail to read your point somehow here. You mean an ASCII figure showing this > is necessary. Yes, work item to do once draft adopted of course. I think the embedded markup is more of a problem than the figure since readers are more used to complex figures being omitted. Thanks, Acee > > -- tony > > > Thanks, > Acee > > > On Apr 27, 2025, at 10:39 AM, Acee Lindem <[email protected]> wrote: > > > > LSR WG, > > > > This starts the Working Group adoption call for > > draft-prz-lsr-interop-flood-reduction-architecture-01. Please send your > > support or objection to this list before Monday, May 12th, 2025. > > > > Thanks, > > Acee > > > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
