Let me address just that particular NIRA-objective which this mailinglist’s
discussion is all about, its design and yes, also soon, the hereby needed
algorithmic technology as to compute consistently viewed hierarchical
topologies. For that computation only a minor enhancement of the Dijkstra is
required,
but not the entire All Links Spanning Tree (ALST). But step by step. Prior
contributing this small though important puzzle as to show the HOW, I think it’
s appropriate to show at first WHAT shall be accomplished as well as WHY
this protocol development will get us out of the BGP-trap or better said
aggregation-trap (an imaginary world-wide OSPF would have the same problems).
WHAT:The goal is that each router aquires a hierarchical network view, where
the current router is surrounded by a network of strict links, which is
surrounded by a network of looser … and looser links. For proper understand
WHY
so, let me give the following example:
Imagine to be at some street junction in Munich, Germany, and you want to
get to Sausolito.
You have available road maps, for Munich, Bavaria, Germany, Europe and a
world map which e.g. contains only 4 US-cities: New York, Chicago, L.A.,
Miami.
But none of your maps shows Sausolito !!! Here, BGP would give up!
But let’s assume, you also know the geographical coordinates of Sausolito as
well as of all nodes of all your nodes on your maps.( 1 degree precision is
enough, no minute or second precision is required.). Let’s also assume you
can by some procedure combine all your maps to a single map whereby your
closer
zoomed available map information replaces the respective part in the less
zoomed map. You may find out that L.A. is closest to your destination and use
the L.A. node as the destination node for determining the best next hop – here
to the next street in Munich towards the Munich airport. Later, you may
arrive in NY, and your current country map would also show San Francisco, but
still not Sausolito.So you would make the best next hop being bound to S.F.
Whenever you arrive in California, you may also see Sausolito on your current
state map and determine the best next hop bound to Sausolito. However, as
soon
as you have reached a router which has the same geographical coordinates like
your destination, this kind of information cannot help you any further. Yes
from now on you need guidance based on aggregated prefix information as to
determine the proper destination node on your map as we are used to. So prefix
propagation can be limited to a 1-degree-square.
Note, how powerful the„<=“ operator was, when L.A. was selected, compared
to „==“.
Mathematical analogy: If you want to find out whether the real number x is
between 0 and 1 you don’t have to compare x with all real numbers in this
interval.
Now the big thing is to build the proper hierarchical network, i.e. the
combined topology of the various maps of different zoom. Each loose link must
have the right length (weight) !
There must be a clear understanding which 1-degree-squares would be
contained within which more upper map. This is subject to „well-known“
standardization information.
Although the borders should be determined by clean longitude/latitude values
and not by political areas like counties, states, countries, continents, let
me, for better understanding, use such political terms by the following.
Example: A state map shall be built based on all county maps thereof. Each
county node router computes the (same identical) county’s contribution for
this state map, i.e that set of loose links by which it shall be represented
in the next upper topology. Hereby it is sufficient that each node of the
county knows all those county nodes that shall show up in the state map. This
information needs to be exchanged across the borders of neighboring counties
of
the same state. Not of different states; that would be required in the next
recursion cycle. The process is similar to forming a PNNI hierarchy.
Like there we would have to deal with uplinks (for combining maps of
different zoom) and hierarchical horizontal links, but there are some
important
differences. An uplink is not the aggregation of a group of border-to-border
physical links.Instead its upper end is some representative node of the
neighboring county.
Instead of the inmature Logical Group Node Representation with spokes and
nucleus etc, we would have well-computed representative topologies, in the
precisely same manner as when we have road maps for cities, counties, states,
countries, continents.
If DNS-lookup not only provided the destination IPv4-address but also the
longitude/latitude information, and if we computed for each visible node the
best next hop, which includes each visible hierarchically upper node, then we
could place the best next hop info into a matrix with 360 x 360 elements,
and could retrieve it by means of a single access (at least in case of
hierarchically upper dest. nodes)
Yesterday I received the Internet Journal with contributions about the IPv4
address depletion.
Maybe IPv4 addresses have only to be unique 1-degree-square-wide rather than
world-wide ?!
It may of course be up to the ID-utilization (besides the LOC-utilization),
but eventually this solution may also avoid this depletion dilemma.
LISP-CONS: Look, there is no political quarrel about the proper allocation
of longitudes/latitudes. They are already properly positioned and do not need
any dissemination process. By taking geographical coordinates also as address
info, then it is appropriate to speak of building some (hierarchical)
topology that follows addressing :-)
Routing churn: You will see, a loose link like Chicago---L.A. would only go
down in case of a power black out throughout the western part of the USA.
Hence the looser the link, the less the churn.
Rome was not built in one day. Nor this concept. It may take some time for
being developed.
But it has immense beneficial objectives, which really can be accomplished.
Heiner
