[29404] in North American Network Operators' Group
Re: using IRR tools for BGP route filtering
daemon@ATHENA.MIT.EDU (cengiz@isi.edu)
Wed Jun 21 13:30:55 2000
From: <cengiz@isi.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14672.64135.951167.860244@cat.isi.edu>
Date: Wed, 21 Jun 2000 10:25:27 -0700 (PDT)
To: kobi@mur.com
Cc: Sean Donelan <sean@donelan.com>, nanog@merit.edu
In-Reply-To: <200006210558.BAA16285@rathe.mur.com>
Reply-To: cengiz@isi.edu
Errors-To: owner-nanog-outgoing@merit.edu
jhsu@rathe.mur.com (jhsu@rathe.mur.com) on June 21:
> problems:
>
> a. the independant registries generally store a local copy of the
> other registries for config use. this was fine when there were
> a few [like ripe, mci, ans] but not so fine when N grows unbounded.
> co-ordination could very quickly become a nightmare.
This problem is actually solved. Please see RFC 2769. There is one
implementation of this already, in ISI's BIRD server. IRRd folks, the
defacto routing registry server, are also working to implement this as
well. I heard rumors that RIPE will also implement this spec.
The protocol lets you auto discover new registries, and of course you
can choose what to do with the newly discovered registries. For
example, you can establish a registry exchange peering with radb, and
set auto discover, and each time radb or recursively some one they
exchange with starts peering with a new repository, you can start
receiving their data as well.
Cengiz
--
Cengiz Alaettinoglu Information Sciences Institute
http://www.isi.edu/~cengiz University of Southern California
