Wed, May 23, 2012 at 06:22:33PM -0700, Wes Hardaker: > 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.
I have probably have missed it, but has an IRR distribution protocol-like mechanism been discussed? See Merit's IRRd documentation, but simply its DNS serial number-like with record "add" and "delete" functions. I would expect this to be relative low impact and, at least with Merit's IRRd, to be low maintenance. And, regarding the comment about NNTP in the slides, I believe that is false. If one had a server used solely for sidr, rather than sidr + alt.whatever.stream.of.garbage, I believe it would be found to be very low maintenance. I haven't run a server for about 15 years, but I never had trouble with the software and certainly the software has likely improved rather than degraded. The problems were always hardware (disk) failures and the volume. > 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. please, we do not want multicast as the only solution. does your noc know how to debug multicast forwarding problems? _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
