Tony – I think you need to mention periodic CSNPs. By base specification (ISO 10589) periodic CSNPs are NOT sent on P2P links – though many implementations support sending them and some implementations even default to sending them. But given it is not base protocol behavior, if you require them for correct operation of the algorithm it needs to be explicitly mentioned.
Use of a PSNP may be a useful aid to convergence, but I think the history period needs to be bounded, otherwise you would be duplicating what CSNPs are for – and doing so less efficiently. So I think you need to be clear on when PSNPs are used and what the scope of the set of LSP entries expected to be sent in such a PSNP may be. Les From: Antoni Przygienda <p...@juniper.net> Sent: Monday, August 1, 2022 9:55 AM To: Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org>; Les Ginsberg (ginsberg) <ginsb...@cisco.com>; lsr@ietf.org Subject: Re: [Lsr] Comments on draft-white-lsr-distoptflood-03 Bit tricky to describe precisely since the list of things to send is per originator per LSP-ID or rather neighbors are stable _per originator_ but whether a LSP is reflooded is driven by the ID as well. But reading what you wrote it’s pretty good summary without explaining what the set is. We probably take it verbatim like this 😉 * Tony From: Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org<mailto:acee=40cisco....@dmarc.ietf.org>> Date: Monday, 1 August 2022 at 08:28 To: Antoni Przygienda <p...@juniper.net<mailto:p...@juniper.net>>, Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>, lsr@ietf.org<mailto:lsr@ietf.org> <lsr@ietf.org<mailto:lsr@ietf.org>> Subject: Re: [Lsr] Comments on draft-white-lsr-distoptflood-03 [External Email. Be cautious of content] From: Antoni Przygienda <prz=40juniper....@dmarc.ietf.org<mailto:prz=40juniper....@dmarc.ietf.org>> Date: Monday, August 1, 2022 at 11:20 AM To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>, "lsr@ietf.org<mailto:lsr@ietf.org>" <lsr@ietf.org<mailto:lsr@ietf.org>> Subject: Re: [Lsr] Comments on draft-white-lsr-distoptflood-03 1. Agree, we already talked about it amongst the authors. Oberve that it’s strictly implementation specific behavior that does not need to be standardized so we overspecify a it but I agree that would improve the document overall. 2. Agree as well, it’s not easy to express what is actually going on PSNPs so we try to massage the language somewhere along the lines what you said Not grok’ing your “per never” timer. Probably auto correction 😉 Ha! Ha! I should always “read before Send” – I meant “per neighbor”. More than happy to get into adoption call if chairs support that. Given we didn’t socialize the new version I thought it’s wise not to push it during IETF but personally more than happy to go down the adoption route since implementations are there and I spent enough time on the draft helping out with it I personally to get it into quality high enough to be WG material IMO We have a backlog of WG last calls but not WG adoptions that don’t aren’t without significant issues. Thanks, Acee --- tony From: Acee Lindem (acee) <acee=40cisco....@dmarc.ietf.org<mailto:acee=40cisco....@dmarc.ietf.org>> Date: Monday, 1 August 2022 at 07:42 To: Antoni Przygienda <p...@juniper.net<mailto:p...@juniper.net>>, Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>, lsr@ietf.org<mailto:lsr@ietf.org> <lsr@ietf.org<mailto:lsr@ietf.org>> Subject: Re: [Lsr] Comments on draft-white-lsr-distoptflood-03 [External Email. Be cautious of content] 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 <lsr-boun...@ietf.org<mailto:lsr-boun...@ietf.org>> on behalf of Antoni Przygienda <prz=40juniper....@dmarc.ietf.org<mailto:prz=40juniper....@dmarc.ietf.org>> Date: Friday, July 29, 2022 at 11:32 PM To: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>, "lsr@ietf.org<mailto:lsr@ietf.org>" <lsr@ietf.org<mailto:lsr@ietf.org>> 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) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> Date: Friday, 29 July 2022 at 15:08 To: Antoni Przygienda <p...@juniper.net<mailto:p...@juniper.net>>, lsr@ietf.org<mailto:lsr@ietf.org> <lsr@ietf.org<mailto:lsr@ietf.org>> 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 Juniper Business Use Only Juniper Business Use Only Juniper Business Use Only Juniper Business Use Only
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
