[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft-ietf-shim6-proto-05.txt
A brief diversion regarding anycast follows. We swing back on-topic
back towards the bottom.
On 9-Nov-2006, at 17:11, Brian E Carpenter wrote:
Joe Abley wrote:
On 4-Nov-2006, at 19:13, Brian E Carpenter wrote:
Are you talking about anycast? That clearly breaks in mobility
and multihoming
scenarios, and can only be used for fairly classical fixed servers.
See draft-ietf-grow-anycast-04.txt.
Anycast doesn't break anything in most multihoming scenarios, and
I'm not sure I understand your implications regarding mobility.
If a client trying to contact a server via an anycast address
moves in the network or changes its source address, its packets may
well be routed differently and be sent to a different instance of
the server. That breaks anycast in the general case; anycast relies
on stable routing.
Indeed, outing stability is important for the lifetime of a
transaction. I don't believe it is reasonable to say that anycast
"clearly breaks in [...] multi-homing scenarios", however. Mmany
sites are multi-homed, and many services are distributed using
anycast; since no large-scale unavailability of such services has
been observed, clearly it's possible to use anycast to provide
services to clients multi-homed sites.
[Note I am not claiming that it's impossible to shoot yourself in the
foot when deploying services using anycast. If anycast were
universally safe, we wouldn't have bothered writing draft-ietf-grow-
anycast.]
As far as mobility goes, if your source address changes then it's a
stretch to suggest that any common protocols will survive elegantly,
anycast or not.
In mobility scenario where a client's source address is preserved as
it moved (the motion through the topology being obscured from the
application by the use of a tunnel to a home agent) the effective
topology from the application's perspective is stable, and changing a
tunnel endpoint on the client side should have no effect on node
selection.
If the home agent end of a tunnel endpoint changes it's certainly
philosophically possible that the change in outbound path will cause
packets to be routed to a different anycast node. However, it's not
obvious to me that
(a) collapse of an application is inappropriate given such a
disruption, in practical terms (since a change of home agent in
common implementations looks to the user like a reconnection to the
network), or
(b) alternate home agents supporting the same client source address
will be substantially separated when considering the topology of the
global Internet: for the world to reach the client in both cases, the
chances are good that both HAs are in the same AS, which might
reasonably be expected to have a site-wide exit policy.
In cases where a service is distributed within a site it's easier to
imagine scenarios where a change of HA would result in a node
selection change for a particular client. However, within such a
single administrative domain the network topology should be well-
known and predictable, and so modulating the details to avoid
services breaking seems entirely possible.
So I don't see that anycast "clearly breaks in mobility [...]
scenarios" either.
In any case, to return to the topic at hand:
There are a couple of variations of shim6 deployment scenario
that probably deserve some thought:
[...]
Yes, so we do need to analyze these scenarios. (It would be better
if shim6 turned itself off in such cases.)
I think we need more analysis than that :-)
From the point of view of shim6 being used in the real world, it
would be a far better result if it could be demonstrated that shim6
could coexist happily with load balancers, at least in principle. The
alternative is that a shim6 client will see substantially no benefit
over a client with no shim6 stack at all when interacting with most
popular content.
To consider an extreme scenario for a second, if no servers support
shim6, then shim6 provides no benefit to clients. The motivation to
deploy shim6 in such a scenario might reasonably be expected to be
near zero.
Joe