I am somewhat belated in commenting on the updated draft - apologies for that.
I thank the authors for addressing my comments and think the draft is
significantly improved.
I do still have two issues - one minor and one more significant.
Minor issue:
I think you need a formal IANA section which defines what is needed in regards
to the algorithm value advertised in the Area Leader sub-TLV defined in
draft-ietf-lsr-dynamic-flooding.
More significant issue:
I am still not convinced that the proposed new use of PSNPs described in
Section 2.3 is of value. Please hear me out on this.
One of the things we learned in the context of work related to
draft-ietf-lsr-isis-fast-flooding is that optimal flooding throughput depends
on knowing the delay employed by the neighbor when sending acknowledgments to
received LSPs (what ISO 10589 calls "partialSNPInterval").
It is known that implementations vary significantly in the delays employed.
Some follow the suggested value in ISO 10589 - which is 2 seconds.
Some use a smaller - but still significant delay - for example 1 second.
And some implementations send acks "immediately" upon receipt of an LSP.
Without knowing the behavior of the neighbor in this regard, you do not know
what value to use as a delay timer for the proposed PSNPs.
You want to be somewhat aggressive (i.e. faster than CSNP interval (typically
10 seconds)) but you don’t want to be overly aggressive or you risk diminishing
the value of your flooding optimizations.
You also need to account for delays in receiving and processing the PSNPs.
This argues for a modest but multi-second timer.
But given that any LSP which is not acknowledged within the retransmit interval
(proposed as 5 seconds by ISO 10589) will be retransmitted anyway, the
need/usefulness of the triggered PSNP at a similar interval seems questionable.
Within a few seconds either the LSP will be retransmitted or a periodic CSNP
will be sent. So the potential benefit to convergence is modest at best and it
risks unnecessarily compromising your primary goal to dramatically reduce
redundant flooding.
Have you implemented the proposal described in Section 2.3?
If you have, under what conditions have you actually seen a benefit? I am
asking here about actual results - not theoretical outcomes.
You could argue that implementation of the procedures defined in Section 2.3 is
not required (you deliberately use SHOULD rather than MUST in this section) and
therefore skeptics (like me) are free to NOT implement this portion. However,
there are two constituencies that concern me.
Implementors who read the document have a reasonable expectation that what is
defined (whether it is MUST or SHOULD) is "best practice" and therefore they
would be biased to do what the document says.
Customers who read the document have a reasonable expectation that what is
defined is what they should require their vendors to supply. So even a stubborn
guy like me might find it difficult to convince a customer that this portion
should not be part of their RFP. 😊
Unless you can actually demonstrate that this adds value in real world
scenarios, I think the draft would be better without this proposal.
Thanx for listening...
Les
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
