heasley h...@shrubbery.net writes:
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
Thu, May 24, 2012 at 06:36:51AM -0700, Wes Hardaker:
I didn't say only :-) . In fact, I pointed at bittorrent as a backup. I
simply said it would be more efficient when sending out *new* changes.
understood; i'm registering/re-enforcing that if that is developed it must
not be the only mathod.
heasley h...@shrubbery.net writes:
Thu, May 24, 2012 at 06:36:51AM -0700, Wes Hardaker:
I didn't say only :-) . In fact, I pointed at bittorrent as a backup. I
simply said it would be more efficient when sending out *new* changes.
understood; i'm registering/re-enforcing that if that is
Wes,
On May 23, 2012, at 9:22 PM, Wes Hardaker wrote:
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
On Thu, May 24, 2012 at 4:13 PM, John G. Scudder j...@juniper.net wrote:
Wes,
On May 23, 2012, at 9:22 PM, Wes Hardaker wrote:
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
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.
