On Mon, 15 Nov 2010, George Michaelson wrote:
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.
Can you share the results?
--Sandy
cheers
-george
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
