RE: multi6-functional-dec and re-homing

[<john.loughney@nokia.com>]

Brian,

> John, I don't understand.
> 
> If neither end is shim6-capable, it is resoundingly out
> of scope.

I think it would be out of scope as well, but I wanted to understand
what Marcelo was suggesting.
 
> If only one end is shim6-capable, we can't run shim6, so
> we have to revert to mono-homing.

For work group purposes, I agree - but in terms of solutions, I think
(after we do the shim6 protocol) finding a solution for it could be
possible, but that is not something that needs discussing now.

John
 
>     Brian
> 
> john.loughney@nokia.com wrote:
> > Marcelo,
> > 
> > Are you speaking generally when we have 2 non-shim6 endpoints? 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
> >>>
> >>
> >>
> >>
> > 
> > 
> 
> 
>