On 15/11/2010, at 5:00 PM, Andrew Chi wrote:
> > I think there are two aspects to "fast enough". > > 1) The "startup" cost of downloading and processing all RPKI data needs to be > on the order of hours and not days. > > 2) The "update" cost of synchronizing changes to the repository must not > cause the validator to fall behind the rate of change in the repository. > I.e., once we have a large collection of objects, is the slightly-increased > marginal cost of modifying one file within acceptable limits? > > I believe our RP software is well within these goals, but it's always good to > test scalability assumptions like these. > > As for the 300K estimate, I'm happy to be corrected, but the order of > magnitude ought to be similar to: > > (# AS's participating in BGP routing) x (small multiplier for crls, manifest, > and tree structure) > > In October 2009, RIPE published an AS count of 15,495. If anyone else has > better numbers, please feel free to chime in. > > -Andrew > Your thinking models my assumptions. I did a tree of around 30,000 objects. This was based on a distribution of the resource pool to the entity count I saw from delegated files, bearing in mind the number of ASN. But, because we have split roots, and each RIR has to cross authenticate for ERX (historical) data, I made substate for my modelled clients that made them hold a distribution of resource under multiple chains, some from their 'main' RIR, and some from other RIR via indirect chains. I didn't do roa. they didn't exist in code at the time they would have added 10-20,000 more objects. Likewise manifests. So my total size was 30k, but it would have been of the order 100k once I add in what we have now as required structure. I also did sqldb for indexing. It makes things much faster to have direct index to SKI, AKI, date/age and valid/invalid state flags. I last ran this around June 2007 btw. cheers -george _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
