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

> KEL> We also had this discussed sometime during the autumn and from 
> what I
> KEL> remember, most seemed to think that mobility and mutli6 required
> KEL> solutions with different paramters - to the point where the 
> solutions
> KEL> would be different solutions.
>
>  This sufficiently at odds with my own sense of the solution space
>  that I really would appreciate any elaboration of the details folks
>  can conjure up.
>
>  So far, my sense is that there is a very large amount of overlap
>  between the two problem spaces.  No, not 100%, but more than enough
>  to justify seeking a single solution for the common set of
>  requirements.
>
>  Multihoming is about multiple addresses.  Mobility is about multiple
>  addresses.  The structure, predictability and timing of address
>  management for the two differ.  This might mean they need entirely
>  different mechanisms, but so far it looks like they can do fine with
>  just one.

 From what I remember of the discussions here on the list, most people 
seem to see several similarities between the two. However the "failure 
modes" seemed different as well as the timing for the events. Also, I 
guess the way the address "learning" is/could be/should be handled in 
different ways for the two scenarios. I am not convinced that the two 
are similar enough to be able to use the same mechanisms, even with 
different parameters. But I would be happy to be proved wrong. :-)

However, again I think that this is something we also should provide as 
input for the architectural analysis. Just as impact on ULPs might 
vary.



> KEL> are you arguing that as part of any solution, we should either 
> include
> KEL> a address selection / pairing algorithm or we should make that an
> KEL> "external" requirement to be solved by a separate protocol or by
> KEL> someone else?
>
> Any initial specification needs to provide a complete capability.  So
> I am arguing that we distinguish between near-term "simplistic"
> choices that provide initial utility, versus longer-term, extended
> choices that can be pursued outside of the initial critical path.

Hmm, this has also been discussed before and the standard counter 
argument is that we should concentrate resources on one solution as we 
otherwise risk not having anyone at all. I am not arguing one way or 
the other, but an interesting question is what do you use to categorize 
any solution in an architectural evaluation in to the categories you 
describe?

- - kurtis -

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

iQA/AwUBQDuu16arNKXTPFCVEQIssgCg0BkpI1QeXpU9akttvanWY8lASj4AnimP
mdYsuFJRqfRdYTD3CPVMUZcp
=Ao8r
-----END PGP SIGNATURE-----