Hi Tony, Please see inline. I’ve taken the liberty of reordering issues.
> 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. I agree that trying to objectively determine the “optimal” flooding reduction algorithm is a rathole. There are many dimensions that an algorithm can and should be evaluated on. These are articulated in RFC 9667, Section 3. Different networks may place different importance on each of these requirements, so discussing optimality without regard to a given network and management policies would be ultimately fruitless. Rather, it would be good for each algorithm to articulate how it meets each of the requirements listed in that section. > 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. Several points here: 1) The need is present. We have multiple shipping implementations that do not interoperate presently. Networks that adopt any one of them are effectively in a state of vendor lock until we have a selection mechanism. This is an unacceptable situation. 2) I find your draft extremely challenging to read. This is very likely a language issue. 3) Perhaps as a result of point 2, I am still not seeing a mechanism in this draft. I see no signalling whatsoever. 4) Would you be willing to stipulate that two algorithms running simultaneously in the same network without regard to one another is unacceptable, as it is likely to cause gaps in flooding or massive over-flooding? Tony
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
