Policy Statement on Address Space Allocations
jnc at ginger.lcs.mit.edu
Mon Jan 29 18:37:33 UTC 1996
From: "Joel M Snyder, writing fool" <Joel_M_Snyder at opus1.com>
The company wishes to have more than one connection to the Internet through
more than one of the major providers
From: lodge at houston.omnes.net (Mathew Lodge)
its upstream provider ... They also want to be multi-homed from day one.
They currently offer all sorts of fully redundant data services, and
understandably they can't see why they should have a single point of
failure in their global Internet access.
Oh, good, the multi-homing discussion again.
(The loud "bang" you just heard was Noel blowing out his brains in sheer
desperation and frustration.)
Here's a repeat of a previous post to a different list:
For those who aren't up on the technical background to multihoming, you
should consider consulting the Big-Internet archives from the end of
September '95 for a long discussion of it.
(In particular, see the thread "Discussing encap/mapping proposal",
especially the messages of Thu Aug 31 23:33:12 1995 from me, Fri, 01 Sep
1995 11:13:39 -0500 from Scott M. Ballew, and Fri Sep 1 13:25:59 1995 and
Sun Sep 3 01:23:59 1995 from me, which discuss the theoretical background
in some detail. The thread "Multihoming", especially the messages Fri Sep 1
11:20:25 1995 and Mon Sep 4 14:26:06 1995 also contains some valuable
For those who don't wish to paw through all that, here are the salient
1. Multihoming for robustness adds new capability to the system, and
that new capability does not come without cost, the cost being greater
routing overhead. The amount of routing overhead will vary depending
on many factors.
2. Connectivity-based addressing (i.e. the thing that "provider-based"
is a subset of) provides routes at least as good, and at as least as
small a cost in routing overhead, as any other addressing scheme.
(Connectivity-based addresses for multi-homed sites allow us to use
less than global scopes for the advertisement of routing information
about such sites. Non-connectivity-based addresses do not have this
characteristic; they require advertisment through the entire network.)
3. The cost in routing overhead (at least in conventional hop-by-hop
routing systems such as the current Internet) is dependent on how far
apart, in the connectivity topology, the multiple connections are.
(More widely separated connections can increase the routing overhead
with little payback in increased reliability.)
4. The cost further depends (again, in the same kind of systems) on
how optimal you want routes to be if both links are up, how optimal
you want them to be if one is down (and it will vary depending on
whether it's a primary or secondary).
I hope everyone will keep these 4 main points in mind in any discussion
Now, a few extra comments appropriate to this case:
There is *no way*, in the current overall routing architecture (which uses
exchange of routing tables) to add multihoming for fault tolerance without
a cost in routing overhead. Providing this fault-tolerance is not zero-cost
in *any* scheme I can conceive (TANSTAAFL, surprise, surprise), but some
are better than others. Since redesigning the entire architecture is not
something we can do this week, I'll leave the pleasant contemplation of such
alternatives to academic, ivory-tower, environs.
We can *easily* limit the amount of routing overhead caused by multi-homing
among different providers if we provide some structure in the addressing
hierarchy *above* providers. (To be technical, this will allow less than
global advertisement scopes of such multi-homed entities.) Since this could
necessitate renumbering most of the 'Net, I don't expect it to happen
We can also limit the amount of routing overhead by providing configured
AAB boundaries for a given multihomed site which enclose a path between the
primary and secondary providers. Since this will in some cases require
cooperation among multiple providers, as well as either i) massive amounts of
manual mechanical configuration bookkeeping, or ii) automated tools we don't
have yet, don't hold you breath for that one either.
PS: If you didn't understand that last paragraph, read the references before
More information about the NANOG