Re: I-D ACTION:draft-huitema-multi6-addr-selection-00.txt

[Brian E Carpenter <brc@zurich.ibm.com>]

>1.  Introduction
...
>    In this memo we will present a set of mechanisms enable the hosts
>    within the multihomed site to select the addresses in order to be
>    able to establish new communications after an outage.

I don't see why this only applies after an outage. The problem presents
itself whenever a source wants to open a new flow - with or without
knowledge that an outage has occurred. (And trivially, rebooting
effectively emulates a general outage.)

Also, as we've discussed, a reduction in obtained QOS may also be treated
as an outage. Ideally, available QOS may  be a criterion for address
selection.

> 5.1  Proactive mechanisms
>
>    In this case, two mechanisms are needed: first, a mechanisms to
>    detect the outage and then a mechanisms to inform the host about
>    which prefixes should be used in the source address for the different
>    destinations. 

I have some difficulty in understanding this. Before a ULP decides to
communicate with a particular remote host, the multihoming apparatus has
precisely zero knowledge that this host is of interest. It's inconceivable
therefore to have prior knowledge of anything useful about the remote host
or its ISP, in the general case. We might know the status of the local
first level (and possibly second level) ISPs, but that is about all. Does
that covers enough cases to be worth the cost of implementing proactive
mechanisms?

> 5.2  Reactive mechanisms
>
>    In this approach, the host will try with different source addresses
>    until the communication is established. 

Possibly, this will involve QOS measurement too. And this might edge over
into the proactive side - it could be worth caching the results in case
other flows to the same remote host are started within the some TTL.

> 6.  Future steps
>
>    This memo presents multiple possible approaches to select address for
>    initiating new communications after an outage in multihomed
>    environments.  At this point, the goal of the memo is to foster
>    discussion about the benefits and drawbacks of each approach, so that
>    eventually a set of mechanisms can be selected.

I think it's more important to define interfaces so that the
mechanisms can be pluggable.

     Brian