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.