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

Hi Brian,

thanks for these comments too.
see below...

El 03/11/2004, a las 10:24, Brian E Carpenter escribió:

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

Well, it is clear that a host has to select the address to use when it 
initiates a new communication with or without an outage, but in the 
case that there is no outage, the main problem is ingress filtering and 
policy (which are out of the scope of this draft, since we wanted to 
keep it focused as a single component)
However, in the case that an outage has occurred, the problem is more 
serious, because if the wrong addresses are used, the communication 
will fail.
this is the situation that the mechanisms presented in the draft tries 
to solve

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

agree, but a first (simple) approach to the problem could be like 
working vs non-working paths.
QoS computation may be a bit tricky, so perhaps it would be better to 
avoid it for initial mechanisms... i don't know

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

well i was thinking about bgp.
I mean, if we have something like what was presented in NAROS, where 
there is server that runs BGP with all the ISPs, then this server has 
information about all the BGP feeds, so it may have additional 
information of the remote end. Clearly this info won't cover all the 
possible failure modes, but some of them. so in those cases, there will 
some info available that allows the host to discard the faulty address.
It is clear that those mechanisms are not enough by themselves, and the 
reactive mechanisms are also needed.

> Does
> that covers enough cases to be worth the cost of implementing proactive
> mechanisms?

This is the whole point i guess.

FWIW those mechanisms are included in order to have all the possible 
approaches and then select the ones we think are worthy

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


Yes, but as i mentioned above, my feeling is that QoS considerations 
should be covered by a bit more advanced mechanisms and that a basic 
approach could simply differentiate among working and non working 
address pairs, do you think that we should be considering qoS from the 
start?

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

agree.

It would be usefull to see if these mechanisms are compatible with the 
multi6 protocol for preserving established communications and if the 
presented mechanisms are good enough to be used for establishing 
initial contact in multi6 capable sessions.


regards, marcelo


>      Brian
>
>
------------------------------------------
Please note that my former email address
[email protected] is no longer in use
Please send mail to:
marcelo at it dot uc3m dot es
------------------------------------------