Subject: Re: [rrg] IPv4 & IPv6 routing scaling problems

From: [email-masked] (Noel Chiappa)
Date: Fri, 12 Feb 2010 10:27:32 -0500 (EST)

> From: Danny McPherson <[email-masked]>

    > 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

---

From: Danny McPherson <[email-masked]>
Date: Fri, 12 Feb 2010 08:37:06 -0700

> Can you expand on that a bit?

I think the slides here illustrate some of this pretty well, and even
illustrate how implementation optimizations that result in systemic 
state and churn are a very bad idea - but most operators don't complain
because they have no CLI-esque visibility into just how broken:

<http://www.ietf.org/proceedings/74/slides/grow-6.pdf>
<http://www.tcb.net/rr-thing.pdf>

> a horrendous undertaking.

Yep, agreed.  

The thing is, network operators are coin-operated, rightly so, and
deploying things like IPv6 before IPv4 is exhausted, or optimizing 
routing designs instead of developing new bottom-line or revenue 
generating features, just doesn't make much sense.  Any incentive 
model outside of 1-3 years to operate or optimize a network service
substrate just doesn't get much attention.

-danny