I think the mentioned solution can also address Robert and Christian’s concerns.
Aijun Wang China Telecom > On Jan 5, 2022, at 07:02, Aijun Wang <[email protected]> wrote: > > Hi, Greg: > > https://datatracker.ietf.org/doc/html/draft-wang-lsr-prefix-unreachable-annoucement-08#section-8 > has some description for such considerations: > “ In order to reduce the unnecessary advertisements of PUAM > messages on ABRs, the ABRs should support the configuration of the > protected prefixes. Based on such information, the ABR will only > advertise the PUAM message when the protected prefixes(for example, > the loopback addresses of PEs that run BGP) that within the summary > address is missing.” > > > Aijun Wang > China Telecom > >>> On Jan 5, 2022, at 03:56, Greg Mirsky <[email protected]> wrote: >>> >> >> Hi Peter, >> thank you for your response. I'm looking forward to the new version of the >> draft. It will be interesting to learn the criteria that enable an ABR to >> reliably identify the scenarios you've suggested are outside the scope of >> the PULSE draft and should be handled differently. >> >> Regards, >> Greg >> >>> On Tue, Jan 4, 2022 at 10:08 AM Peter Psenak <[email protected]> wrote: >>> Hi Greg, >>> >>> On 04/01/2022 18:13, Greg Mirsky wrote: >>> > 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. >>> >>> no. It's a limit not a delay. If too many edge nodes loose connectivity >>> to the ABR in its area, it's a result of the severe event like area >>> partition or loss of area connectivity from ABR. These are not types of >>> events that we are trying to address with pulses. >>> >>> The limit is not described in the published version of the draft. >>> We are working on the updated version that will include the description >>> of it. >>> >>> thanks, >>> Peter >>> >>> > >>> > Regards, >>> > Greg >>> > >>> > On Tue, Jan 4, 2022 at 1:52 AM Peter Psenak <[email protected] >>> > <mailto:[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]> >>> > <mailto:[email protected] >>> > <mailto:[email protected]>>> >>> > > wrote: >>> > > >>> > > Chris, >>> > > >>> > > On 03/01/2022 17:18, Christian Hopps wrote: >>> > > > >>> > > > Peter Psenak <[email protected] <mailto:[email protected]> >>> > <mailto:[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]> >>> > > <mailto:[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]> <mailto:[email protected] >>> > <mailto:[email protected]>> >>> > > >>> https://www.ietf.org/mailman/listinfo/lsr >>> > <https://www.ietf.org/mailman/listinfo/lsr> >>> > > <https://www.ietf.org/mailman/listinfo/lsr >>> > <https://www.ietf.org/mailman/listinfo/lsr>> >>> > > >>> >>> > > > >>> > > > >>> > > >>> > > _______________________________________________ >>> > > Lsr mailing list >>> > > [email protected] <mailto:[email protected]> <mailto:[email protected] >>> > <mailto:[email protected]>> >>> > > https://www.ietf.org/mailman/listinfo/lsr >>> > <https://www.ietf.org/mailman/listinfo/lsr> >>> > > <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
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
