|
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
|