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]>>
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]>>
>> *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]>>>, "Tony Li"
>> <[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>>
>> 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
[email protected] <mailto:[email protected]>
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
