[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