RE: multi6-functional-dec and re-homing

[<john.loughney@nokia.com>]

Marcelo,

> I think that we have a terminology issue here, and i guess that we can 
> benefit from the distinction made by Jari.
> One thing is the shim protocol, that as you mentioned is only needed to 
> preserve the established communications and another thing is the output 
> of the shim wg, which can be broader than just the protocol for 
> preserving establishing communications. What i am arguing for is that 
> the shim wg should also provide the mechanisms to establish new 
> communications after an outage in the case that only one of the hosts 
> is upgraded and the other one is just an legacy ipv6 node (i.e. at 
> least point 3 below)

I agree; I think there may be some debate about how generic the
mechanism for re-establishing communication should be.  In my opinion,
such a model is needed for the shim6 protocol to work properly; however,
I think we should work on a mechanism that is more optimized for use
with shim6 than a completely generic mechanism, or at least that is
what our target should be.  If we do develope a mechanism that works
with or without shim6, than that is a good thing, but I don't think
we should have a requirement that this mechanism should work without
shim6.

> Otoh, even the shim layer will need to establish new communications 
> after an outage, so this mechanism is also needed for the shim to work 
> properly (however, we could envision different mechanisms in the case 
> that both ends support the shim and in the case when one legacy host is 
> involved). also, the ingress filtering compatibility mechanisms are 
> needed for the shim to work.

I agree with this.

John
 
> Regards, marcelo
> 
> El 21/01/2005, a las 23:24, Christian Huitema escribió:
> 
> >> I agree that a single host that has SHIM components cannot preserve
> >> established communications (since for this support from 
> both ends of
> >> the communication is needed).
> >> However, if one of the nodes has SHIM components, it may be able to
> >> establish new communications after an outage, something that a non
> > SHIM
> >> host cannot. and this is a great benefit imho
> >
> > When I look at the components of multi-homing support, I find the
> > following:
> >
> > 1) Support of multiple IPv6 interfaces & corresponding IPv6 
> addresses
> > 	This is standard in most IPv6 stacks.
> > 	By itself, it allows servers to accept connections over multiple
> > nets.
> > 	Programming interface is well known (bind to "any", then
> > listen).
> > 	Can break if egress filtering interferes, but only in some weird
> > cases.
> >
> > 2) Choice of the appropriate address pair when many are available
> > 	There is a standard spec for "source and dest address
> > selection".
> > 	It should allow clients to establish connections.
> > 	However, it relies on "static analysis" of the prefixes, and
> > does
> > 	not work well if one of the paths is unreliable.
> > 	Can break if egress-filtering interferes.
> >
> > 3) Better algorithm for address pair selection
> > 	Essentially, try multiple choices instead of just one.
> > 	Present in some stacks and some applications.
> > 	We could do better.
> > 	Does not necessarily require Shim6.
> > 	Only a partial solution to egress-filtering.
> >
> > 4) Egress-filtering solution
> > 	Resolve interaction between "destination based routing" and
> > 	egress filtering.
> > 	Different solutions for different types of networks.
> >
> > 5) Detection of rehoming events
> > 	Quickly detect that connectivity has changed,
> > 	Could use information from multiple layers
> > 	Adequate response can be performed at many layers
> >
> > 6) Connection maintenance after rehoming & other event
> > 	The solution that shim6 addresses...
> >
> > -- Christian Huitema 
> >
> 
>