[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, <firstname.lastname@example.org> escribió:
I don't know...
well, i am not sure about this...
My point was about establishing new communication after an outage
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
some degree of fault tolerance (i.e. the capability of establishing
communications after an outage) even in communications with nodes
don't implement the shim.
This is a general transition issue; I guess the protocol should
an shim6 endpoint works with a non-shim6 endpoint.
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)
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
But, imho, this would greatly reduce the benefits of the resulting
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)