Christian,
What you wrote is doubly incorrect.
First, you missed the context:
Noel Chiappa wrote:
Needless to say, the real-time taken for this process to complete
- i.e. for routes to a particular destination to stabilize, after a
topology change which affects some subset of them - is dominated by
the speed-of-light transmission delays across the Internet fabric.
You can make the speed of your processors infinite and it won't make
much of a difference.
Christian Huitema wrote:
Since events imply some overhead in processing, message passing,
etc, one can assume that at any given point in time there is a
limit to what a router can swallow.
This is true indeed, but a) this limit has everything to do with
processing power and available bandwidth and nothing to do with speed of
light and b) the context was talking about infinite processing power
anyway.
Bottom line, you can only increase the number of routes
if you are ready to dampen more aggressively.
There is no close relation. Dampening affects route that flap. If the
new routes don't flap, all that is required is more memory to hold them
and slightly more CPU to perform lookups but not much more as the
relation between lookup time and size is logarithmic. Read below for
handling routes that flap because they indeed do.
There is an obvious "tragedy of the commons" here: if more network
want to "multi-home" and be declared in the core, then more aggressive
dampening will be required, and each of the "multi-homed" networks
will
suffer from less precise routing, longer time to correct outages, etc.
Again I don't see a relation here. Assuming that the newer prefixes in
the core flap about as much as the current ones, what is required to
handle more is to increase computing power and bandwidth in order to
keep what a router can swallow under the limit it takes a hike.
There are different elements at play that also limit the number of
core routers. Basically, an event in a core router affects all the
path that go through it, which depending on the structure of the graph
is somewhere between O(M*log(M)) or O(M.log(M)). In short, the routing
load grows much faster than linearly with the number of core routers.
I agree; the relation between processing power requirements and number
of prefixes is somehow exponential, but back to the real world:
Years there was a frantic forklift upgrade business to get the biggest
baddest BFR from vendors even before the paint was dry, and this
happened because indeed we were starving for more CPU and more memory.
This does not happen today. As Stephen points out, even the little guys
aren't complaining anymore and vendors don't even put the latest
technology they can in their products because nobody's screaming for it
anymore.
In short: the IPv6 idea of reducing the size of the routing table was
necessary if IPv6 had been deployed and replaced v4 5 years ago. We have
missed the launch window and as of today this problem solved by time; I
hear that we could handle a million prefixes with today's technology.
If it takes a THz processor to handle 10 million prefixes and a 100THz
one to handle 100 million prefixes, I don't care as long as said
processors are on the shelf at Fry's for $200 a piece and on a vendor's
Sup for $100K a piece.
Michel.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf