Subject: [RRG] Not address but topology aggregation

From: [email-masked]
Date: Sun, 15 Jun 2008 06:12:00 EDT

I have been observing the current v4/v6 discussion.The v4- scalability  
problem is not solved just by flocking to v6. The RAWS report even mentioned the  
expectation that the problem would increase at least by factor 4.
And this is not a surprise: v4 and v6 are both  committed to the  same 
paradigm namely "address aggregation" which is the true cause of the  problem (and 
not multihoming, natural growth, end user device diversity,etc.  which only 
report the problem).
I showed how to avoid this problem by sketching a routing protocol  which 
yields a sparsed internet network view such that by the help of 2 geo-data  
octets forwarding at least to the destination square degree can be done without  
the prefix-based routing table, instead by means of a single-index  table  
lookup.My problem: How to squeeze out 2 octets in the IP header?
By means of an optional parameter?  By means of an outer header   just as is 
granted to LISP? By some shim (a single MPLS label has even  4 octets !!! )
The next possibility is by means of IPv6. Note, 8 octets are enough to  
identify any square centimeter on the surface of this planet. With the remaining  8 
octets a hell of a lot network elements can be identified on each such square 
 centimeter. By assuming that only 1 router is hereby included (in this  
destination square centimeter), routing from ingress to egress can be done by  one 
single table lookup  at each router! ( I am sure that less granularity  would 
do as well :-). This also means: No SINGLE address prefix building is  needed 
any more ! (Exception: For building tunnels as to interconnect isolated  
knowledgable subnetworks during an initial phase of deployment)
 
I will continue to seek and to hope getting a chance as to demonstrate my  
concept. Yes, geo-data plays an important role, but not the fundamental one  
(obviously there are other geo concepts as well). The fundamental  difference 
with the current paradigm however is the automated topology  aggregation. I am 
still about to make progress and have regretfully learned  that hierarchy a la 
PNNI or NIMROD is not a big help.
 
I know that I hereby take an "out-law"-position. I do NOT say "forget  
Dijkstra", instead "improve and use Dijkstra for the construction of aggregated  
topologies". Yes, I do say " away with address aggregation and away with  
distance vector".  A GOOGLE MAP user  will understand my "vision" as  well as my 
disappointment about PNNI/Nimrod :-)
 
The benefits are much more than the elimination of the scalability  problem. 
A routing technology could be enabled such that loops become  yesterday's 
ghosts and the TTL, as used today, a fossil from the past.
Multipath  and even much more than ipfrr is doing could be enabled  intra- 
AND inter-domain wise.
Multihoming can adequately and easily be done by employing different  
dest.geo-data of the respective dest.router.
Address depletion is not a problem. The end device must be unique just at  
any dest. router.
Mobility becomes very easy. The routing churn is not of O(r²) with r =  
distance to the originator, but of 1/O(r²)
Traffic balancing TE could be done while SEEing and dealing with that  
traffic originating subnetwork whose traffic would pass the current router, and  
finally: young students may get a powerful basis for developing their own  ideas.
 
Heiner