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.
- [rrg] Locator Toni Stoev
- Re: [rrg] Locator Fred Baker
- Re: [rrg] Locator Noel Chiappa
- Re: [rrg] Locator HeinerHummel
- [rrg] Locator: routing scalability Toni Stoev
- Re: [rrg] Locator: routing scalability Paul Jakma
- Re: [rrg] Locator: routing scalability Toni Stoev