[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: multi6-functional-dec and re-homing


El 24/01/2005, a las 7:11, <john.loughney@nokia.com> escribió:

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.


my concern is about deployment
The deployment model for the shim protocol requires de support from both ends of the communication
i am worried about some signs that are starting to appear, like the policy proposal for PI assignment for multihomed sites in the ARIN region. I read this as a sign that the community is requiring a multihoming solution asap.
So my point is that we need to provide some tools that provide immediate benefits to the multihomed sites.
A mechanism for establishing new communication after outages, that does not impose support from the other party of the communication, would provide immediate benefit to the multihomed site.
Only providing a shim protocol that requires support from both ends, is a great tool, but its deployment time seems way too long compared to the aforementioned initiatives.

But, i guess that i have already made my point clear too many times by now.
Sorry for repeating myself, but i think this is an important point.

Regards, marcelo



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