[54094] in North American Network Operators' Group
Re: FW: /8s and filtering
daemon@ATHENA.MIT.EDU (David Schwartz)
Tue Dec 10 14:22:49 2002
From: David Schwartz <davids@webmaster.com>
To: <forrest@almighty.c64.org>, <nanog@merit.edu>
Date: Tue, 10 Dec 2002 11:18:53 -0800
In-Reply-To: <Pine.LNX.4.44.0212101236220.31544-100000@almighty.c64.org>
Errors-To: owner-nanog-outgoing@merit.edu
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.
=09Smaller 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.
=09If 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.
=09We 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
rare.
>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?
=09You'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.
=09Not 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.
=09DS
