Tony – Inline…but I agree we can let this simmer for a while…
From: Antoni Przygienda <p...@juniper.net> Sent: Friday, March 10, 2023 12:55 PM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; lsr@ietf.org; draft-ietf-lsr-distoptflood.auth...@ietf.org Subject: Re: Comments on draft-ietf-lsr-distoptflood-01 Thanks, most of the update were your comments. Yeah, IANA will come So, the problem is that you do NOT flood on those adjacencies where we suggest to send PSNPs and hence no RTX will happen, only CSNP will fix it and that’s slow. So PNSPs will speed it up … So I don’t follow your logic aobut (it will RTX anyway) [LES:] I understand the PSNPs are to be sent on the links NOT used in the reduced flooding. My point is that if you don’t get an ack back from the peer on the link on which you did flood, it could be because: a)The neighbor is sending delayed acks or b)The LSP actually got dropped Depending on implementation choice, “a” could take 2+ seconds. If “b” happens the LSP will get retransmitted withing 5 seconds anyway If you want your mechanism to be better/faster than periodic CSNPs but be unlikely to trigger unnecessary duplicate flooding you need to pick a timer between 2-5 seconds – which isn’t going to be much better than the 5 second retransmit interval. And you risk unnecessary duplicate flooding. Anyway, we understand each other now (I hope)… Les I’m perfectly fine keeping it a SHOULD or even MAY if you’re more comfortable with that, but it will speed up in case of hicc-ups AFAIS. And no, we don’t have currently experimental data we can disclose … And neither have you so we basically all argue on “feelings and experience” and hence won’t make progress. Experimental data shouild come over time. And even then, it will hinge on so many topological, link behavior assumptions we can argue the whole day long anyway. For the moment the draft will just chuck along in the WG as it is, it’s still early and further discusisons will happen … Thanks again Les for thorough reading and thinking it through * Tony From: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> Date: Friday, 10 March 2023 at 07:31 To: lsr@ietf.org<mailto:lsr@ietf.org> <lsr@ietf.org<mailto:lsr@ietf.org>>, draft-ietf-lsr-distoptflood.auth...@ietf.org<mailto:draft-ietf-lsr-distoptflood.auth...@ietf.org> <draft-ietf-lsr-distoptflood.auth...@ietf.org<mailto:draft-ietf-lsr-distoptflood.auth...@ietf.org>> Subject: Comments on draft-ietf-lsr-distoptflood-01 [External Email. Be cautious of content] 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 Juniper Business Use Only
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
