El 19/01/2005, a las 13:04, <john.loughney@nokia.com> escribió:
Marcelo,
well, i am not sure about this... My point was about establishing new communication after an outage with external hosts that don't implement the shim. This is important becuase at least in the early days, most of nodes won't implement shim. Explicitly taking this point into consideration would allow to provide some degree of fault tolerance (i.e. the capability of establishing new communications after an outage) even in communications with nodes that don't implement the shim.
This is a general transition issue; I guess the protocol should specify how
an shim6 endpoint works with a non-shim6 endpoint.
I don't know...
I mean, on one hand, you are right, the shim protocol must specify how to deal with non-shim hosts. this means essentially the capability detection functions of the functional dec draft.
However, there is more that can be done in this context i suppose. I mean there are some fault tolerance capabilities that can be provided even though the communication is established with a non shim host. In particular, it is possible to establish new communications after an outage if the host withn the multihomed site is able to smartly select the source address to be used for that communication. In order to do this, the multihomed host needs modifications in the source address selection mechanism.
Such mechanism could also be used when establishing communications with a shim node, but perhaps in this scenario superior solutions can be obtained since both nodes implement the mechanism.
So, i guess that my point is that when a non shim node is involved in a communication, it would be good if we did more that just detecting that the shim is not supported, but we could deploy mechanisms to provide enhanced fault tolerance in this scenario.
(It could also be noted that such mechanism is likely to be much simpler than the whole shim and that it will, by itself, provide some degree of fault tolerance, so it may make sense to deploy it even without the shim)
Makes sense?
Well, yes, but also no. RFC 1958 says "keep it simple" so (see previous message) my instinct is to forget about shim6 when the other end isn't shim6-capable.
Brian