Hi, Robert: Agreed. The potential usages of PUA/UPA are not only PE routers(for BGP PIC), but also prevalent Tunnel technologies(GRE/SRv6). All these nodes are important and we can’t punches so many holes in the summary range.
Aijun Wang China Telecom > On Jun 14, 2022, at 22:43, Robert Raszuk <rob...@raszuk.net> wrote: > > > Acee, > > > Note that any good implementation will allow one to punch holes in their > > area ranges so that critical prefixes are advertised or > > Every PE address is critical. The story that one PE can be more important > than any other is just to mislead you at best. > > And we are (I hope) scoped the discussion to summaries. > > I realize PUE also wants to cover P failures so in this case each P is also > equally important. > > Thx, > R, > > >> On Tue, Jun 14, 2022 at 3:57 PM Acee Lindem (acee) <a...@cisco.com> wrote: >> Speaking as WG member: >> >> >> >> From: Lsr <lsr-boun...@ietf.org> on behalf of Robert Raszuk >> <rob...@raszuk.net> >> Date: Tuesday, June 14, 2022 at 9:27 AM >> To: Christian Hopps <cho...@chopps.org> >> Cc: Gunter Van de Velde <gunter.van_de_ve...@nokia.com>, lsr <lsr@ietf.org>, >> "draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org" >> <draft-ppsenak-lsr-igp-ureach-prefix-annou...@ietf.org>, >> draft-wang-lsr-prefix-unreachable-annoucement >> <draft-wang-lsr-prefix-unreachable-annoucem...@ietf.org> >> Subject: Re: [Lsr] Thoughts about PUAs - are we not over-engineering? >> >> >> >> All, >> >> >> >> > What is wrong with simply not doing summaries >> >> >> >> What's wrong is that you are reaching the scaling issue much sooner than >> when you inject summaries. >> >> >> >> Note that any good implementation will allow one to punch holes in their >> area ranges so that critical prefixes are advertised or included in the >> range existence criteria. >> >> >> >> Thanks, >> >> Acee >> >> >> >> >> >> Note that the number of those host routes is flooded irrespective of the >> actual need everywhere based on the sick assumption that perhaps they may be >> needed there. There is no today to the best of my knowledge controlled >> leaking to only subset to what is needed. >> >> >> >> But this is not the main worry. Main worry is that in redundant networks you >> are seeing many copies of the very same route being flooded all over the >> place. So in a not so big 1000 node network the number of host routes may >> exceed 8000 easily. cri >> >> >> >> Sure when things are stable all is cool. But we should prepare for the >> worst, not the best. In fact, the ability to encapsulate to an aggregate >> switch IP (GRE or UDP) or nowadays SRv6 has been one of the strongest >> advantages. >> >> >> >> So as started before the problem does exist. Neither PULSE nor PUE solve it >> which are both limited to PE failures detection which is not enough (maybe >> even not worth). But PE-CE failures need to be signalled in the case of >> injecting summaries. Maybe as I said in previous msg just BGP withdrawal is >> fine. If not we should seek a solution which addresses the real problem, not >> an infrequent one. >> >> >> >> Best, >> >> R. >> >> >> >> >> >> >> >> On Tue, Jun 14, 2022 at 2:51 PM Christian Hopps <cho...@chopps.org> wrote: >> >> >> >> > On Jun 14, 2022, at 04:59, Van De Velde, Gunter (Nokia - BE/Antwerp) >> > <gunter.van_de_ve...@nokia.com> wrote: >> > >> > What is wrong with simply not doing summaries and forget about these PUAs >> > to pinch holes in the summary prefixes? this worked very well during last >> > two decennia. Are we not over-engineering with PUAs? >> >> 100% yes, IMO. >> >> Thanks, >> Chris. >> [as wg-member] >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr >> > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
