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

From: Brian E Carpenter <[email-masked]>
Date: Wed, 03 Nov 2004 10:24:07 +0100

>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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 3 Nov 2004 18:12:01 +0100

Hi Brian,

thanks for these comments too.
see below...

> 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

> as an outage. Ideally, available QOS may  be a criterion for address

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

> 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

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

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

> 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-masked] is no longer in use
Please send mail to:
marcelo at it dot uc3m dot es
------------------------------------------