Re: modules of a mh solution (was RE: New multi6 draft: WIMP)

[Dave Crocker <dhc@dcrocker.net>]

marcelo,

mb>  There are many other issues that have to
mb> be addressed in order to provide a multihoming solution and which solution
mb> it is probably simpler and easier to deploy.

First, I certainly agree that we need to be clear what problem(s) a
proposal solves and equally clear about what (related and interesting)
problems it does not.  And we need to be clear about relative
priorities.  So it's good you are raising this point it and will be even
better if folks discuss it.


mb> Moreover, solving the other
mb> simpler issues is likely to be what most of users really need right now.

There is certainly some feeling that this is true, but I am not so
certain. I think that the current reason for multihoming is reliability,
rather than performance.  As you note, connection preservation is only
one aspect of reliability.

I think there is an orthogonal issue to connection preservation. A host
needs to discover the set of addresses available to it. And it needs to
have a basis for choosing one. It would be nice for host to have a
discovery mechanism that did not involve manual configuration or running
a routing protocol listener.

What other, near-term uses for multihoming are you suggesting that are
a) important, and b) easier than any of the current proposals?

I'll comment that I think the discussion of multihoming gets distorted
by treated mobility as an entirely separate topic.  Portions of each are
entirely separate from the other.  However some portions do overlap. By
pursuing them independently, we do not take advantage of the overlap.

(Now, quite a few multi6 participants are also attending to mobility, in
their proposals.  However the conceptual discussions on the list are
nearly always and only about multihoming.)

A final demure: merging two areas of interest can serve to dissipate the
effort to solve either.  However I think this is not one of those cases.


mb> Now, returning to the preservation of established communications, i think
mb> that there is another module that i would include: locator selection
mb> mechanisms.

yes.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>