On Fri, Nov 9, 2012 at 9:35 AM, Tim Bruijnzeels <t...@ripe.net> wrote: > Good. On that note I think it's worthwhile thinking about different > complementary ways to deal with this. I.e. make the server side more > scalable as well as considering flooding protocols and other ways to share > data between RPs.
can we break the 'current protocol choice' away from the 'future protocol choice(s)' discussion then? Meaning, can those folk interested in pursuing alternate options decide on: 1) size of a single repository (pick a large ISP as a for-instance, some one like L3 who has ~30k customers, each with 5 routes average x2 for keyroll situations? - or better yet, make up your own set of numbers, document them and the reasoning why) 2) number of repositories in existence (say, number of ASN in the global table, or ...) 3) re-fetch times of every repository (3 hrs for instance for any object type?) 4) average network latency from fetcher to fetchee (~150ms for instance) document that and then start looking at tradeoffs and consequences? talking about other transports is good, I think to date we keep getting muddled in 'but today works so...' If we want to re-think the transport, or offer alternate transports for existing folks, let's step away from 'today works'. -chris regular-guy-voice. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
