Peter, You clearly missed the added new sentence to section 4.3 in version -01
It is RECOMMENDED that the ABR register for the most specific prefix that is less specific than the original prefix. Thx, R On Tue, Jan 25, 2022 at 2:57 PM Peter Psenak <ppse...@cisco.com> wrote: > On 25/01/2022 14:07, Robert Raszuk wrote: > > Peter, > > > > Your math is off. > > > no, it's right. Every local PE in an area registers to different 100 > remote addresses to local ABRs. 1k PEs in area * 100 destinations equals > to 100k registrations. > > Peter > > > > > > > 1. 100k registrations in each ABR, 10 million network wide > > > > ABRs will "aggregate" atomic registrations to summaries when passing > > them to other ABRs. Please recalculate, > > > > > Thx, > > R. > > > > > > On Tue, Jan 25, 2022 at 12:25 PM Peter Psenak > > <ppsenak=40cisco....@dmarc.ietf.org <mailto:40cisco....@dmarc.ietf.org>> > > > wrote: > > > > Tony, > > > > I'm going to use my target scale of 100k PEs, split in 100 areas, 2 > > ABRs > > per area, with the average VPN size of 100. > > > > What you propose would result in: > > > > 1. 100k registrations in each ABR, 10 million network wide > > 2. 1200 TCP sessions in each ABR, 220k TCP sessions network wide > > > > Above is present in the network constantly, without any PE failure > > happening. > > > > We use summarization to avoid keeping states associated with 100k PE > > prefixes. With your proposed solution, on the ABRs, we replaced the > > state associated 100k prefixes with the state associated with 100k > > registrations. What did we solve? Not much, we just moved the problem > > from IGPs to some "other" application. > > > > > > Using the same scale, with the Pulse proposal, we will have no extra > > state in a stable condition. > > > > If one PE fails we will have extra 2 pulses. > > > > If one PE fails in every area at the same time we will have 200 > > extra 200 pulses. > > > > If we limit the number of pulses per ABR at any given time to 10 > (which > > is far enough to address any realistic PE failure scenario), in the > > worst case we will have extra 2k pulses in the network for a very > > limited amount of time. Yes, it goes everywhere, but given the > > amount of > > data, it's not significant. We have more then 2k prefixes being > carried > > in the IGP networks today, and we know it's not an issue. > > > > thanks, > > Peter > > > > On 19/01/2022 02:05, Tony Li wrote: > > > > > > FYI. This is a better alternative that PUA/Pulse. > > > > > > Tony > > > > > > > > >> Begin forwarded message: > > >> > > >> *From: *internet-dra...@ietf.org > > <mailto:internet-dra...@ietf.org> <mailto:internet-dra...@ietf.org > > <mailto:internet-dra...@ietf.org>> > > >> *Subject: **New Version Notification for > > draft-li-lsr-liveness-00.txt* > > >> *Date: *January 18, 2022 at 5:04:22 PM PST > > >> *To: *<t...@ietfa.amsl.com <mailto:t...@ietfa.amsl.com> > > <mailto:t...@ietfa.amsl.com <mailto:t...@ietfa.amsl.com>>>, "Tony > Li" > > >> <tony...@tony.li <mailto:tony...@tony.li> > > <mailto:tony...@tony.li <mailto:tony...@tony.li>>> > > >> > > >> > > >> A new version of I-D, draft-li-lsr-liveness-00.txt > > >> has been successfully submitted by Tony Li, and posted to the > > >> IETF repository. > > >> > > >> Name:draft-li-lsr-liveness > > >> Revision:00 > > >> Title:Node Liveness Protocol > > >> Document date:2022-01-18 > > >> Group:Individual Submission > > >> Pages:9 > > >> URL: > > https://www.ietf.org/archive/id/draft-li-lsr-liveness-00.txt > > <https://www.ietf.org/archive/id/draft-li-lsr-liveness-00.txt> > > >> <https://www.ietf.org/archive/id/draft-li-lsr-liveness-00.txt > > <https://www.ietf.org/archive/id/draft-li-lsr-liveness-00.txt>> > > >> Status: https://datatracker.ietf.org/doc/draft-li-lsr-liveness/ > > <https://datatracker.ietf.org/doc/draft-li-lsr-liveness/> > > >> <https://datatracker.ietf.org/doc/draft-li-lsr-liveness/ > > <https://datatracker.ietf.org/doc/draft-li-lsr-liveness/>> > > >> Htmlized: > > https://datatracker.ietf.org/doc/html/draft-li-lsr-liveness > > <https://datatracker.ietf.org/doc/html/draft-li-lsr-liveness> > > >> <https://datatracker.ietf.org/doc/html/draft-li-lsr-liveness > > <https://datatracker.ietf.org/doc/html/draft-li-lsr-liveness>> > > >> > > >> > > >> Abstract: > > >> Prompt notification of the loss of node liveness or > > reachability is > > >> useful for restoring services in tunneled topologies. IGP > > >> summarization precludes remote nodes from directly observing > the > > >> status of remote nodes. This document proposes a service > that, in > > >> conjunction with the IGP, provides prompt notifications without > > >> impacting IGP summarization. > > >> > > >> > > >> > > >> > > >> The IETF Secretariat > > >> > > >> > > > > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org <mailto:Lsr@ietf.org> > > https://www.ietf.org/mailman/listinfo/lsr > > <https://www.ietf.org/mailman/listinfo/lsr> > > > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
