RE: modules of a mh solution (was RE: New multi6 draft: WIMP)

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

> -----Mensaje original-----
> De: senthil ayyasamy [mailto:saq66@umkc.edu]
> Enviado el: miercoles, 18 de febrero de 2004 13:47
> Para: mbagnulo@ing.uc3m.es; Dave Crocker
> CC: multi6@ops.ietf.org
> Asunto: Re: modules of a mh solution (was RE: New multi6 draft: WIMP)
>
>
> At 11:53 AM 2/18/2004 +0100, marcelo bagnulo wrote:
> >For instance, most of the modules that you describe below are basically
> >focused in preserving established communication through outages in
> >multihomed environments.
> ...
> >I mean, I would say that there is a significant amount of potential IPv6
> >multihoming users that don't really have many critical established
> >communications that have to survive a outage that occurred in
> one of their
> >non directly connected link. (moreover, probably currently IPv4
> multihoming
> >solution fails to provide this for many apps in some scenarios where BGP
> >reconvergence takes a while)
>
> For now, connection preservation (fail over etc) should be the only goal.
> LB/multi paths is a difficult problem (both at transport and routing.) It
> has to be done after multi6 standardization. If we support MA, concurrent
> multi transfer has to be standardized within tsv. If we support routing
> based solutions(locator rewriting or BGP related,) load balancing needs
> an algorithm approach (which should be done within routing area.) OTOH,
> host centric solutions can depend on DNS for LB etc (which is not a
> multi6 issue.)
>
> or you meant something else?

Yes, definitely i meant something else, sorry for being so unclear.

Actually i was pointing that there are some simpler problems that can be
solved locally at the multihomed site that are also part of the multihoming
solution and that would provide important benefits without too much cost.

The first issue that has to be addressed is ingress filtering compatibility.
If you are using multiple addresses per host and the ISP are implementing
ingress filtering, problems appear when a single homed host becomes
multihomed. This problems occur even when there is no outage, and may affect
communications even when both links are working fine.
This implies that a single homed site that becomes multihomed will obtain a
degraded performance because of multihoming.
so the first step IMHO is that when a site becomes multihomed, it should
obtain at least the same benefits as when it was single homed.

Then, some mechanisms can provide some benefits of multihoming. For
instance, when a outage occurs, hosts within the multihomed site should not
use the source address associated with the path that has suffered the
outage. Note that this is not related with the preservation of the
communication, it is just that when an ISP is down, new communication
shouldn't use the associated address. In this case, a certain level of fault
tolerance is provided, even if the established communications are not
preserved

Additionally, selecting the source and destination properly some levels of
policing can be provided.

IMHO all this is much more simpler than mechanisms to preserve established
communications but they provide important benefits.

I say that these mechanisms are simpler because they require only
modification within the multihomed site and they don't require modification
of external hosts.

Moreover, some of these mechanisms work fine with non upgraded hosts within
the multihomed site.

I hope i explain myself more properly this time, sorry for the confusion.

Regards, marcelo

>