Re: on the point of mobility & multihoming

[Dave Crocker <dhc@dcrocker.net>]

Brian,


BEC> My point is really that walk-in-the-park example doesn't (in my view)
BEC> change the problem space (at least not the problem space that I believe
BEC> we are working on).
...
>> Agree. We are looking for a solution that doesn't care why the physical
>> signal fails and the frequency of failing.
...
>> Multiaddress mulithoming and mobility solutions must incorporate the same
>> mechanisms:
...
BEC> is one physical difference - in the site multihoming case I don't see
BEC> that there is a rendezvous issue. The set of connections that may be used 
BEC> is defined and configured in advance, whereas in mobility it is unknown 
BEC> in advance and requires discovery, rendezvous and AAA mechanisms.

Multhihoming configuration changes over time, as does the availability
of configured connections to the Internet.  These changes in
reachability are presumed to happen more slowly that with a mobile
scenario, but the the other technical characteristics are pretty much
the same.  (We could quibble about full-scale outages, with no valid
address, but otherwise it is multiple addresses, changing over time.)

"In advance" does not apply to an existing connection when a multihome
access is changed during the connection.

The multihoming scenario that is probably driving folk's sense of
difference between multihoming and mobility is: a) little or no change
to the configuration, b) no need to apply the changes to existing
connections.

This is a useful set of constraints, but it is important to recognize
the way they change the problem space.


BEC> It may be that by *adding* a discovery, rendezvous and AAA package to
BEC> the multi6 solution, we will get a new mobility mechanism. We should
BEC> certainly keep that in mind in the architecture discussion
   
yup.


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