Hi Tony,
> On Feb 6, 2024, at 7:43 PM, Tony Li <[email protected]> wrote:
>
> Thank you for your fantastic comments. Please see inline.
You’re welcome and thank you for your careful reply, and also for the
additional polishing. I’ve just reviewed the diff, it looks good. Just a few
things to note in the revision, below.
—John
### Section 5.1.1
• 1-127: Standardized distributed algorithms. Individual values are to
be assigned according to the "Specification Required" policy defined in
[RFC8126] (see Section 7.3).
But in 7.3 you’ve changed the policy to Expert Review. I suggest deleting the
conflicting sentence here, so,
NEW:
• 1-127: Standardized distributed algorithms.
On the basis that it’s better to have a single source of truth when possible.
It would also be OK to update the conflicting text, though.
### Section 5.1.2
2. Indicate the set of algorithms that it supports, if any.
But since you pointed out that "6.4 prohibits zero algorithms”, can’t “if any”
be deleted since there must always be at least one?
### 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
