If
so, we need a BCP on this, outside of the shim6 protocol. This
seems much more like an operational issue.
If you are discussing how to do this when only 1 of the endpoints
is shim6 aware, then I think this should be addressed in the shim6
protocol document.
Or am I missing something?
John
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?
regards, marcelo
John