North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: using IRR tools for BGP route filtering

  • From: Austin Schutz
  • Date: Thu Jun 22 01:34:08 2000 
On Wed, Jun 21, 2000 at 10:25:27AM -0700, [email protected] wrote:
> 
> 
> [email protected] ([email protected]) 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.
> 
	
	But they are reinventing the wheel. Why not use the preexisting
functionality built in to the rwhois or dns protocols? The querying
mechanism for the IRRd is not RFC documented and returns 'F' when errors
occur. The source code is by and large sparsely documented, and in the
case of the RAToolSet, it won't compile cleanly on most platforms.

> 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.
> 
	But I don't _want_ everyone's data crammed in my database. I want
a referral from a central database that points me to one of several
locations for authoritative data. Do I want to cache that data? Maybe.
Maybe not.
	It would not be (as) difficult to define an rwhois schema that has the
desired functionality plus a protocol extension or two to account for any
extended behavior, such as caching.
	Please don't take this as bashing on the authors of the aforementioned
tools. I realize that they have been working hard and diligently.

	Austin