Re: [rrg] Locator: routing scalability

Paul Jakma <paul@jakma.org> Fri, 15 May 2009 21:33 UTC

Return-Path: <paul@jakma.org>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BB6F3A6A57 for <rrg@core3.amsl.com>; Fri, 15 May 2009 14:33:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level:
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k82emSkbCiC5 for <rrg@core3.amsl.com>; Fri, 15 May 2009 14:33:44 -0700 (PDT)
Received: from hibernia.jakma.org (cl-9.dub-01.ie.sixxs.net [IPv6:2001:770:100:8::2]) by core3.amsl.com (Postfix) with ESMTP id BB4543A69C5 for <rrg@irtf.org>; Fri, 15 May 2009 14:33:43 -0700 (PDT)
Received: from melandri.gla.jakma.org (melandri.jakma.org [81.168.24.37]) (authenticated bits=0) by hibernia.jakma.org (8.14.3/8.14.3) with ESMTP id n4FLYuG7018665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 May 2009 22:35:10 +0100
Date: Fri, 15 May 2009 22:34:56 +0100
From: Paul Jakma <paul@jakma.org>
To: Toni Stoev <irtf@tonistoev.info>
In-Reply-To: <200905141131.22465.irtf@tonistoev.info>
Message-ID: <alpine.LFD.2.00.0905152159580.12032@melandri.jakma.org>
References: <d59.4031ac99.373bd5bc@aol.com> <200905141131.22465.irtf@tonistoev.info>
User-Agent: Alpine 2.00 (LFD 1167 2008-08-23)
Mail-Copies-To: paul@jakma.org
Mail-Followup-To: paul@jakma.org
X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.1.1 (hibernia.jakma.org [212.17.55.49]); Fri, 15 May 2009 22:35:12 +0100 (IST)
Cc: IRTF RRG <rrg@irtf.org>
Subject: Re: [rrg] Locator: routing scalability
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 May 2009 21:33:45 -0000

On Thu, 14 May 2009, Toni Stoev wrote:

> Does locator have to facilitate routing with its structure?
> My answer is: yes, it must.

I have a question, a stupid one probably... Is the following thinking 
of mine correct?:

If we encode routing information into the locator somehow, then this 
implies the 2 are tied together, and that (at least) the initial 
top-level hierarchy of internet routing is fixed for the life-time of 
the locator. So this implies either one or more of:

- that the lifetime of locators be short, and that they are
   re-calculated/re-assigned frequently enough to have a sufficient
   level of reachability between hosts on the internet.

   (e.g. imagine a scheme that assigned locators empirically, by
    examining the structure of the internet and calculating a
    spanning-tree that approximated a power-law distribution
    as good as possible and then assigning locators in an according
    fashion, thus maximising the aggregation of routing information.

    I think there may be papers describing such things, but I'm not
    sure there are RRG proposals ???).

- fairly long-lived, indeed static locator assignments. This implies
   a quite broad and flat, top-level routing table. This is basically
   what we have today, if ASes advertised just one prefix.

   Proposals under this model generally split routing into a 2-tier
   system: the flat, top-level routing table + a secondary table of
   networks behind the top-level locators (either aggregated locators,
   or remapped/tunneled somehow)

Is this right so far?

If so, and if the prevailing proposals so far are of the static 
top-level kind, then do know if a flat top-level is sufficiently 
scalable? Is there any data/work on how fast this top-level might 
grow? To what extent is the AS growth reflective of how that 
top-level might grow? To what extent is the transit-AS growth 
reflective of it?

I ask because AS growth might not be linear:

 	http://www.potaroo.net/tools/asn32/

though transit-AS growth is unclear (it doesn't grow much in fact, so 
its perhaps impossible to get a trend from it):

 	http://www.potaroo.net/ispcol/2009-03/bgp2008.html

Basically, what I wonder is whether a static top-level 
locator->routing mapping is sufficient to meet the scaleability 
requirement?

If it is not, then facilitating routing with the locator is just a 
delaying tactic - a more dynamic system would eventually be 
necessary.

If it is sufficient, great, of course - any dynamic system would by 
definition be more complex.

(There may be ways of statically assigning locators according to some 
kind of power-law distribution - but this means impressing some kind 
of order onto ISPs, which probably isn't socio-politically 
tractable).

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
Neutrinos are into physicists.