[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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