Subject: PI space (was: Stupid NAT tricks and how to stop them)

From: [email-masked] (Noel Chiappa)
Date: Wed, 29 Mar 2006 15:39:01 -0500 (EST)

> From: "Michel Py" <[email-masked]>

    >> We aren't *ever* going to give everyone PI space (at least, PI space
    >> in whatever namespace the routers use to forward packets) ...
    >> Routing (i.e. path-finding) algorithms simply cannot cope with
    >> tracking 10^9 individual destinations (see prior message).

    > I think you're dead wrong on this. This reasoning was valid with 10^8
    > Hz processors and 10^8 bytes of memory it's no longer true with 10^11
    > or 10^12 Hz processors and memory (we're almost at 10^10 cheap ones).

The last time I heard, the speed of light was still a constant. And the
current routing architecture is based on distributed computation.

I.e. router A does some computing, passes partial results to router B, which
does some more computing, and in turn passes the partial results to router C.
After some amount of this back and forth across the network, the route is
eventually computed and installed.

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.

	Noel

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 29 Mar 2006 22:10:45 -0600

Thus spake "Noel Chiappa" <[email-masked]>
>    > I think you're dead wrong on this. This reasoning was valid with
>    > 10^8 Hz processors and 10^8 bytes of memory it's no longer true
>    > with 10^11 or 10^12 Hz processors and memory (we're almost at
>    > 10^10 cheap ones).
>
> I.e. router A does some computing, passes partial results to router B,
> which does some more computing, and in turn passes the partial
> results to router C.  After some amount of this back and forth across
> the network, the route is eventually computed and installed.
>
> 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.

Nothing has changed here.  The propogation of an individual route is limited 
by the speed of light (in fiber or copper), yes, but faster CPUs and bigger 
memories mean that more of those routes can be propogating at the same time 
with the same or less effect than a few years ago.

The IPv4 core is running around 180k routes today, and even the chicken 
littles aren't complaining the sky is falling.  Compare to how many routes 
were around pre-CIDR and the resulting chaos.  Routers have gotten much, 
much better since then, and in most cases they're using technology 5+ years 
behind the PC market (200MHz CPUs, SDRAM, etc.).  We'd have to seriously 
screw up to run afoul of today's limits, and the vendors can easily raise 
those limits if customers demand it (though they'd much prefer charging 
$1000 for $1 worth of RAM that's too old to work in a modern PC).

S

Stephen Sprunk        "Stupid people surround themselves with smart
CCIE #3723           people.  Smart people surround themselves with
K5SSS         smart people who disagree with them."  --Aaron Sorkin