RE: Preserving established communication focus

["marcelo bagnulo" <mbagnulo@ing.uc3m.es>]

Hi Brian,

> -----Mensaje original-----
> De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En

> Marcelo,
>
> I don't think we should re-open the debate that led to RFC 3582.

Agree.

>
> I do think that all the goals identified there should be goals of
> the architecture. And I think they cover your points (with traffic
> engineering referred to as load balancing).

Completely agree.

I guess that the point is that there are several problems grouped under the
name of multihoming, since there are several goals that are expected to be
provided by the multihoming solution, as it described in RFC 3582.
My observation is that the arch document is mainly focused to approaches
that provide a solution for a very specific problem i.e. preserving
established communications.
I mean, my understanding of the approaches presented in section 4 is that
they basically provide the preservation of established communications. As i
said, this is just one of the problems. IMHO, the document should also
contain an analysis of the different approaches to provide the other goals
contained in RFC3582, like for instance. Which are the possible approaches
to provide traffic engineering capabilities? which are the possible
approaches to setup a new communication after an outage?.
I mean, i guess that the current document contains an in depth analysis of
the possible solutions of one particular problem of multihoming that is the
preservation of established communications, and that it would be interesting
to expand it to provide a analysis of the complete multihoming space problem
covering the other issues contained in RFC3582.

Regards, marcelo

>
>     Brian
>
> marcelo bagnulo wrote:
>
> >
> >>-----Mensaje original-----
> >>De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En
> >>nombre de marcelo bagnulo
> >>Enviado el: martes, 04 de mayo de 2004 19:53
> >>Para: multi6@ops.ietf.org
> >>Asunto: Preserving established communication focus
> >>
> >>
> >>Hi,
> >>
> >>My main concern about this document
> >
> >
> > I was reffering to draft-huston-multi6-architectures-00, of course
> >
> > Sorry for the possible confusion, regards, marcelo
> >
> >
> >
> >>is that it only covers the problem of
> >>preserving established communications through outages. While this is an
> >>important problem, this is not the only problem with multihoming, and i
> >>would even say that it is not the most important feature that has to be
> >>provided (it is the most difficult/challenging/amusing one, though :-)
> >>
> >>I guess that multihoming should provide at least fault tolerance
> >>and traffic
> >>engineering capabilities.
> >>
> >>Traffic engineering capabilities are not covered in the
> document, nor the
> >>impact of one or other approach in the resulting TE capabilities of the
> >>approach.
> >>
> >>Fault tolerance features are also broader than the problem of preserving
> >>established communications. Additionally, the problem of
> establishing new
> >>communications after an outage is relevant (and i would say that
> >>in general
> >>is more relevant than preserving established ones)
> >>
> >>So i would argue to perform a broader approach, like the one
> >>provided by JN
> >>chiappa in his multihoming points:
> >>
> >>"There are many different potential *goals* one may have for using
> >>multihoming,
> >>e.g.:
> >>
> >> - Reliability
> >> - Load balancing
> >> - More optimal paths
> >> - etc
> >>
> >>Depending on what one is trying to use multihoming *for*, this
> may make a
> >>lot
> >>difference to what mechanism(s) (see Obervation #0 about
> "cost") it makes
> >>sense to use.
> >>
> >>[...]
> >>
> >>When multihoming is used to provide *reliability*, there are
> (at least?) 3
> >>different levels of potential capability available. Those 3
> >>classes (in what
> >>appears to me to be the increasing order of difficulty) are:
> >>
> >> - Allow new outgoing connections
> >> - Allow new incoming connections
> >> - Keep existing connections open
> >>
> >>Again, depending on what level of capability one wishes to provide, the
> >>mechanism used may differ."
> >>
> >>I guess that the presented analysis can be extended to also
> considered the
> >>additional fault tolerance capabilities. for instance it would
> be required
> >>to add additonal considerations w.r.t these points
> >>
> >>Regards, marcelo
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
>