Re: [sidr] RPKI <-> allocation consistency

Eric Osterweil <eosterweil@verisign.com> Tue, 28 August 2012 14:09 UTC

Return-Path: <eosterweil@verisign.com>
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 C447521F84C5 for <sidr@ietfa.amsl.com>; Tue, 28 Aug 2012 07:09:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.382
X-Spam-Level:
X-Spam-Status: No, score=-6.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06ZIWneEFXV7 for <sidr@ietfa.amsl.com>; Tue, 28 Aug 2012 07:09:21 -0700 (PDT)
Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id 15BDB21F8468 for <sidr@ietf.org>; Tue, 28 Aug 2012 07:09:20 -0700 (PDT)
Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKUDzRDo+seWwplMjya4lAK1U0xMZkdJEE@postini.com; Tue, 28 Aug 2012 07:09:21 PDT
Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q7SE9FYo002914; Tue, 28 Aug 2012 10:09:18 -0400
Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.88.29.242]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Aug 2012 10:09:15 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Eric Osterweil <eosterweil@verisign.com>
In-Reply-To: <503C47A8.7030700@bbn.com>
Date: Tue, 28 Aug 2012 10:09:15 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <303C576D-D1F8-4F62-8E0E-0D74A28B2771@verisign.com>
References: <24B20D14B2CD29478C8D5D6E9CBB29F625F555CB@Hermes.columbia.ads.sparta.com> <D857A4BB-E484-45A4-A09F-FB8FAF2215AC@tcb.net> <C5B88834-3A10-41F7-A4F3-2B7C9B540197@verisign.com> <50389897.3040503@bbn.com> <97856400-9F70-4AEC-AF91-A0673A6D716D@verisign.com> <503C47A8.7030700@bbn.com>
To: Stephen Kent <kent@bbn.com>
X-Mailer: Apple Mail (2.1084)
X-OriginalArrivalTime: 28 Aug 2012 14:09:15.0200 (UTC) FILETIME=[B4C9FC00:01CD8526]
Cc: sidr@ietf.org
Subject: Re: [sidr] RPKI <-> allocation consistency
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: Tue, 28 Aug 2012 14:09:21 -0000

On Aug 28, 2012, at 12:23 AM, Stephen Kent wrote:

> Eric,
> 
> It seems likely that not all RPs will have the same view of INR allocation, e.g., due to differences
> in when RPs fetch data from repositories. This seems analogous to the transient inconsistencies that
> ISPs see today if they use IRR or other INR data sources, for similar reasons.

Maybe yes, and maybe no.  I don't necessarily want to diverge into that topic now (though a separate thread would be ok).  I'm more focused on the pragmatic issues that come up when implementing.  So far, my concerns seem to be pretty specific to this design, but I'm sort of seeking guidance here...

> 
> I think Rob Austein has referred to the repository system as being "loosely consistent," a reasonable target for a large scale, distributed database with entries maintained by a large group of folks.

I admit that my memory/cache consistency background is a little rusty (though I used to be quite dialed in on it), but I don't recall ever coming across that model before.  What are the access/ordering guarantees in ``loose consistency?''  Again, it only matters from a pragmatic perspective.  I am having trouble ensuring that I have the right idea here.

Thanks a lot!

Eric