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@he.net http://www.he.net | +-----------------------------------------------------------------------+