Re: [sidr] Scaling properties of caching in a globally deployed RPKI / BGPSEC system

[Russ White <[e-mail]>]

> It is also important to note that a running RP fetches only *changed* RPKI objects 
> during each polling instance in normal (steady-state) operation 
> (i.e., whatever the delta happens to be since the previous polling instance). 
> The RP would download *all* RPKI objects rather rarely, e.g., when there is a restart 
> (i.e., failure recovery). So the common fetch delay seen at RPs would be 
> more like seconds or minutes as shown in the lower left corner of plot on slide 2 
> (or, top of the table in slide 1), corresponding to fetches of 100 to 10,000 changed rpki objects.
> 
> B. Estimate of RPKI repositories:

> It is known that 84% of all ASes are stub, and 16% are non-stub. So about 35,280 are stub ASes 
> and only 6,720 are non-stub. The stub ASes are likely to only run simplex bgpsec and 
> they would likely contract out publication point service to their upstream ISP or a third party 
> (Tim also observed this). Even many non-stub ASes can be expected to do the same. 
> So in the end, we think the total number of repositories (what you call SIAs) 
> will be O(100) or O(1000), much less than the 42,000 you have assumed.

Several points:

1. It is never a good idea to "just right" engineer a system to the
"best available numbers from today." Yes, I know the old saw about the
glass being neither half empty nor half full, but overengineered --but I
also know that virtually every system that counts on a specific traffic
pattern, or a specific rate of usage, finds those underlying assumptions
completely and totally wrong.

2. If I ran a large network (like a big financial, or major traffic
sink), I would never hand my certificate advertisement over to my SP. If
I've taken the time and trouble to get my own addresses in order to
maintain some level of independence from my provider, I wouldn't undo my
independence by using that same provider as the point of advertisement
for my routes in a system that can take 4+ hours to synchronize (only in
SIDR do we talk about minutes and hours as if they are "short"
convergence times).

3. So, I would assume a much higher number than the O(1000) you're
assuming here, and bring the number closer to the 40,000 contained in
the original process.

> C. Number of router certs:
> 
> Observe that per-router certs are not required; certs can be per AS. It remains to be seen 
> what granularity (ranging from per AS to per router) will be used. But, for worse case, 
> if we assume per-router certs in all ASes, then a conservative estimate can be obtained as follows. 
> The stub ASes will have a low average # eBGPSEC routers (say, 2 per AS), 
> and the non-stub ASes will have a relatively larger value for the same (say, 20 per AS). 
> Then the total number of eBGPSEC routers can be estimated at 204,960 (= 20*6720 + 2*35280).  
> You had assumed 420,000 (10 x 42,000). Also, there should be 4 certs per *non-stub* eBGPSEC router; 
> one pair (current and next) for origination prefixes and another pair (current and next) for transit ASes 
> (please see draft-rogaglia-sidr-bgpsec-rollover and draft-sriram-replay-protection-design-discussion). 
> And there should be only 2 certs per *stub* eBGPSEC router since it does not have transit prefixes. 
> That gives us an estimate of 678,720 (=4*20*6720 + 2*2*35280) for the total # router certs. 
> We think this number is conservative (high) but reasonable for now.

I don't think this is right, either --you're assuming a "stub AS" will
only have two routers, which is completely off base. The smallest stub
AS will have two routers, larger ones will have more as they scale
upwards. Several large enterprise networks I've worked on have at least
20, if not more, edge routers across a single AS, into multiple providers.

The size of a transit is also questionable --I can't imagine an average
of 20 edge routers for a transit provider. Are there really so many 2
and 3 edge router transits that it would offset AT&T, Level 3, and many
others we know must be on the order of hundreds of edges?

204k eBGP speakers is a gross understimate of the size of the Internet
at large.

Russ

-- 
<><
[e-mail]
[e-mail]