Re: Transport level multihoming

[Peter Tattam <peter@jazz-1.trumpet.com.au>]

On Tue, 7 Aug 2001, Ramakrishna Gummadi wrote:

> > Doesn't similar constraints apply to any transport level solution ?
> > I am not sure how a transport solution works when one of the
> > upstream ISP's link fails. Isn't this one of the requirements ?
> 
> I don't think that an end-host level solution without address
> translation can work effectively 
> in a decentralized multi-tier multihoming scenario because the end-hosts'
> addresses have to be added/deleted/modified whenever a provider
> adds/deletes/changes its providers. Address translation has to be used,
> but this will be rendered less effective in the 
> transport level multihoming case because end-hosts will now have to be 
> aware of the final routable addresses so that they can advertise them in
> the payload, assuming we don't want to change every app at the other
> end-point to make it aware of multiple addresses.
> 

I thought that site renumbering was supposed to deal with this?  Bob Hinden had
a lot to say on the issue.



> A tunneling (or any network-layer)+translation based solution would not
> have this problem.
> 
> Another problem with the transport-level multihoming is that 
> the number of failure modes in multi-tier multihoming are decreased. For
> example, consider the scenario where a site is dually-multihomed, while
> each of the providers are triply multihomed to three different providers
> each. The question how many addresses do the hosts in the site have? If it 
> is two, then it means that the site can not tolerate failures in four of
> the providers twice removed from it. If it is six, then it means we are
> exposing the site to addressing issues not related to it.
> 
> A tunneling+translation solution solves this problem cleanly by using only
> two (or
> as many addresses as there are providers) provider-independent addresses
> to the site. The site's immediate providers would independently translate
> the addresses to meet their own load-balancing needs without leaking the
> site's prefixes. When a failure between the provider and its higher-up
> is detected, by creating two tunnels between itself and the higher up via
> the two working ISPs, a provider can ensure connection survivability and
> can even load-balance failed traffic among the working providers. The
> tunnels are only one "leve" deep, and are transparent to all others,
> including the original site.
> 
> 
> thanks,
> ramki
>

Won't a translation solution have the risk of translator box meltdown?  i.e.
may not scale?


Peter 

--
Peter R. Tattam                            peter@trumpet.com
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210