1)You can successfully deploy this algorithm in the presence of nodes
which do NOT support this algorithm. But you cannot successfully deploy
this algorithm in the presence of nodes which enable a different
flooding reduction algorithm.
This is correct. There seem to be two sides to this situation, however.
Some operators will likely not want to deploy
draft-ietf-lsr-dynamic-flooding to deploy flooding reduction because it
is "something else to break," or it interferes in some way with
incremental deployment. I'm sympathetic to this point of view, so I'm a
little skittish about making the signaling in dynamic-flooding a
MUST--but I'm perfectly happy to make it a MAY, or perhaps a SHOULD, if
folks think that is useful.
2)Regarding the use of PSNPs…you propose to send a PSNP (once
apparently) which has the LSP entries for all the LSPs which you chose
NOT to flood to a given node (minus any LSPs for which you may have
received an explicit ack) in the most recent time interval - suggested
to be one second.
Correct. This was intended as a compromise towards initial criticisms of
the mechanism that "flooding could fail, so there needs to be some way
to ensure no-one dropped anything." The original draft suggested a CSNP
one second after the partial flood, with a operator-configurable timer.
The original intent was not to disturb existing periodic CSNPs. PSNPs
are, however, lighter weight.
What then do these special PSNPs provide? It could be argued that they
provide a lower cost and more targeted recovery mechanism in some
circumstances – and that using them in conjunction with periodic CSNPs
may speed convergence. However, I think the existing proposal discussed
in Section 2.3 of the draft lacks detail and is unlikely to achieve
this goal in most circumstances.
In the initial stages of this work, I was fine leaving flooding
reliability to periodic CSNPs. Flooding failures are just what the
periodic CSNPs are supposed to account for. Flooding reduction might, in
some situations, increase the odds of a flooding failure occurring, but
it seems flooding failures are pretty rare, so the additional overhead
probably isn't needed.
This really comes down to assessing the trade-off between ensuring
proper flooding as quickly as possible and the additional processing
overhead of the "quick check" PSNP/CSNP. I don't know if there is going
to be a "universal answer" for everyone (?). Some folks are going to be
more comfortable with some sort of "quick check," others are going to
see (as your analysis shows) that such a check isn't really needed.
Suggestion--what if we changed this implementations MAY bring their
existing timer up so the next CSNP is sent more quickly, or
implementations MAY send a following PSNP. These should SHOULD be
operator configurable. I don't see that choosing any of these options
would impact interoperability between implementations, and it would give
different folks with different comfort levels options?
:-) /r
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
