Tony (and everyone) - Following up on the brief discussion about this draft at today's WG meeting...
I withdraw the comment regarding having to announce use of the algorithm. After rereading I agree this is not necessary. Regarding my second comment about the use of PSNPs as a recovery mechanism in cases where topology changes temporarily compromise the optimized flooding...the draft says in Section 2.3 <snip> o Set a short timer; the default should be one second o When the timer expires, send Partial Sequence Number Packet (PSNP) of all LSPs that have not been reflooded during the timer runtime to all neighbors unless an up-to-date PSNP or CSNP has been already received from the neighbor <end snip> Given that PSNPs are unreliable, how can you guarantee that the neighbor has received the PSNP(s) required by the most recent set of LSP updates which were NOT flooded to that neighbor? The traditional way of closing this gap is to send periodic CSNPs on interfaces where flooding may have been suppressed. In this way you guarantee the reliability of the update process. The recovery time may be a bit slower as sending CSNPs every second is excessive - but I do not see how you guarantee reliability without periodic transmissions. Or do you mean to say send the PSNP once IN ADDITION to periodic CSNPs?? This would allow quicker recovery in most cases while using a slower periodic timer for the CSNPs as protection in case the PSNP was lost. Les _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr