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. 

I think I was trying to say was that this seens to me to be the site
renumbering scenario. At the Tokyo meeting, this was discussed and the
following recommendations considered.

1) renumbering would be infrequent and usually highly coordinated.

2) when renumbering occured there would be considerable overlap where both sets
of addresses would be in use at the same time.  This is simply an extended
multihoming scenario with certain prefixes being deprecated.  The overlap
should be long enough to allow deprecated addresses to disappear from the
network.

The issue of management of site renumbering in a multi tier environment does
leave open many management questions.  One throny issue is that higher tiers
would have to inform lower tiers of their intentions and lower tiers would have
no choice in the matter in reality.  How this is perceived by the wider
community is a public relations excercise.  The public has grown accustomed to
the fallacy that once they get some address space, they sort of own it or at
least lease it.  The concept of the address space being fluid is going to take
a lot of reeducation.

I believe a successful solution to multihoming in Ipv6 is to make the address
space fluid enough to facilitate renumbering and transport (site) level
multihoming but sticky enough that it doesn't all fall apart.

The BGP approach takes the address space as a fluid mass and tries to mold it
to the current routable topology.

The site level approach considers the address space as a skeleton upon which
you can apply the flesh of routing.  No matter how you shake it, the skeleton
is rigid as it is based on relatively static allocation policies.

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