Hi Tony,
> otherwise yes, people can have different preferred ponies based on the > requirements driving their topology/solution space and that speaks for > relevance of different algorithms and/or signalling approaches. But to be > precise, it does not necessarily imply that people or the WG should care > about multiple algorithms/signalling at the same time on the network ;-) (as > footnote: anyone who wants to migrate from one algorithm/version to another > node-by-node w/o first disabling the first algorithm everywhere will however > end up in the "multiple algorithms at same time on network"). I strongly disagree. Anyone using any type of flooding reduction algorithm needs to understand that complex algorithms and implementations can and will have bugs. To assert otherwise, is simply an act of extreme and unprecedented hubris. An operator with a buggy algorithm or implementation may very much want to migrate to a new algorithm and we need to have a way to make that possible. Always reverting back to full flooding is a nice dream, but in a sufficiently dense network, that may not be possible. The flooding load may simply overwhelm the control plane without some form of flooding reduction. As a result, we need to be able to change algorithms, preferably during a maintenance window. >> 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? > > hmm, first comment I get it's unreadable so as kernel of the thing; in simple > terms the draft says that algorithms/signalling can be arbitrarily mixed > (again, if the need even arises) and will gurantee flooding coverage as long > they are "prunners" which are 2 required straight-forward properties: > > 1. any node running flood reduction needs to either advertise that it is > "configured to run an algorithm" or "is running a certain algorithm" so other > nodes know what they participate or can participate in. > 2. any adjacency with a different configured or running algorithm on the > other side needs to be fully flooded > > obviously within the "component", i.e. e'one signalling same algorithm the > algorithm MUST guarantee flooding coverage (CDS) > > obviously AFAIS again, if a node violates 1. and is not indicating what it is > configured to run or running then we have "ships in the night" and ships in > the night never interoperate. Nodes or leaders "assuming" that nodes support > the algorithm are basically ships in the night which means, a single > algorithm without being a prunner will work fine but it won't mix (and again, > assuming we even care about presence of multiple algorithms/signalling > running at same time in the network). > > Since you mention specific drafts, I don't really want to drag this thread > into solutions since that's a follow up thing depending on consensus here but > AFAIS RFC9667 respin can actually fairly easily include the leaderless mode > with some clarifications (and possibly even w/o adding new sub-TLVs ;-) and > it would be further beneficial since the RFC is underspecified in certain > respects and bears possibly defects as it stands which we can roll up then. > Again, discussion to be had if that's the path the WG starts to pursue and > I'm happy to suggest a strawman of necessary changes then. I’ll take that as a ‘no’. That’s unfortunate. Ok, we will be having a much longer discussion. T
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
