> Well, it is a problem that you have to solve anyhow, as soon as the same
> service is available from multiple servers accross the Internet.
agreed that it's highly desirable to solve the problem. what I'm not
so sure of is whether it's highly desirable to make a solution to
this problem part of the critical path for IPv6 deployment.
> What is
> the difference, from a host point of view, between choosing among interface
> addresses aa, ab, ac, ad of server A and choosing between interface
> addresses aa, bb, cc and dd of servers A, B, C and D?
in the former case, you're just concerned about choosing the best path.
in the latter case, you're also concerned with server load.
> If you wanted to
> solve the latter at the routing level, then you should allocate an anycast
> address to every group of servers that provide the same service (e.g. a
> copy of the same DNS domain, of the same Web sites, or a gateway to the
> same mail systems.)
I don't think you can solve the latter problem at the routing level,
unless you want to somehow convert server load factors into routing
metrics. Also, an anycast based solution would appear to preclude
any possibility for server selection algorithms tuned to the needs
of the application - say, if for a particular application bandwidth
or low packet loss are more important than latency.
> Let's face it: the odds of solving a scaling problem from the edges of the
> network, from the hosts, are much better than the odds of scaling the
> routing system.
I like the general idea of doing more routing work at the periphery, but
it's not clear to me that this is strictly an edge-vs-core tradeoff.
And I do see merit in DNS-based server selection, but I don't think it's
going to be effective enough in the near term to replace traditional
multihoming.
Keith
