Re: [sidr] Injecting idea of "freshness of repository data" into BGP

"Danny McPherson" <> Thu, 29 March 2012 14:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F76421E80B2 for <>; Thu, 29 Mar 2012 07:24:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pLVxKzvgQKUd for <>; Thu, 29 Mar 2012 07:24:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6409421E8124 for <>; Thu, 29 Mar 2012 07:23:55 -0700 (PDT)
Received: from (localhost.localdomain []) by (Postfix) with ESMTP id DA8E126800D for <>; Thu, 29 Mar 2012 08:23:54 -0600 (MDT)
Received: from (SquirrelMail authenticated user by with HTTP; Thu, 29 Mar 2012 10:23:54 -0400 (EDT)
Message-ID: <>
In-Reply-To: <>
References: <20120328081939.GA19843@slice> <> <20120329072236.GA7311@slice> <> <20120329081625.GA9609@slice> <> <20120329115714.GA18393@slice> <> <20120329121824.GB18393@slice> <>
Date: Thu, 29 Mar 2012 10:23:54 -0400 (EDT)
From: "Danny McPherson" <>
To: "sidr wg list" <>
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] Injecting idea of "freshness of repository data" into BGP
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 Mar 2012 14:24:04 -0000

>   o but we do not know the long term scaling characteristics of the
>     current rsync scheme.

While we may not know the scaling characteristics of the solution, do we
at least know what would be a desirable objective target for sustainable

>   o we could get much better rsync performance with a trivial change at
>     the rids.

Does "much better" accommodate our desired engineering targets for
long-term?  What are those?

>   o we are already playing with a bittorrent experiment for a number of
>     reasons, mainly because its model is so different.  you have seen
>     the initial results.  the code is open.

Twitter may be more real-time (only half kidding :-)

>   o but we are suspicions and curious creatures, so folk are already
>     discussing mechanisms for v2, mechanism agility, ...  to be deployed
>     in a year or three.

Again, if we're engineering here for the future and stable standards then
what are the desirable long-term system scale objectives for the RPKI?  I
think this is a pretty reasonable question - when this is fully deployed
in n years, whatever the timeline is, what do you believe will be the
number of objects (CRLs, EEs, ROAs, Manifests, size, etc..), RPs,
frequency of updates, etc.., given the operational and design experience
you have thus far?

While I suspect some clever response here, I'm being sincere with these
questions, particularly if we're baking this stuff into standards track