[ppml] 2005-1 status

[Tony Li]

> OK, Tony...it's an architecture problem... what's the solution then.  What
> architectural change can elimate the scaling problem posed by an expanding
> PI endsite population.... or is there an alternative to PI that allows
> flexibility of endsites to benignly exchange service providers?


Well, the basic problem that we have to confront is that to keep the
routing subsystem scalable, we can only relay a relatively small amount
of information, regardless of the size of the network.  Yes, I grant you
 that this amount can and will grow slightly over time and that Moore's
law may (or may not) help us out, but any way we look at it routing must
scale about logarithmically or so.

For that to happen, we need to be able to create topological
abstractions on the network.  We need to be able to take a map of the
network, draw a big circle around various parts of it and give
everything in that circle a 'handle' for us to route on.

Obviously, PI space flies right in the face of this.  Every single PI
allocation that is ever made comes at a constant cost to the network and
 covers a fixed portion of the network.  Unless PI allocations
effectively never happen, any reasonable PI allocation allotment will
quickly cause a routing information explosion.

Example 1: Suppose that a PI allocation gets a /48.  Then the routing
infrastructure needs to support 2^128 / 2^80 = 2^48 (~ 3e14) information
entries.  Further, that allocation is already enough to support 2^80 (~
1e24) hosts.  The current Internet is something like 3e8 hosts, so this
is already a very large allocation.

Example 2: We could make PI allocations much larger, such as a /32, but
then we limit either the size of the network or the number of
enterprises that are allowed to participate.  Even then the routing
issue is intractable using today's technology (~ 4e9 entries).

The basic conclusion here is pretty much straightforward: we cannot
responsibly make PI allocations without either blowing up the routing
subsystem or squandering our hard-fought extra address space.

Given this, it follows that we need an architecture that allows us to
renumber or multi-home easily.  There have been many that have been
discussed and I won't re-hash them all here, as this mail is long enough
already.

Regards,
Tony