Re: [rrg] IPv4 & IPv6 routing scaling problems

jnc@mercury.lcs.mit.edu (Noel Chiappa) Fri, 12 February 2010 15:26 UTC

Return-Path: <jnc@mercury.lcs.mit.edu>
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 AC04828C1A2 for <rrg@core3.amsl.com>; Fri, 12 Feb 2010 07:26:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.431
X-Spam-Level:
X-Spam-Status: No, score=-6.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 9czO5uM9yX3H for <rrg@core3.amsl.com>; Fri, 12 Feb 2010 07:26:15 -0800 (PST)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id CE96928C19C for <rrg@irtf.org>; Fri, 12 Feb 2010 07:26:15 -0800 (PST)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 0830F6BE5B2; Fri, 12 Feb 2010 10:27:32 -0500 (EST)
To: rrg@irtf.org
Message-Id: <20100212152733.0830F6BE5B2@mercury.lcs.mit.edu>
Date: Fri, 12 Feb 2010 10:27:32 -0500
From: jnc@mercury.lcs.mit.edu
Cc: jnc@mercury.lcs.mit.edu
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 15:26:16 -0000

    > From: Danny McPherson <danny@arbor.net>

    > 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
    > ...
    > Each of those unique routes for a given prefix means more everything,
    > including FIB I/O.

Interesting - I'd always been concerned about the growth of the network, and
routing table, as much for stabilization times as for the sheer size of the
table.

I'd never thought much about how a larger network implies more alternate
paths, and of course with a routing architecture that uses path-vector for
loop detection, that has a pretty considerable scaling factor too, as the
number of alternate paths will grow faster than the sheer network size. (I
seem to recall an old paper, by Yakov I think it was, that speaks to that,
but I don't recall its conclusions at this point.)

(No doubt that particular blind spot is due in part to my preference for
other approaches, but I digress... :-)

    > 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.).
    > ...
    > it's important to factor both inter-domain, AND intra-domain, and
    > understand the issues with scaling in the current system.

Can you expand on that a bit?

    > all the work in IDR is about adding more state and paths and attributes
    > and features, not dealing with this scaling issue.

Well, in their defense, I can understand people wanting more features from the
routing. Unfortuntely, IMO that basic architecture is not well-suited to
adding lots of advanced features (all the easy, low-hanging, ones have
probably already been picked), but changing to a different one is going to be
a horrendous undertaking.

	Noel