Subject: Re: Transport level multihoming

From: Peter Tattam <[email-masked]>
Date: Wed, 8 Aug 2001 11:13:41 +1000 (EST)

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                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

---

From: Peter Tattam <[email-masked]>
Date: Wed, 8 Aug 2001 11:38:13 +1000 (EST)

> a lot to say on the issue.

Disregard this comment in this context. I think it relates to another message I
was reading.

Apologies.

........

---

From: Ramakrishna Gummadi <[email-masked]>
Date: Tue, 7 Aug 2001 18:58:35 -0700 (PDT)

> a lot to say on the issue.

I think the mechanisms in IPv6 are adequate for sites/hosts that use one
address per connection. I don't think they would be adequate if we
consider multi-tier multi-homed scenarios that carry all possible
addresses in packets.

I may be wrong, but this clearly seems to be the case in any
transport-level multihoming solution...

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

It is only for the customer's prefixes that a provider has to make
translation. The translation can reside in the customer's border router,
and needs to contain only entry per site. Secondly, translation is
entirely optional. Finally, I think stateless (with regard to
packets) translation is not very expensive---already, web switches provide
hardware layer-7 (looking at cookies and urls) "virtual ip" services for
load-balancing and failover, so a layer 3 translation certainly looks
certainaly possible to me.

thanks,
ramki

---

From: Peter Tattam <[email-masked]>
Date: Wed, 8 Aug 2001 12:17:05 +1000 (EST)

> certainaly possible to me.

But it's still another single point of failure.  In my experience, such a
service unless delivered in a router style high reliability platform is going
to be a high risk point of failure.  Also the suggestion that it be another box
separate from the router means that it adds significant cost to the provider's
infrastructure.  It will be a specialized piece of equipment and likely to be
expensive.

Routers are good - they have high utility/cost, manage redundacy well, are
general purpose and you normally have more than one of them.

Peter

---

From: Ramakrishna Gummadi <[email-masked]>
Date: Tue, 7 Aug 2001 19:31:52 -0700 (PDT)

> general purpose and you normally have more than one of them.

I was suggesting that border routers implement this
functionality as part of the multihoming modification. If I am not
mistaken, most access routers, cable and dsl boxes already provide this
(and more complex stateful translation) functionality for IPv4, although
for different reasons ...

thanks,
ramki