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

["marcelo bagnulo" <mbagnulo@ing.uc3m.es>]

Hi Dave,

[trim the destination list]

> Some proposals differ from each other at the level of "paradigm".  They
> quite simply approach the solution in a fundamentally different way.
> However others are variations on the same paradigmatic theme.  It seems
> entirely reasonable to look for the commonality and select from among
> the proposals.

Well, i would also say that different views also are dealing with different
problems related with multihoming and the basically focus on different
issues.

For instance, most of the modules that you describe below are basically
focused in preserving established communication through outages in
multihomed environments.

This is only *one* issue about multihoming. While most of proposals focus on
this point (i would say because it is the mist challenging one) this is not
the complete multihoming problem. There are many other issues that have to
be addressed in order to provide a multihoming solution and which solution
it is probably simpler and easier to deploy. Moreover, solving the other
simpler issues is likely to be what most of users really need right now. I
mean, I would say that there is a significant amount of potential IPv6
multihoming users that don't really have many critical established
communications that have to survive a outage that occurred in one of their
non directly connected link. (moreover, probably currently IPv4 multihoming
solution fails to provide this for many apps in some scenarios where BGP
reconvergence takes a while)

Please, note that i am not saying that the preservation of established
communications is not important, i am just saying that there are other
multihoming issues that are also important and that are easier to deploy and
that would provide many of the multihoming benefits.

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

This has at least three issues related:

Locator selection for initial contact: you have to discover which locator is
available

Locator selection during the communication: you have to decide when a
locator has become unreachable (at least)

Policing: locator selection mechanisms have to provide the means to
implement policing

Regards, marcelo


>
> Although the paradigmatic differences probably affect one's list of
> issues or "modules", my own view is:
>
>   - Association establishment
>   - Endpoint-pair context identification
>   - Authentication of the control exchange
>   - Updates to the pool of locators for the context
>   - Rendezvous (for mobile targets)
>   - Control exchange transport
>
> For those of a like mind, trying to first agree on a common set of such
> functions would be helpful.  It would then let us look for pieces of
> solution that we can share. (I think this sort of exercise at least
> will help refine our understanding of the differences.)
>
> By way of example, MAST has a very large hand-wave with respect to the
> details of control exchange authentication. It takes the approach that
> something of the weak authentication/purpose-built keys approach is
> sufficient, but leaves the details unstated.
>
> It would be great to have a solution that we could simply plug in to
> that part of the specification. The choice is essential for viable use,
> of course, but it does not affect the MAST paradigm.
>
> d/
> --
>  Dave Crocker <dcrocker-at-brandenburg-dot-com>
>  Brandenburg InternetWorking <www.brandenburg.com>
>  Sunnyvale, CA  USA <tel:+1.408.246.8253>
>
>