Re: [rrg] Geoff Huston's BGP/DFZ research - 300k DFZ prefixes are the tip of the iceberg

Robin Whittle <rw@firstpr.com.au> Mon, 15 March 2010 03:16 UTC

Return-Path: <rw@firstpr.com.au>
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 95C443A688B for <rrg@core3.amsl.com>; Sun, 14 Mar 2010 20:16:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.614
X-Spam-Level:
X-Spam-Status: No, score=-1.614 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SARE_SUB_OBFU_Z=0.259]
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 bcl5NnFbNFxT for <rrg@core3.amsl.com>; Sun, 14 Mar 2010 20:16:05 -0700 (PDT)
Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id E69853A6852 for <rrg@irtf.org>; Sun, 14 Mar 2010 20:16:03 -0700 (PDT)
Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id E2422175A41; Mon, 15 Mar 2010 14:16:09 +1100 (EST)
Message-ID: <4B9DA680.3000503@firstpr.com.au>
Date: Mon, 15 Mar 2010 14:16:16 +1100
From: Robin Whittle <rw@firstpr.com.au>
Organization: First Principles
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: paul@jakma.org
References: <201002180040.o1I0eAr0027055@cichlid.raleigh.ibm.com> <4B837DB1.8050009@firstpr.com.au> <201002242234.o1OMYlJV031162@cichlid.raleigh.ibm.com> <CD964388-4B88-4B58-82D5-88A7A11A5095@apnic.net> <4B8FB78D.7060903@firstpr.com.au> <4B9B068A.3030004@firstpr.com.au> <alpine.LFD.2.00.1003141730020.4735@stoner.jakma.org>
In-Reply-To: <alpine.LFD.2.00.1003141730020.4735@stoner.jakma.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: RRG <rrg@irtf.org>
Subject: Re: [rrg] Geoff Huston's BGP/DFZ research - 300k DFZ prefixes are the tip of the iceberg
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: Mon, 15 Mar 2010 03:16:07 -0000

Short version:   Paul appears to think there is no routing scaling
                 problem.


Hi Paul,

Thanks for your reply, in which you wrote:

>> Geoff's research is:
>>
>>> In the "Re: [rrg] draft-narten-radir-problem-statement-05.txt" thread
>>>   http://www.ietf.org/mail-archive/web/rrg/current/msg06152.html
>>>
>>> and in "BGP in 2009":
>>>   http://www.potaroo.net/presentations/2010-02-01-bgp2009.pdf
> 
> Those are the ones. I'd read that email too, but had forgotten of its
> existence in replying to this thread - thanks for highlighting it.

Also, as just mentioned by Amund Kvalbein:

   BGP churn evolution: A perspective from the core

http://simula.no/research/nd/publications/Simula.nd.435/simula_pdf_file


>>  It's possible that the current architecture of the internet is
>>  holding back growth that should otherwise be there.
>>
>> Yes.  If we concentrate only on non-mobile networks, there are two
>> broad aspects of the routing scaling problem:
>>
>>  1 - The unreasonable, arguably unscalable, burden placed on the
>>      DFZ routers individually, and on the DFZ control plane in
>>      general, by the set of end-user networks which currently
>>      get portability, multihoming and inbound TE by the only
>>      means available: getting their own space and advertising it
>>      as PI prefixes in the DFZ.
> 
> Well, why is it "unreasonable" exactly? If the system works and is
> scalable, what's the problem?

I understand that many people regard it as unreasonable that the act
of some end-user network somewhere in the world advertising its own
prefix in the DFZ (typically their PI prefix, but also sometimes a
prefix they got as PA space from an ISP other than the one they are
now advertising it through) causes a real burden on all DFZ routers
and on the DFZ control plane in general.  This is because the people
who run these DFZ routers receive no payment, and little or no
benefit, from that prefix being advertised in the DFZ.  Cumulatively,
these prefixes add up to the single biggest identifiable problem at
the heart of the routing scaling problem.


> It's only unreasonable if there's a /good/ way to keep those prefixes
> out of the DFZ (i.e. good in the sense that it's at least as good as
> what we have today). If such a way exists, then that's great - we should
> definitely research ways to improve routing, of course.

This is what we have been doing since the RAWS workshop in 2006, and
some folks have been researching this since before RAWS.


> However, it does not seem justified to say the current routing
> architecture has a scaling problem. 

