[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comments on draft-ietf-shim6-proto-05.txt



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.


If you are talking about hacks for building server pools, well,
I would expect those hacks to break too, but we can't know what hacks
people are deploying.


The characteristics of server load balancing as performed by products from f5, foundry, cisco, etc are well-known informally, even if they are not fully-specified in a standards document.

We can't design a standard to deal with that, but I suspect the impact
on moving clients may be exactly what I just described.


I have lost the original messages in this thread through over-zealous ietf mailbox pruning out of cron, so what follows may well be an obtuse tangent.

There are a couple of variations of shim6 deployment scenario that probably deserve some thought:

 + shim6 support present/absent on clients
 + shim6 support present/absent on load balancers
 + shim6 support present/absent on origin servers
+ whether or not destination addresses are re-written by the load- balancer (cf "pass-through mode")

It would be of benefit, I think, to consider at least the cases:

 + shim6/client + non-shim6/load-balancer + non-shim6/origin-server
 + shim6/client + non-shim6/load-balancer + shim6/origin-server
 + non-shim6/client + non-shim6/load-balancer + shim6/origin-server

and confirm that there is no fundamental architectural reason why services shouldn't be able to work at least as well as they might in a non-shim6, non-multi-homed environment.

I hear the inference with respect to packet-mangling middleboxes, but I think we need to be somewhat pragmatic and acknowledge the fact that if shim6 is destined to break a user's ebay/yahoo/google/myspace/ whatever experience, then ISP helpdesks around the world will rapidly become adept at instructing their customers how to turn shim6 off.

Yes, so we do need to analyze these scenarios. (It would be better
if shim6 turned itself off in such cases.)

    Brian