Re: Transport level multihoming

[Ramakrishna Gummadi <ramki@cs.berkeley.edu>]

> 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.

While I think that renumbering is a technical issue that is non-trivial to
remove because it has wide management implications, I am willing to ignore
this in this context.

But, like I said, it certainly has a great role to play in the amount of
redundancy and availability it provides (if an ISP multihomes to three
providers while it
uses one provider's prefixes for its sites, then I think multihoming is
not being used to its fullest potential). The ISP may also be using its
connectivity bandwidth suboptimally, which I consider another strong
potential problem because the full potential of packet switching is not
being realized.

> 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.

I am not saying that we should abandon the existing routing architecture.
In fact, we would be exploiting its excellent scaling and
routing properties. All translated addresses would be providing is a
sticky point of reference for a flow around which fault-tolerance through
routing, and scalability through aggregation will be achieved.

thanks,
ramki


> 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
>
>