On 25/01/2022 15:18, Robert Raszuk wrote:
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.
I don't think so. I'm talking about PE to ABR registrations only. I have
not even counted the inter-ABR ones.
Peter
Thx,
R
On Tue, Jan 25, 2022 at 2:57 PM Peter Psenak <[email protected]
<mailto:[email protected]>> 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
> <[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>>
> 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: *[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>> <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>>
> >> *Subject: **New Version Notification for
> draft-li-lsr-liveness-00.txt*
> >> *Date: *January 18, 2022 at 5:04:22 PM PST
> >> *To: *<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>>, "Tony Li"
> >> <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>>
> >>
> >>
> >> 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>>
> >>
<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/>>
> >> <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>>
> >>
<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
> [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
