RE: Multihoming by IP Layer Address Rewriting (MILAR)

[Iljitsch van Beijnum <iljitsch@muada.com>]

On Mon, 3 Sep 2001, Michel Py wrote:

> I would tend to say "visible over TWO or more transit networks"
> for the following but agree on the rest.

That way, every current style multihomer qualifies. I can see some
dual-homed networks having a block of their own, but I certainly wouldn't
want all of them to have an address block of their own. Also, using
addresses from two blocks is not unreasonable, but a customer dual-homing
to two triple-homing ISPs would have six address ranges, that is too much.

Also note "globally visible". Here in The Netherlands many ISPs have one
"real" uplink that is globally visible, but also connect to the Amsterdam
Internet Exchange. I think it is reasonable in such a setup that they
would use address space from their transit ISP and announce that space
over the AMS-IX to local/regional peers. That way, the DFZ stays small but
local/regional traffic can still find the shortest path.

I know internet exchanges are out of vogue in the US, but they are a
reality in Europe. The AMS-IX carries 3 Gbit/s of traffic, compared to 300
Mbit for the New York Internet Exchange, even though bandwidth is a lot
cheaper in the US than in NL. The number of people that live in The
Netherlands is comparable to that in the NYC metro area. (But then the
AMS-IX is one of the four to six main exchange points in Europe.)

> I am a little more reserved about this:

> >> - using multiple address ranges is the only way disconnect
> >> the growth in multihoming from the growth of the global
> >> routing table

> Until someone finds a mechanism that can do it.

Ok, you're right, other ways, such as on-demand created routes, are
possible, but I don't see it happening.

> Besides, the
> growth of the multihoming table, if it contain multihoming
> prefixes only and not the result of poor summarizations could
> be controllable as you mentionned above.

I don't think it can be controlled, unless draconian measures are taken.
I'm not as pessimistic as some others: I think the current multihoming
practices could continue to work for the foreseeable future if BGP
implementations can be optimized.

Still, if we can create a good host-based multihoming solution, this will
drain away much of the growth of current multihoming practices, giving us
all more breathing room. Also, it makes multihoming reachable for
everyone. With IPv6 we're in the unique position that the implementations
are still very fluid, so we should take advantage of that.

However, your proposal depends on changing the Internet core routing,
which is very hard to change. Note that there is hardly any IPv6 routing
in the core, while the changes in BGP necessary for this are minimal. Your
approach is much more radical and I have a hard time seeing it happen. On
the other hand, since there is so little IPv6 routing going on, there is a
window of opportunity there as well.

The main advantage of your proposal is that you solve the "alternative
address discovery" problem.

> Please take the time to have a look at:

> http://arneill-py.sacramento.ca.us/draft-py-multi6-mhtp-01.txt

Note that a network that is part of the DFZ does not have "an ISP". You
pay an ISP to route traffic to all destinations connected to the Net, in
other words: you pay for a default. In the default-free zone there are no
defaults (but the reverse is not always true: a network running without a
default is not necessarily part of the DFZ) and you don't pay others to
handle your traffic: you peer with them. (Although I'm sure there are some
caveats there.)

Iljitsch