On Thursday, February 27, 1997 8:52 AM, Mr. Dana Hudes[SMTP:dhudes at graphnet.com] wrote:
@ IP address allocation cannot be done willy-nilly. You cannot discuss
@ allocation without considering routing . Aggregation is the name of
@ the game, or we will have monster route tables of 100K routes. Right
@ now, I am not aware of any vendor capable of handling more than 50K
@ routes. It may well be that the Routing Arbiter and Route Server, as
@ applications running on a Sun, could handle more by throwing more RAM
@ and disk into the system but regular routers have no virtual memory
@ and limited slots for physical RAM. The IETF solution to this looming
@ problem is CIDR as all should well know.
@ By using a hierarchical allocation policy we have some prayer of
@ aggregating announcements at the various NAPs/MAEs/IXPs. If customers
@ run around switching providers and not renumbering then holes start
@ to appear in the CIDR blocks. AT least by considering vague geography
@ by continent we have the more specific in, e.g., Europe, for European
@ routes which are aggregable in other continents.
@ Dana Hudes
@ Senior Network Engineer
I agree, "IP address allocation can not be done "willy-nilly".
As the U.S. NSF InterNIC has proven, IP addresses can be allocated and
NO GUARANTEES of routing are provided.
The registry leases "uniqueness".
People who obtain a lease on those addresses then have to take
them to the people who run the network. That group can have different
policies, costs, etc. It is that group that has to deal with the issue
of routing tables, etc.
To try to tie all the groups together does not produce a scalable
system. Bottlenecks form and allocations are made based on
the wrong reasons. You would see this same type of situation
if the FAA controlled ticket sales on airplanes as well as the
size of gates and ticket counters. You would end up with one
or two people sitting in a control tower watching planes going
nuts trying to control the entire industry that would bottleneck.
JimFleming at unety.net
JimFleming at unety.s0.g0 (EDNS/IPv8)