multi-homing

Wed Aug 29 00:11:51 UTC 2001

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

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

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

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

s.