Re: [sidr] sidrSlides for "RPKI Over BitTorrent" presentation

heasley <heas@shrubbery.net> Thu, 24 May 2012 13:18 UTC

Return-Path: <heas@shrubbery.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFEA21F85DD for <sidr@ietfa.amsl.com>; Thu, 24 May 2012 06:18:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msMl93Yd1AEO for <sidr@ietfa.amsl.com>; Thu, 24 May 2012 06:18:31 -0700 (PDT)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46EA21F8570 for <sidr@ietf.org>; Thu, 24 May 2012 06:18:31 -0700 (PDT)
Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 5968B88EEF; Thu, 24 May 2012 13:18:31 +0000 (UTC)
Date: Thu, 24 May 2012 13:18:31 +0000
From: heasley <heas@shrubbery.net>
To: Wes Hardaker <wjhns1@hardakers.net>
Message-ID: <20120524131831.GG35070@shrubbery.net>
References: <20120326173305.D1CB96E71B3@minas-ithil.hactrn.net> <0lehqanzja.fsf@wjh.hardakers.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0lehqanzja.fsf@wjh.hardakers.net>
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Rob Austein <sra@hactrn.net>, sidr@ietf.org
Subject: Re: [sidr] sidrSlides for "RPKI Over BitTorrent" presentation
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 May 2012 13:18:32 -0000

Wed, May 23, 2012 at 06:22:33PM -0700, Wes Hardaker:
> Rob Austein <sra@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?