David - Let's take Tony's example test case.
A large network is partitioned and heals. As a result I now have 1000 LSPs which need to be flooded. Let's suppose on most links/nodes in the network I can support receiving of 500 LSPs/second. But on one link/node I can only support receiving 33 LSPs/second. This means we are at risk for part of the network converging the LSPDB in 2+ seconds and part of the network converging the LSPDB in 33+ seconds. Having the means for the node which only supports 33 LSPs/second to signal its "upstream neighbors" to not overflow its receive queue isn't going to help network convergence. That's all I am saying. Les > -----Original Message----- > From: David Lamparter <equi...@diac24.net> > Sent: Tuesday, July 23, 2019 2:14 PM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> > Cc: Tony Li <tony...@tony.li>; lsr@ietf.org > Subject: Re: [Lsr] Dynamic flow control for flooding > > Hi Les, > > > On Tue, Jul 23, 2019 at 08:29:30PM +0000, Les Ginsberg (ginsberg) wrote: > > [...] As network-wide convergence depends upon fast propagation of LSP > > changes - > > you're losing me between that previous part and the next: > > > - which in turn requires consistent flooding rates on all interfaces > > enabled for flooding [...] > > I understand and follow your reasoning if we have a classical timer that > limits flooding rates per LSP. If we get multiple updates to the same > LSP, dissimilar flooding rates imply we might just have sent out the > previous now-outdated state, and we block for some potentially lengthy > time before sending out the most recent version of that LSP. > > I don't understand how we get delayed propagation of LSP changes if we > employ some mechanism to raise the flooding rate to something based > around the target system's capabilities. > > Could you elaborate on how we get delayed LSP propagation in this > scenario? > > Thanks, > > > -David _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
