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

[Kurt Erik Lindqvist <kurtis@kurtis.pp.se>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



	Dave,

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.
> mb> fully agree.
> mb> do you have in mind something different than just plain trial and 
> error?
> mb> becuase i wouldn't want to modify external hosts, right?
>
> I have a suspicion that you do not mean "trial and error for 
> discovering
> one's own list of addresses" but rather mean "trial and error as a 
> basis
> for choosing one"...
>
> I think there need to be mechanisms for both learning of one's own
> addresses and for helping decide which one to use.  The former is
> essential in the near-term, I believe.  Without it, we cannot scale any
> approach that makes the hosts aware of their multiple addresses.
>
> Something akin to routing table information, to help a host choose 
> among
> the list of its own addresses, is important, but can be deferred.

are you arguing that as part of any solution, we should either include 
a address selection / pairing algorithm or we should make that an 
"external" requirement to be solved by a separate protocol or by 
someone else?

>>> 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.
> mb> Well, i guess that some mh solutions can be used to provide 
> mobility support
> mb> but not all of them.
>
> That is my point.
>
> If we have two proposal that are roughly equal in their complexity,
> utility, and the like, then the fact that one can also be used to
> satisfy some mobility requirements ought to bias us in its favor.
>
> At the least, this wider range of utility ought to be a significant 
> part
> of our evaluation among the proposals.

It should. And this IMHO is covered by "2.1.2 Uniqueness" and "2.1.2.1 
Does your solution address mobility" in Eliot's draft.

- - kurtis -


-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBQDjPpaarNKXTPFCVEQK5LACgoN4VLjnvN7qrX+AXaQ/jAMg0ejIAn1hE
lzh8moRmQUadkXusK0FMV4+/
=1gK3
-----END PGP SIGNATURE-----