>can take 4+ hours to synchronize (only in SIDR do we talk about minutes and >hours as if they are "short" >convergence times).
As has been noted before, a *running* rpki cache server has low delays at each polling instance (see top of Table 1 for 100 up to 10,000 *changed* RPKI objects). For a *new* rpki cache server that is starting up and fetching all 1.5 million objects, the rpki rsync delay is larger (4 hours). Routers would not be using this *new* server until it signals it is ready to serve. In the meanwhile, routers are being served by other *up and running* rpki cache servers. > >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. As Eric has also shown, it makes a difference of only about 10% in the total rpki rsync delay when you increase the # SIAs (repositories) from 5 to 42,000. BTW, just to note here again Tim's comment to Eric about this, "In any case 42k repositories seems a bit much, though more than 5 is very likely." > >> C. Number of router certs: >> --snip -- >> 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. Would you like to share a ball park number you know that is a better estimate for the # eBGP speakers? It is a parameter in the model; so easy to rerun. Sriram _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
