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

"Danny McPherson" <danny@tcb.net> Thu, 29 March 2012 13:07 UTC

Return-Path: <danny@tcb.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 6065621F88C8 for <sidr@ietfa.amsl.com>; Thu, 29 Mar 2012 06:07:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 Cg2nwKBWdrOA for <sidr@ietfa.amsl.com>; Thu, 29 Mar 2012 06:07:32 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id AB19821F884E for <sidr@ietf.org>; Thu, 29 Mar 2012 06:07:32 -0700 (PDT)
Received: from webmail.tcb.net (localhost.localdomain [127.0.0.1]) by dog.tcb.net (Postfix) with ESMTP id 73C1E26800D for <sidr@ietf.org>; Thu, 29 Mar 2012 07:07:32 -0600 (MDT)
Received: from 216.168.230.7 (SquirrelMail authenticated user dpop@tcb.net) by webmail.tcb.net with HTTP; Thu, 29 Mar 2012 09:07:32 -0400 (EDT)
Message-ID: <7812.216.168.230.7.1333026452.squirrel@webmail.tcb.net>
In-Reply-To: <20120329100434.BBE5A6EE29F@minas-ithil.hactrn.net>
References: <20120326173305.D1CB96E71B3@minas-ithil.hactrn.net> <A76204B3-5EF3-4212-9136-B8E3266C7D17@tcb.net> <20120329100434.BBE5A6EE29F@minas-ithil.hactrn.net>
Date: Thu, 29 Mar 2012 09:07:32 -0400
From: Danny McPherson <danny@tcb.net>
To: sidr@ietf.org
User-Agent: SquirrelMail/1.4.10a-1.fc6
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Subject: Re: [sidr] Slides for "RPKI Over BitTorrent" presentation
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: danny@tcb.net
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, 29 Mar 2012 13:07:33 -0000

> At Wed, 28 Mar 2012 20:33:24 -0400, Danny McPherson wrote:
>
> If you're talking about moving all of the existing SIDR protocols to
> Experimental, that's a cheap shot and you know it.

I didn't say that.

> If you're just talking about RPKI over BitTorrent, the BitTorrent
> experiment was just that, an experiment.  The slides say so, and
> state, in so many words, that this was not a proposal to change the
> SIDR protocol suite.

I actually agree with the premise here, that there are scale and freshness
and distribution issues in the current model that need to be worked out.

> Thank you for making my point for me.  We can do much better than what
> we're seeing right now, but the first step is understanding where the
> problems are, which involves studying behavior and reporting results.
> This is less likely to happen if every report is viewed as an occasion
> for an axe-grinding contest, so perhaps we should focus on the
> technical issues.

This is not "axe grinding".  These designs are likely to considerably
influence how networks and routing architectures and support systems are
designed and operated - in the real world, not in a lab or 'pilot'.  I'd
like to get this right as much as you would (moreso, because my $dayjob
relies on it), and that should encourage us to fully understand the
long-term desirable objectives before stepping on the accelerator for full
standardization.  Whatever we design today should at least be able to
accommodate full deployment in the current system (even when focusing on
*routed* resource certification), which given the data you've presented at
the past coupled meetings it's already strained and there appears to be a
disconnect between those designing the RPKI and the initial folks captive
to operationalizing it (e.g., the RIRs).

Out of curiosity, what were the initial design / scale goals of the RPKI
team for aggregate object count, frequency of publication and access by
RPs?


-danny