i) prefix length is unfortunately not directly related to the "need"
     for multihoming.

ii) multihoming costs the person receiving the multihoming an
     amount of money that is variably determined by their upstream

iii) the number of prefixes that _would_ multihome if they:

     a) had the appropriate equipment
     b) had the appropriate tech-brains
     c) had an ASN
     d) had connections through multiple providers

     is _not_ known.

if you don't believe i) just imagine a content provider that is really
interested in reaching its customers through the most direct and fast path
possible, and who can't afford any outages. (their content isn't really
worth much during an outage).

ii) and iii) are important, taken together.

is _your_ router going to explode if my /24 gets added to your table? of
course not. your main concern is that your router explodes if _too_ many
people's prefixes, of whatever size, get added to your table. this is, i
think, a good thing to worry about, but it's a little early to be worrying.
if nothing else (and i'm most certainly not arguing that this is the best
solution), market pressure can be applied at points ii) and iii) to
reduce to an arbitrarily small number the number of prefixes of concern

all arguments of the variety, "i pass X [MGT]bits/sec, that's why i
qualify and you don't" or of the variety "i house a network of size /X
and that's why i qualify and you don't" are specious as well. ISP's need
to multihome for reasons quite different (well, exactly the same but in
an inverted direction) from the reasons that content providers do. it's
important to note that prefix length is _not_ always, or perhaps even
often, directly related to amount of traffic passed.

obligatory attempt at a useful comment:

completely ooma(tm) speculation, but i wonder if this would work:

(if someone's done this calculation, or can back-of-the-envelope
do it, i'd be curious to hear the results):

consider the size of an ideally "full" route table for a particular
traffic-passing router. consider a) the amount of time it takes for a
"maximal" percentage of particular prefixes in that table to actually pass
traffic across two of your interfaces and b) acceptable latency across
those two interfaces in your router. ("maximal" here means whatever your
router's prefix table capacity is, and "full" means the size that we as
a community need to be able to support but currently cannot.)

it's possible that you can:

update a "cache" of prefix entries locally against a slower, but more
"expandable" prefix-server.

the long and the short of it is, you offload the "live" route table to a
slower (read more cheapy expandable) box that has a fast connection to
your router(s). when a packet's destination route prefix isn't contained
in the cache, the prefix-server is polled (remember, very low latency to
this box) for the correct route, and it's added to the table. prefixes
not used for awhile age out of the local cache, and prefixes currently
in use are checked (through the prefix-server) periodically to determine

end-to-end (from far-flung BGP speaking routers) propogation time for
route information isn't exactly zippy right now anyway, so it shouldn't
bother anyone that "best-path as currently should be known to me" isn't
always taken for every packet.

so the tradeoff is more clear here -- the "slow" table server could
conceivably use very cheap technology for table storage (many GB of RAM
on something with a slow CPU, or even perhaps a fast-enough RAID array
spring to mind), and the "fast" router only needs to poll at a rate
commensurate with acceptable latency.

the "slow" box and "fast" box could be independent units inside of a
commercial router or not, and the "fast" link between the live table
and the cache should be cheap enough.

i'm not describing a route server here, really. i'm really talking
about offloading the space requirements to something that's slower, and
using a local cache to (presumably) keep router table size down.

(this external box _would_ be the one responsible for propogating
bgp updates to your peers, and inbound bgp updates would be transparently
redirected by the router to this box to deal with).


