Hi Tony and all, On rereading my comments about Section 6.7, it occurred to me that I ignored distributed mode. I can see that in that mode, the concept of "old" and "new" topology does make sense, isn't hard to nail down, and in that context, paragraph two makes sense. My comments continue to apply to centralized mode, though.
Thanks, --John > On Feb 6, 2024, at 8:52 PM, John Scudder <[email protected]> > wrote: > > ### Section 6.7 > > I had asked about old vs. new topologies. Your new version has this: > > In centralized mode, transient conditions with the Area Leader's set > of advertisements may cause multiple flooding topologies to be > advertised concurrently. In this case, nodes SHOULD flood on each of > these topologies until the transient condition is resolved. > > When the flooding topology changes on a node, either as a result of > the local computation in distributed mode or as a result of the > advertisement from the Area Leader in centralized mode, the node MUST > continue to flood on both the old and new flooding topology for a > limited amount of time. This is required to provide all nodes > sufficient time to migrate to the new flooding topology. > > In centralized mode, a node doesn't need to distinguish between the > old and new flooding topologies. As updated information comes in, it > can be added to the existing flooding topology. As old information > is replaced by subsequent updates, it can be removed, thereby > converging to the new information. > > In the first quoted paragraph, you tell me that in centralized mode there can > be multiple concurrent topologies. But then in the third paragraph, you tell > me I don't need to care about distinguishing between them. In that case, why > are we even talking about them? Also, I still don't think I know how to > distinguish between them (although I guess that's OK because the third > paragraph tells me I don't have to). > > If the third paragraph is the bottom line, can't the second paragraph be > deleted? And can't the first paragraph be rewritten considerably? This whole > thing reads like an artifact of some long-ago working group debate, or debate > between the authors, that was resolved as "just flood over whatever topology > you currently know, it will sort itself out, it’s an eventually-consistent > protocol”... which is what you would do if none of these paragraphs existed > at all, and you were just implementing the spec as written, without trying to > exercise creativity. > > If the point of these paragraphs is what I’ve guessed above, I wonder if it > would be better to rewrite them without talking about “old” and “new” > topology since those are not discrete things we can even nail down. Something > along the lines of, “At any given time, a node's concept of the flooding > topology may be in flux, due to the receipt of updates from the Area Leader > adding or removing links from the flooding topology. A node need not take any > special action, but should flood according to its current view of the > flooding topology." _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
