> From: Danny McPherson <[email protected]>
> 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
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
