Peter, Your math is off.
> 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> 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> > >> *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>>, "Tony Li" > >> <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> > >> Status: 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> > >> > >> > >> 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 > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
