Speaking as WG member:
Hi Tony,
Great improvement to the prior version of the draft – I’d now support adoption.
My two comments at the mike were:
1. Potentially add text to text to section 2.1 and 2.2 to allow for N
flooding paths t the neighbors on the TNL.
2. Suggested clarificiton for section 2.3:
OLD:
of all LSPs that have not been reflooded during the timer runtime
NEW:
of all LSPs for which flooding to any neighbor was suppressed during the
time runtime
Alternately, you could have a separate timer per never if one desired more
granular failure detection. I realize that for a given LSP source, the list of
neighbors will be exactly the same. I remember that prior to your
modifications, this was a CSNP and I questioned whether this failure prevention
strategy would negate the savings in flooding..
Thanks,
Acee
From: Lsr <[email protected]> on behalf of Antoni Przygienda
<[email protected]>
Date: Friday, July 29, 2022 at 11:32 PM
To: "Les Ginsberg (ginsberg)" <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [Lsr] Comments on draft-white-lsr-distoptflood-03
No Announce: thanks, we agree
Well, given LSP flooding is unrelible as well it seems no better and no worse
if we RTX. The PSNP bits will be hanging there and I guess we have to put it on
a RTX mechanism or we rely on CSNP. Good comment.
Yes, the PSNPs are _in addition_ so yes, I agree also here we can fall back on
those. I kind of prefer those since it doesn’t change protocol behavior further
than it already does by sending the additional PSNP
Thanks
n Tony
From: Les Ginsberg (ginsberg) <[email protected]>
Date: Friday, 29 July 2022 at 15:08
To: Antoni Przygienda <[email protected]>, [email protected] <[email protected]>
Subject: Comments on draft-white-lsr-distoptflood-03
[External Email. Be cautious of content]
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
Juniper Business Use Only
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr
