Rob Austein <s...@hactrn.net> writes: > For those who didn't get to see the end of the "RPKI Over BitTorrent" > presentation in today's SIDR meeting, the full slide deck is available > at > > http://www.ietf.org/proceedings/83/slides/slides-83-sidr-9.pdf > > and should be relatively self-explanatory.
I've been thinking about this a lot lately, as it'll certainly be a challenge to ensure everyone is up to date. It doesn't matter whether you "should have pulled" or whether "you pull right when you get a request". Either way, there is an underlying data distribution problem. Most importantly, every bit of the repository needs to pretty much get everywhere. Rdist works well for trying not to duplicate data. Bittorrent works well for sharing the load, but either requires a lot of bittorrent start files (whatever they're called), which then becomes hard to syncronize; or a small number of bittorrent files (one per aggregation point) that indicate you need to refetch and entire .zip file even if you already have most of it anyway. But the real underlying problem is what I said above: every bit needs to get efficiently to every place, ideally at time of initial publication. This sure smells to me like a solution in need of multicast (or, more accurately, "deployed multicast") with a fall back to something like bittorrent for bootstrapping or when you've missed session data and can't recover. Multicast as a data stream would be much more efficient is collecting updates, although there are still issues that would need to be worked through like "how do you know you heard everything". Oh, and it only works if you multicast deployed to your site of course. -- Wes Hardaker SPARTA, Inc. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
