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

[Dave Crocker <dhc@dcrocker.net>]

Kurt,

(meant to tack this on to my reply of a few minutes ago.)


>> 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.


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).


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.



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