Re: [Lsr] AD review of draft-ietf-lsr-dynamic-flooding-14

[Tony Li <[e-mail]>]

Hi John,

> 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.


Thanks again for your comments. Please see inline.


> ### 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.


Agreed, fixed.


> ### 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?


Agreed, fixed.


> ### 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.”


We are talking about ‘old’ and ’new’ because that is the harsh reality that we have to deal with.
It’s not pretty, it’s not ideal, but it’s what we have. IS-IS is designed in a way that the
infrastructure can present us with arbitrary, overlapping, inconsistent information at any time. 
Fragments (and we can’t even agree to call them fragments) can show up arbitrarily and
the receiver has no idea whether they have a complete and consistent set of updates or not.

Implementors have to know how to deal with things. If an implementation has one flooding
topology in hand and receives fragments that add a second flooding topology, what does it do?
If I recall correctly, this question rightfully came up during WG discussions.  That’s exactly what this
is trying to address.

I appreciate that your proposed text is trying to finesse the issue, but I disagree with your resolution.
Your text suggests that a node can simply use a single view of the topology. As our second 
paragraph is trying to explain, this could be problematic because the two topologies could be radically
different and not flooding on one of them could lead to under-flooding and inconsistency. This is
why we specifically want implementations to flood on the union of the topologies.

You also wrote:

> 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.

Distributed mode doesn’t really suffer from the same problem as there is no information inconsistency. With distributed mode, old and new are quite clear and flooding on both is still the best answer.

Given that we are still discussing this, I will hold off on publishing a new version.

Regards,
Tony