> From: Daniel Senie <[EMAIL PROTECTED]>
> Now we're busy pushing technology to ensure routing table sizes won't
> increase because the present generation of hardware can't handle larger
> routing tables. Are we being a bit short-sighted?
No. The issue with routing table size is not the memory required to store it,
but the stabilization time when a topology change happens. That is a factor
of a number of things, including the speed of light, which isn't going to get
faster any time soon... :-)
Noel
PS: The following bits and pieces of old emails which I dug up talk
about this in a little more detail:
think about what factors go into the equation which describes the
stabilization time curve.
(I say "curve" since a mere average is useless; if you have design A in
which it always stabilizes in 3T, and design B in which is sometimes
stabilizes in T and occasionally in 100T, the *average* for both may be
the same, but in real service you'd probably prefer the predictability
and boundedness of design A.)
There are factors in there *other* than node processing power, such as
i) the propogation time of updates (which is heavily dependent on
the speed of light), and ii) the number of nodes in the network
through which the updates have to propogate.
After the above, what share of the stabilization time is affected by
processing power in the nodes? Put another way, what does your model
predict for the stabilization time if you have *infinite* processing
power in the nodes? If your answer is zero, your model has gone wrong
somewhere.
As an insight, assuming processing power is infinite, how does the
stabilization time vary in the number of nodes in the graph? (Hint:
what is the average path length in a random graph of N nodes?) ...
is the stabilization time linear in the number of nodes through which
the computation has to pass, or what?
Assuming processing power is infinite, how does the stabilization time
vary in the number of nodes in the graph? If the number of nodes is
held constant, what is the effect of propogation time on the curve? Do
you know any way, chearp or otherwise, to reduce propogation times?
Stabilization time is larger in a larger network. Full stop. A larger
network will *also* have more topology changes per unit time. As a net
gets larger, you are caught between two closing jaws: increasing
stabilization time, and decreasing MTB topology changes. There are
solutions, but throwing more processing power in the routers at the
problem isn't it.
...
There *are* some ways to deal with these problems (e.g. by bounding
the number of nodes that updates have to propogate through, by careful
design of topology and abstraction hierarchy, and limiting inter-level
linkage) but they demand a more engineered (on the large,
inter-provider scale) net than we have now.
