FW: /8s and filtering

David Schwartz davids at webmaster.com
Tue Dec 10 19:18:53 UTC 2002

On Tue, 10 Dec 2002 12:36:39 -0600 (CST), Forrest wrote:

>Maybe I'm missing something, but what good would it do for someone to
>multihome if only their own providers accept their route, but nobody else
>does?  I realize that their block should be still announced with their
>ISP's larger aggregate, but what good does this do if your ISP goes down
>and can't announce the large aggregate.  

	Smaller multihomers elect to multihome for a variety of reasons. Those 
reasons typically include latency reduction and toleration of POP failures, 
router failures, and line failures. They're not looking to stay online is 
Sprint or MCI disappears entirely.

	If you multihomed to 2 providers in this manner and made a table of all your
downtime and its causes, loss of the larger aggregate would the tiniest 
fraction of your downtime, which is already a tiny fraction of the time.

	We don't put parachutes on commuter jets. The failures where 
these would be helpful are but the tineiest fraction of the failures that 
occur.  And any significant failure at all of such a redundant system is 

>If you're a smaller organization, perhaps you'll only have a /23 from your
>upstream provider.  With the filtering that seems to be in place, it seems
>like the only way you can truly multihome with a /23 is if it happens to
>be in the old Class C space.  Or is this wrong?  

	You're just biasing the question with the choice of words you use ... 
"truly" multihome.

>What seems to be needed is perhaps a /8 set aside by the RIR specifically
>to allocate to small organizations that wish to multihome that people
>would accept /24 and shorter from.  

	Not only would this increase the size of the global routing table, but this 
would actually decrease reliability for most basement multihomers. Basement 
multihomers tend to flap their routes more often than their upstreams. By not 
being inside a larger aggregate, these flaps are likely to result in more 
significant pockets of unreachability than they would be otherwise.


More information about the NANOG mailing list