Hi Peter, I'm probably missing something in the current PULSE but I cannot find the mechanism that limits the number of the pulses. Do you envision that being like a throttling mechanism? But delaying the propagation of notification for some events might cause more instability in a network.
Regards, Greg On Tue, Jan 4, 2022 at 1:52 AM Peter Psenak <[email protected]> wrote: > Hi Greg, > > On 03/01/2022 23:17, Greg Mirsky wrote: > > Happy New Year to All! > > > > Hi Peter, > > Top-pasting: > > In 99,99% of cases there will be only single pulse generated when one PE > > goes down. That itself is a very rare event itself. > > > > We can easily limit the number of pulses generated on ABR to a single > > digit number to cover the unlikely case of many PEs in area becoming > > unreachable at the same time. > > > > I think that it is possible for the summarizing ABR to get disconnected > > from the IGP area in such a way that the summarization is still valid. > > If such a case is valid, would the ABR generate PULSE for each > > disconnected PE? > > obviously not. That's why I mentioned the number of pulses will be > limited on every ABR. > > thanks, > Peter > > > > > Regards, > > Greg > > > > On Mon, Jan 3, 2022 at 8:56 AM Peter Psenak > > <[email protected] <mailto:[email protected]>> > > > wrote: > > > > Chris, > > > > On 03/01/2022 17:18, Christian Hopps wrote: > > > > > > Peter Psenak <[email protected] <mailto:[email protected]>> > writes: > > > > > >> On 03/01/2022 16:21, Christian Hopps wrote: > > >>> > > >>>> On Nov 29, 2021, at 7:39 PM, Les Ginsberg (ginsberg) > > <[email protected] > > <mailto:[email protected]>> wrote: > > >>>> > > >>>> Tony – > > >>>> Let me try one example – see if it helps. > > >>>> Summarization is used in the network. > > >>>> But customer identifies a modest number of key nodes where it > > wants to detect loss of reachability ASAP. Unfortunately, customer > > is unable to assign addresses which are outside of the summary to > > these nodes. > > >>> > > >>> I think this does in fact capture the problem trying to be > > solved here, nicely. > > >> > > >> not really. > > >> In fact assigning addresses to the nodes in a way that they are > > part of the > > >> summary is the right thing to do. > > > > > > No, not if you want more detailed information about specific > > reachability it's not. And .... > > > > > > typically you want to summarize all prefixes inside the area when > > advertising outside the area. And you want to know about some of > these > > prefixes when they are lost to help convergence. > > > > > > > > > >> The problem we are trying to solve is to use the summarization > > but without the > > >> loss of the fast notification of the node down event. > > > > > > You want more specific information about reachability, but you > > just want to do it when the network is stressed and undergoing > change. > > > > > > So the "works now" way of not summarizing these important > > prefixes has the state in the network when it's working, so you know > > adding and removing it is something the network is already capable > > of handling. > > > > > > New signaling that *only* is created when things start failing, > > tests the infrastructure at exactly the wrong time. > > > > In 99,99% of cases there will be only single pulse generated when > > one PE > > goes down. That itself is a very rare event itself. > > > > We can easily limit the number of pulses generated on ABR to a single > > digit number to cover the unlikely case of many PEs in area becoming > > unreachable at the same time. > > > > > > > > > > If a failing network can handle the extra state, then a > > functioning stable network of course can too. > > > > no, that's not what we claim. We want network to be summarized all > > times > > and generate limited number of pulses at any given time to help the > > network converge fast in case where single (or very few) PEs in an > area > > go down. > > > > thanks, > > Peter > > > > > > > > > > > > Thanks, > > > Chris. > > > > > >> > > >> thanks, > > >> Peter > > >> > > >> > > >>> One solution very simple solution that works today is: > > >>> - Tell the customer they can't do this, but they *can* modify > > their addressing > > >>> (this is literally what they do for a living) so that they > > don't have this > > >>> problem. > > >>> Do we *really* want modify our IGPs (a BIG ask) with some > > pretty questionable > > >>> changes, just to save the operators the trouble of doing their > > job correctly? > > >>> Maybe the answer here is this isn't a good idea, and we should > > move on... > > >>> Thanks, > > >>> Chris. > > >>> [as wg member] > > >>> _______________________________________________ > > >>> Lsr mailing list > > >>> [email protected] <mailto:[email protected]> > > >>> https://www.ietf.org/mailman/listinfo/lsr > > <https://www.ietf.org/mailman/listinfo/lsr> > > >>> > > > > > > > > > > _______________________________________________ > > Lsr mailing list > > [email protected] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/lsr > > <https://www.ietf.org/mailman/listinfo/lsr> > > > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