It is known. You forget one point, e) find it financially attractive,
but all together the upper bound is all sites. There is a good
technical argument (in the abstract, not with today's system) to
be made that everyone should be multihomed, down to dual-DSL lines,
dual-dial up lines, dual whatever access is available.

Of course, for a number of reasons this will never happen, most of
them come back to it not being financially attractive for the users
or for the service providers.

If you design everything from the ground up such that each "site"
is multihomed by default, and can develop systems that scale to
that goal than no matter how many people choose to multihome the
system will work.

I believe it is technologically possible to make every site
requirement. It would never happen with today's protocols, and
alias with the direction IPv6 is taking I don't see a light at the
end of that tunnel wrt multihoming. The technology may be
prohibitively expensive at some cut off point, but at least at that
point it would come down to simple dollars and cents for the users
and an ISP, and not a maze of similar but slightly different rules.

I know someone will want to argue that it is not possible to allow
_everyone_ to multihome, so I will go ahead and suggest an example
of a network very close to that goal, in fact one you can run IP
over (if a tad slowly). The cellular telephone network for the
most part has this property. Every phone has a number. It can
dynamically connect to multiple providers, and can change providers
as conditions change, or the device moves. The only property it
doesn't have that IP multihoming doesn't have is the ability to
use two providers at the same time; however the technology for a
handset that could make a CDMA and a TMDA call at the same time on
two different networks definitely exists.

This is not to say I think 'cellular phone routing' would solve
the IP issues if directly translated, in fact I think quite the
opposite. That said, I do belive large scale systems that allow
individual users to move, or multihome (I think those two items
are more closely related than people think) while keeping their
"address" exist.

I don't do the IETF thing, but has any development effort there
tried to make multihoming / mobility a requirement of a new protocol,
and if so why hasn't there been more progress on that front? (steve uurtamo) writes:

is _your_ router going to explode if my /24 gets added to your table? of
course not. your main concern is that your router explodes if _too_ many
people's prefixes, of whatever size, get added to your table. this is, i
think, a good thing to worry about, but it's a little early to be worrying.

i think that absent the worrying that's already gone on, from way back
before CIDR when BGPv3 was classful, is the only reason you can still
say it's "early."

alas, doomsayers who are taken seriously in their own time, that is,
early enough for their prophesies to be treated as foresight and acted
upon preventatively, are often called unstable sky-is-falling cranks in
the history books. (witness the Y2K debacle if CIDR doesn't excite you.)

The closest analog in the networking world that comes to mind for matching
the properties of how both cell-phone portability and LNP work isn't IP.
It's DNS. Consider the following points, each of which applies to both
telco routing and DNS, but *not* to IP:

1) 'Routing' lookup done once, at the start of the transaction.
2) Relatively low overhead compared to the transaction.
3) Handled by a distributed system using local *external* query points
   whose primary job is providing routing information, not actually doing
   the routing.
4) Every address is portable between nearly arbitrary providers (and, in
   the case of the telco, I believe is now required to be by law).

I'm far from the first person to bring this up; please see some of the
excellent papers from the ATM, VOIP, and MPLS arenas about "why routing
telco traffic is completely different from routing IP traffic", many of
them authored by members of this forum, for further details.

The primary failure points in this is that DNS recovery times are nowhere
near as good as most telco re-routing times, can't occur mid-stream, and
because of this combination, tends to be far more problematic when there
is a failure, because people *notice* - both in that their session goes
away, and that they then can't even just "redial" and blame it on a cosmic
ray at the wrong time.


I don't do the IETF thing, but has any development effort there
tried to make multihoming / mobility a requirement of a new protocol,
and if so why hasn't there been more progress on that front?

There are numerous related activities going on in the IETF to address
multihoming and mobility.

First, there has been a very long standing effort in the mobility front.
MOBILE-IP allows one to hold a single IP address, no matter where one
is. It works via tunneling to a known point in the topology, where
non-participating nodes rendevous. With IPv6 they're attempting to do
one better: there are to be no nodes that are not aware of mobility.
That way, once the two end points have connected one can send a
rebinding message to the other saying, "I'm over here." The benefit is
the elimination of triangular routing.

As to multihoming, there are two working groups that are specifically
looking at multihoming and its implications.

The first is PTOMAIN (don't ask me to expand it. Randy came up with

PTOMAIN is focused on improving things now through incremental changes
to BGP. One of the approaches they're looking at is the scoping of
routing updates to a limited number of ASes, after which they would be
aggregated into a shorter prefix.

MULTI6 is looking at the problem for IPv6. And in this working group
things are going a bit slower, but the constraints are looser, since the
deployment at this point is, well, limited. There is at least one
proposal that talks about NATting and NAT mapping between the end points
and within the network. Imagine the edges NATting an address and then
unNATing it at an exit. It beats normal NAT in as much as the IP
address that the destination sees is the one that the sender used. How
it selects addresses, transmits the mapping, and all that are in a draft
document. Of course, this stuff is very immature. Our friend Sean
Doran is one of the chairs. Perhaps he can comment more.

Finally, there are several efforts going on outside of the IETF that may
well have very broad implications for both mobility and multihoming.
These are research activities of the IRTF. One is the Routing Research
Group (RRG), where they're looking at next generation routing. Another
effort is the Name Space Research Group, headed by Steve Crocker, Steve
Bellovin, and myself. That effort was asked the question "should there
be an additional name space above layer 3?" The answer is hard to find,
but we are producing an RFC that should be due out in a few months.

Finally, there are some more vaguely related things going on. One is
SCTP, which is done. It allows for multiple ip addresses per transport
end point (as opposed to a single one with TCP). An extension is being
considered to allow for addition of transport addresses in the middle of
the connection (right now you have to name them all during setup).

And finally there is a new working group called HIP (host identiy
payload) being run by Bob Moskowitz (see draft-moskowitz-hip-*). Here
the idea is to insert a naming layer just as we discussed in the NSRG.
Bob has some interesting applications to improve security. There are
also mobility possibilities here too. This stuff is fairly early on.

Hope this helps,

Eliot Lear