Whoah . . .  You are arguing against the positions of pretty much
everyone who is involved in the RRG.  Please see 17.2.x of:

  http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html

for a summary of my understanding of the nature of the problem.  See
also:

   http://tools.ietf.org/html/rfc4984
   http://www.iab.org/about/workshops/routingandaddressing/
   http://tools.ietf.org/html/draft-irtf-rrg-design-goals-01
   http://tools.ietf.org/html/draft-narten-radir-problem-statement-05

> So it would not be justified, at
> thhis time (AFAICT), to excuse inefficiencies added by proposed changes
> on the basis that there's a pressing problem with the current architecture.

You have asserted there is no routing scaling problem, but you
haven't argued why this is the case - such as by arguing in detail
against the arguments presented in the five above documents.


>>  2 - The much larger number of end-user networks which could use 2
>>      or more ISPs and which want or need portability, multihoming or
>>      inbound TE but don't have it because they are unable to get the
>>      space and advertise it.  (Perhaps a subset of these could do
>>      it, but don't because they known how unscalable it is.)
> 
>> The growth in BGP advertised PI prefixes is the simplest measure of
>> the first aspect - which is like the tip of the iceberg.  The less
>> visible part is point 2, like the main body of the iceberg.
> 
> Well, the internet is going to grow. That's hardly a surprise. What's
> the problem with the internet growing? Geoff's results seem to show that
> the growth is well within the scaling abilities of the 'net.

That's not what most RRG people think, and the above documents
include many arguments for why we think this.


>> So even if Moore's Law keeps up in some acceptable manner with the
>> pace of growth in the number of PI prefixes in the DFZ, this doesn't
>> help with point 2 or with mobility.
> 
> Sure, but:
> 
> a) If the scope of the problem suddenly is "those very small
>    networks which want portability/multi-homing but aren't big enough
>    to get an AS and PI", then:
> 
>    - it's a much, much smaller problem in terms of affected parties
>      than "internet routing doesn't scale"

It is an instance of the needs of many networks not being met by
current techniques.  Since there is a growth in this number of
networks, this is arguably a scaling problem.


>    - it's not clear even that such networks exist to any
>      meaningful extent (OK, I'm geeky enough that I'd love portability
>      and multihoming for my home network), i.e. if this is the
>      problem being solved then that changes the economic incentives
>      of roll-out.

I understand the RRG's aims are not just to get existing
PI-advertising end-user prefixes to change to using a new arrangement
with less burdens on the DFZ control plane, or to cope with the
expected growth in networks of the same nature (same size, same
needs, same resources).  I understand our aim includes providing a
more accessible and highly scalable method by which a larger number
of end-user networks can get portability, mulithoming and inbound TE
than those which currently get it via advertising their own prefixes
individually in the DFZ.

Furthermore, we are aiming to find a better, scalable, form of mobility:

  http://www.irtf.org/charter?gtype=rg&group=rrg

    At the moment, the Internet routing and addressing
    architecture is facing challenges in scalability, mobility,
    multi-homing, and inter-domain traffic engineering. Thus the RRG
    proposes to focus its effort on designing an alternate
    architecture to meet these challenges.


> b) If the problem is that fewer networks today can get PI, then we
>    should be able to see a change in the mode of prefix growth in the
>    historical data. However, TTBOMLK, we don't see this in the data.

The mapping for TTBOMLK was not in my cache.  Google resolved my
query in a fraction of a second:

  To The Best Of My Knowledge

Its is not that fewer networks advertise PI prefixes today than in
the past, but that there is a growing number of networks wanting
portability, multihoming and inbound TE, that only a subset of them
are getting this at all (through advertising their PI prefixes or PA
prefixes, individually), that there are already too many who can't
get these benefits and that due to growth in the number of networks
of this kind, more and more cannot get these benefits at all - while
the subset who do get these benefits do so in a way which (we
believe) involves unfair and unsustainable burdens on others.


> Basically, if there's a problem then where is the evidence of it, now
> that we seem to have initial evidence to suggest otherwise?
> 
>> Sorry I haven't had time to revisit our discussions in early
>> February.  I have a backlog of RRG messages to read and respond to -
>> mainly discussion following from my critiques of several architectures
>> - and I need to give priority to paying work.
> 
> No worries, that was just speculation on my part anyway. :)
> 
> regards,

OK - in the context of the work which has been done so far, I suggest
that your assertion that there is no routing scaling problem is just
speculation too!

  - Robin