Re: [rrg] IPv4 & IPv6 routing scaling problems

Danny McPherson <danny@arbor.net> Fri, 12 February 2010 14:45 UTC

Return-Path: <danny@arbor.net>
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 C32D13A71E0 for <rrg@core3.amsl.com>; Fri, 12 Feb 2010 06:45:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 fankkUTh2-lt for <rrg@core3.amsl.com>; Fri, 12 Feb 2010 06:45:43 -0800 (PST)
Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by core3.amsl.com (Postfix) with ESMTP id AF6023A71D7 for <rrg@irtf.org>; Fri, 12 Feb 2010 06:45:43 -0800 (PST)
Received: from gateout02.mbox.net (gwo2-lo [127.0.0.1]) by gateout02.mbox.net (Postfix) with ESMTP id 827CA4BC8C6 for <rrg@irtf.org>; Fri, 12 Feb 2010 14:47:01 +0000 (GMT)
Received: from s1hub2.EXCHPROD.USA.NET [165.212.120.254] by gateout02.mbox.net via smtad (C8.MAIN.3.61A) with ESMTPS id XID890oBLovB0842Xo2; Fri, 12 Feb 2010 14:47:01 -0000
X-USANET-Source: 165.212.120.254 IN danny@arbor.net s1hub2.EXCHPROD.USA.NET
X-USANET-MsgId: XID890oBLovB0842Xo2
Received: from [192.168.1.64] (97.118.239.19) by exchange.postoffice.net (10.120.220.32) with Microsoft SMTP Server (TLS) id 8.2.234.1; Fri, 12 Feb 2010 14:45:55 +0000
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Apple Message framework v1077)
From: Danny McPherson <danny@arbor.net>
In-Reply-To: <75cb24521002051030v29b9183cq823c0d59b70fffe8@mail.gmail.com>
Date: Fri, 12 Feb 2010 07:46:15 -0700
Content-Transfer-Encoding: quoted-printable
Message-ID: <0503A92D-D633-4C19-8FA6-3CFD9FD5CD77@arbor.net>
References: <32101_1265251077_ZZg0Q4CoNw0Le.00_4B6A32F8.4080800@firstpr.com.au> <48225D32-CD3B-4AE0-BFC6-5535B12BF519@wisc.edu> <75cb24521002041918l4820395dh9524b280a2b00d32@mail.gmail.com> <672B9734-BF8B-4B18-933C-4DEEC49ACA32@castlepoint.net> <75cb24521002051030v29b9183cq823c0d59b70fffe8@mail.gmail.com>
To: RRG <rrg@irtf.org>
X-Mailer: Apple Mail (2.1077)
Subject: Re: [rrg] IPv4 & IPv6 routing scaling problems
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, 12 Feb 2010 14:45:44 -0000

On Feb 5, 2010, at 11:30 AM, Christopher Morrow wrote:

>> [2] Let's not forget that it's not *just* routes in BGP, but just as importantly *paths* that has negative scaling implications, as well, on the control plane, (note slide 13):
>> http://www.ietf.org/proceedings/74/slides/grow-6.pdf
> 
> i agree that it's not just routes, it's not just paths, it's not just
> speed of change (of either of the two previous items)...
> 
>>    ... and, keep in mind, there are things on the horizon (i.e.: add-paths, SIDR?) that may add _more_ state to be pushed around in BGP (should they see widespread deployment), which is scary.  OTOH, on a more optimistic note, there are some additional enhancements that can make BGP more efficient, however it's unclear how much benefit several of the enhancements may provide as not all of them have been studied
> 
> also agree with this, adding more state or more memory/cpu
> requirements to existing systems is full of unknown consequences.

Not surprisingly, I completely agree with this as well.  It's not
just the number of prefixes in the current system, it's the number
of unique routes (paths) to each prefix, the former of which is 
often 20x or more the number of unique prefixes in the system (today!), 
and any time any one of those prefixes has state change, all the paths
see some piece of churn internal to a routing domain (and often 
inadvertently trigger external artifacts like suppression from 
damping, etc.).  

Each of those unique routes for a given prefix means more everything, 
including FIB I/O.  IPv6 during long term transitional coexistence with
IPv4 is just going to compound this.  

Surprisingly, all the work in IDR is about adding more state and
paths and attributes and features, not dealing with this scaling issue.
If the goal here is scalability, it's important to factor both inter-
domain, AND intra-domain, and understand the issues with scaling in 
the current system.

-danny