IPv6 news

Sun Oct 16 05:11:03 UTC 2005

On Sat, 15 Oct 2005, John Payne wrote:
> On Oct 15, 2005, at 3:29 PM, Tony Li wrote:
> >> So the IETF identified 4 reasons to multihome.  Of those 4, shim6  
> >> ignores at least 2 of them (operational policy and cost), and so  
> >> far as I can see glosses over load sharing.
> >
> > If you have a solution that satisfies all requirements, you should  
> > contribute it.  Shim6 is indeed a partial solution to the stated  
> > requirements.  There was no tractable solution found to all  
> > requirements, and to not solve any of the issues was seen as  
> > basically fatal.
> 
> I don't have an acceptable solution... however, I am getting tired of  
> shim6 being pushed as *the* solution to site rehoming, when at best  
> it's an end node rehoming solution.

The essential problem comes down to routing topology information... all
the "scalable" solutions obscure or reduce this information in order to
work.

Not reducing the information means either having the same number of
routing table entries as the number of multihoming sites or enforcing some
kind of theoretical heirarchical structure (many of the original IPv6
papers had this pipe dream spelled out for how to handle multihoming)
either based on geography or what amounted to a hegemony of top level
providers.  The heirarchical solutions haven't already been implemented
(with IPv4 or IPv6) because it costs alot to build networks, many networks
have spent too much, and market forces have "optimized" (if that is what
you call the current state of affairs) to a set of providers that been
able to stay in business.  Also if your business is providing
connectivity, you are loath to enshrine via protocol somebody else in a
strategically dominant position... it would eliminate any chance of
being able to manage your profit margin.

So... any proposal you here from somebody that says the current IPv4 BGP
solution for multihoming is unworkable due to the fact that it won't scale
(an interesting claim depending on where on the curve you think market
penetration of the Internet is, coupled with the question how many more
sites multihoming do you want to support (this appears to the result of
complex economic interactions, not anybody's planning)) you can count on
routing topology information being reduced.  Don't be suprised, its
necessary to achieve their design goal.  You can't have both full topology
information (all the path information) and less information (replacing the
paths with something simpler).

For example, shim6 sounds like it replaces substitues all kinds of path
selection information with latency.  The amusing thought came to mind that
the equivalent of current AS prepending for shim6 sites would be to get a
box to introduce additional latency on the path they want to reduce
traffic on.  (There are companies that sell such optical devices for
testing.)  (perhaps I'm totally wrong about how shim6 works, my
appologies to people working on it)

Anyway, it's useful to think about what you want in terms of topology
information and where you want it.  When is it necessary to have real
topology information and when would something else suffice (depending on
what you are doing (for example live on demand video streams)), etc.  
Parameters are things like session surviability, time to convergence, etc.  
You have alot more room if you say that its ok if existing sessions can be
interruped and reconnect.  Unfortunatley, alot of the solutions look like
something other than TCP meaning you aren't helping the existing
applications.

I don't envy anybody trying to magic away topology information.  I can see
solutions if we replace TCP.  Whatever you implement on the servers, I
don't see how session surviability can be included without cooperation
from the clients or the clients routers.

Mike.

+----------------- H U R R I C A N E - E L E C T R I C -----------------+
| Mike Leber           Direct Internet Connections   Voice 510 580 4100 |
| Hurricane Electric     Web Hosting  Colocation       Fax 510 580 4151 |
| mleber at he.net                                       http://www.he.net |
+-----------------------------------------------------------------------+