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

>>> The harder question is how to get information about the availability 
>>> of
>>> new addresses to the client system? Offhand, I think this requires a
>>> "push" mechanism from the network, rather than a pull mechanism from
>>> the
>>> client, in order to make sure the client learns of the changes in a
>>> timely fashion.
> KEL> Following my question in the other mail, do you also see that this
> KEL> mechanism in some way needs to help with the actual address 
> selection?
>
> To the extent that the mechanism for notifying of changes in
> availability also supplies QOS-related parametric information, yes, it
> is helping selection.
>
> But the actual selection is a separate mechanism, and I think we can
> get quite a bit of benefit out of a qos entry that is nothing more
> than exists/doesn't-exist. At any rate, the _use_ of the qos-related
> information is quite different from creating the database of the info.

First I don't think you want to call it QOS. Also, I am not so sure 
about this. This would require some form of extra state throughout the 
edge of the provider network, per customer or in worst case, per node. 
Right?

> KEL> So, my concern  is that we actually have a problem split in (at 
> least)
> KEL> two pieces - making the end system aware of what addresses with 
> what
> KEL> properties are available to it; and from the set of 
> addresses/locators
> KEL> make the selection of which one to use.
>
> yes.  however this separation is natural.  The activities occur
> at different times (or, I think, they should) and the hard work
> probably is done by different entities (the supplier of the qos
> information, versus the user of it).

Yes, but it does make some of the implications below.

> KEL> You can further complicate the above if we think that selecting a
> KEL> address for initial communication is one thing, selecting a 
> address for
> KEL> established communication is something else.
>
> Yup.
>
> In fact there is one approach to this domain that says the initial
> mechanism is whatever we already have today and that the mechanism for
> selections with an existing communication is all that we should pursue
> in the near-term, because it provides a strategic, incremental
> enhancement.

I think that todays state is a must as fall-back. But I don't have a 
problem of "multi6 capable host" triggering on new features being 
announce to it and first trying to use that for connection 
establishing.

- - kurtis -

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

iQA/AwUBQDuwgaarNKXTPFCVEQJEuQCfech3KpBRKpQfJjAMmw1WHdAiuP4AoO7Z
Rb0S4rtwgihyMVWh8WJwOPvm
=tZNI
-----END PGP SIGNATURE-----