[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 15:53, Brian E Carpenter escribió:
> In particular, the benefits would be the capability of establishing
> new communications through the alternative paths.
Well, that is an intrinsic property of IPv6 surely - if a host has
two addresses, and one fails, you can try the other.
Yes, but in this particular case, the multihomed host will have to
retry with an alternative _source_ address.
RFC3484 states that hosts should retry with alternative destiantion
address if they are available for the destiantion, but it is silent
w.r.t. source address retrial.
In the case that a multihomed host with multiple address need to
establish a new communication after an outage, it is likely that it
will have to retry using a different source address. currently this is
not specified anywhere.
But since we
can only get ULID to locator translation with a shim at both ends,
I just don't see what is brought to this property by the shim;
both ends will have to use the new locators at the ULP interface,
so the shim has no work to do.
W.r.t what is the relation between this point and the shim wg i would
- as i understand, the shim wg is about developing a multihoming
solution. a key part of the solution is the shim layer to preserve
establsihed communications through outages. however, there some other
parts of a multihoming solutions that are important as well, and i
think they need to be developed as part of the work of the shim wg. One
of such pieces is the mechanisms to provide compatibility with ingress
filtering. These are clearly not part of the shim layer but they are
clearly needed to make a multihoming solution work. the capability of
establishing new communications with non shim capable hosts can be seen
imho as another one of such features. (the other one is the TE
capability that was pointed out by Pekka S. that imho need some
rewriting in the draft)
- otoh, even in communications between 2 shim capable nodes, the
capability of establishing new communications after an outage is
required. the point here is that, if both ends support the shim, then
the used mechanisms can be different. However, the mechanisms for the
case when one of the nodes in non shim capable could still be used in
the case when the two nodes are shim capable. The tradeoff here is
w.r.t. the additional benefits that can be achieved when both endpoints
support the shim. But in any case, a mechanism for establsihing new
communications after an outage is also needed for the shim. this
mechanism can be designed in a way that it works with non shim capable
hosts or not. My point is that in any case we need a mechanism to deal
with non shim capable hosts. then we can explore if we will use the
same one when the two nodes support the shim or if it worthy to design
a new mechanism for this case.