[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: PI/metro/geo [Re: The state of IPv6 multihoming development]




|   However, if we can build a naming 
|   hierarchy in which
|   most multihomed networks connect to two places that are 
|   very close in
|   the hierarchy, this buys us aggregatability. Obviously, 
|   this is never
|   going to be a long term solution, but it makes for a very good short
|   term solution as it can work pretty much immediately by 
|   just adopting a
|   new address allocation scheme and some creative BGP filtering.


Unfortunately, that's not going to be so simple.  What happens
when some organization that spans geographic areas decides
that they want to multihome through providers on either sides
of their particular continent?  Or even different continents?


|   It's hardly the same thing, as perpetual motion is something that
|   doesn't work in theory or practice, no matter which way you 
|   slice it.
|   (Obviously I'm not saying something can't move "forever", but rather
|   that you can't derive energy from something forever.) You can make
|   routing work in any way you want, it's just that some ways 
|   are cheaper
|   or faster than others. That's one of the problems with 
|   networking: even
|   if done wrong it can work so people don't even see they're doing it
|   wrong. But then sometimes this is an advantage as you can still get
|   things to work even if there is a reason why it can't be done right.


Exactly.  What we want to build is a routing architecture that is 
never going to have to be replaced.  It's too difficult to reach in and
change it, so you'd like it to be done right the first time.  Since
scalability is key and the way to scale is to keep the overhead low,
a solution that has higher overhead is sub-optimal and to be avoided.

Geographic aggregation is fine if the topology does indeed provide
a convenient aggregation boundary.  But in many cases, there will be no 
such convenient boundary.  What do you do?  You cannot make an exception
and flat route any enterprise that has such links, because then their
overhead dominates the cost of all routing and you're not sufficiently
scalable.

Now I admit that you can warp the virtual topology by tunneling in such
a way that any two points on the graph are adjacent.  But by doing this,
you are abstracting routing away from the physical topology and you're
insuring that routing never makes a correct decision with respect to 
that physical topology.


|   Simple = using little information. Flat routing gives you all the
|   information you need. Depening on aggregates leads to less optimal
|   forwarding decisions.


Routing Theorem #1.  ;-)


|   > The K/K paper does show that, given certain reasonable 
|   assumptions about
|   > topology, that the increase in path length due to their 
|   information hiding
|   > scheme grows very small as the network gets larger, 
|   although of course their
|   > whole paper is about mono-metric systems.
|   
|   It seems to me you have some very clear opinions on how this should
|   work. Can we expect a draft?


You might surf around for "Nimrod" and "Chiappa".  There's about an
entire book's worth of material around about this.

As has been remarked elsewhere, we've been around and around and
around on this topic for the last decade.  We have no new answers,
only the bitter pill of reality that we cannot all seem to swallow 
at the same time.

Tony