Re: [sidr] Injecting idea of "freshness of repository data" into BGP

["Danny McPherson" <[e-mail]>]

>   o but we do not know the long term scaling characteristics of the
>     current rsync scheme.

While we may not know the scaling characteristics of the solution, do we
at least know what would be a desirable objective target for sustainable
deployment?

>   o we could get much better rsync performance with a trivial change at
>     the rids.

Does "much better" accommodate our desired engineering targets for
long-term?  What are those?

>   o we are already playing with a bittorrent experiment for a number of
>     reasons, mainly because its model is so different.  you have seen
>     the initial results.  the code is open.

Twitter may be more real-time (only half kidding :-)

>   o but we are suspicions and curious creatures, so folk are already
>     discussing mechanisms for v2, mechanism agility, ...  to be deployed
>     in a year or three.

Again, if we're engineering here for the future and stable standards then
what are the desirable long-term system scale objectives for the RPKI?  I
think this is a pretty reasonable question - when this is fully deployed
in n years, whatever the timeline is, what do you believe will be the
number of objects (CRLs, EEs, ROAs, Manifests, size, etc..), RPs,
frequency of updates, etc.., given the operational and design experience
you have thus far?

While I suspect some clever response here, I'm being sincere with these
questions, particularly if we're baking this stuff into standards track
protocols.

Thanks,

-danny