Hi Aijun, In most deployments summary routes are already crafted carefully to only cover those destinations which are important and should be reachable from outside of the area.
So I see no point in building yet another policy to select a subset of summaries to be PUA eligible. Along those lines I do not buy into the notion of "some prefixes within summaries to be more important than others" - it is simply impossible to say that this PE is more important than the other one in all practical cases. If we are to roll out a mechanism to signal unreachability it better be robust and dependable - not just an optional hint. With that I would welcome solution which says - if we have more then X prefixes (or % of prefixes) to be advertised by ABR we stop advertising the summary covering them (or deaggregate the summary). Thx, R. On Wed, Jan 5, 2022 at 12:06 AM Aijun Wang <[email protected]> wrote: > 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
