El 19/01/2005, a las 17:14, Brian E Carpenter escribió:
Marcelo,
You're correct of course that source address selection is a blank. There was some discussion around this point years ago, but it went nowhere. I agree that one of the *support* modules for shim6 will have to solve the source address selection problem, but that is clearly separable in my mind from the shim itself and the shim's state machine.
regards, marcelo
Well, Kurtis foolishly said he'd draft the next version of the charter. I'm curious to see what he thinks the consensus is...
Brian
marcelo bagnulo braun wrote:El 19/01/2005, a las 15:53, Brian E Carpenter escribió:Yes, but in this particular case, the multihomed host will have to retry with an alternative _source_ address.Focussing:
> 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.
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.W.r.t what is the relation between this point and the shim wg i would say that: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.
- 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.
Regards, marcelo
Brian