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

Re: multi6-functional-dec and re-homing


El 19/01/2005, a las 13:50, Brian E Carpenter escribió:

marcelo bagnulo braun wrote:
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.


But, imho, this would greatly reduce the benefits of the resulting solution....

I mean, this means that the resulting solution will only provide any kind of benefits when the two hosts involved in the communications implement the shim.
this would be ok if there were not possible to do better, but this is not the case.
We can design a solution that provide some of the fault tolerance capabilities when just one of the endpoints support the solution. In particular, the benefits would be the capability of establishing new communications through the alternative paths.

this would provide some fault tolerance benefits to the multihomed site independently of whether the external hosts support the shim or not.

imho this would render the multihoming solution much more attractive

so i would argue that we should explicitly include an item in the charter to do this

(i agree that not doing this would be simpler of course, but i think that establishing new communication after an outage is at least as important as preserving established ones for a lot of users and if we can provide this capability without requiring support of the external host it would be good, but i guess i am repeating myself)

(please note that during the presentation of the multi6 status on the ipv6, there was an explicit question on whether it was required to support both ends to obtain any multihoming benefit, as i recall, and this was seen as an issue)

Regards, marcelo

   Brian