[29380] in North American Network Operators' Group
Re: using IRR tools for BGP route filtering
daemon@ATHENA.MIT.EDU (Jeff Haas)
Tue Jun 20 10:29:05 2000
Date: Tue, 20 Jun 2000 10:26:58 -0400
From: Jeff Haas <jeffhaas@merit.edu>
To: "Daniel L. Golding" <dan@netrail.net>
Cc: Peter Francis <peter@softaware.com>, nanog@merit.edu
Message-ID: <20000620102658.E2089@vorlon.merit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <Pine.BSI.4.05L.10006200027350.3160-100000@cartman.netrail.net>; from Daniel L. Golding on Tue, Jun 20, 2000 at 12:29:08AM -0400
Errors-To: owner-nanog-outgoing@merit.edu
On Tue, Jun 20, 2000 at 12:29:08AM -0400, Daniel L. Golding wrote:
> I guess the only answer I can give to this is "nice try". If determining
> other people's peering arrangements was this easy, everyone would be doing
> it. While in theory, folks can register objects describing a peering
> relationship, very few folks (if any) actually do so.
And even for providers which are willing to publicly register
their policy the most data you'll usually get is adjacencies via the
aut-num objects. For the tier-1 providers, even this information
(visible in the global BGP) would make for a hideously huge object.
At the moment, IRR filtering technologies make the most sense at
the edges of your network, not near the Internet core. When
deployed at the core, pair-wise peering requires both parties to
register policy (and verify it!) before IRR filtering makes sense.
Otherwise it simply leads to further routing outages.
Filter at the edges and work your way inwards. This will solve
many routing outage issues.
> Daniel Golding
--
Jeffrey Haas - Merit RSng project - jeffhaas@merit.edu
