Home page logo
/

nanog logo nanog mailing list archives

Re: using IRR tools for BGP route filtering
From: <gerald () merit edu>
Date: Thu, 22 Jun 2000 11:56:11 -0400 (EDT)


 
On Wed, Jun 21, 2000 at 10:25:27AM -0700, cengiz () isi edu wrote:


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.

      
      But they are reinventing the wheel. Why not use the preexisting
functionality built in to the rwhois or dns protocols? 

Thoses protocol could certainly have been utilized and the community
did not ignore them.  In fact the pro's and con's were vigoursly debated at 
NANOG and IETF.  In the end the community decided the best way to go was 
RFC 2769.

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.

Just in case you were not aware, we do have an on-line IRRd users manual
at www.irrd.net.  We do our best to keep the manual updated and it does
provide detailed information for those who wish to use it.  IRRd started
out as a machine interface so was born the 'F', 'D', 'C', etc.. 
return codes.  You will find a section in the manual which explains
the return codes.  The ripewhois interface (designed for humans, mostly)
does return english sentences.

I agree with you that the internal source code documentation is sparse.
To address this issue (and others) we are currrently conducting a 
full code review and clean up which should help to address this problem.

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.

Merit is already taking steps to help coordinate the distributed DB effort.
We have a listing of remote registries with associated information at
http://www.radb.net/docs/list.html.  And when we impletment RFC 2726
we will have 'repository' objects corresponding to each remote DB that
we mirror.  This information will give the community a DB source to discover
new DB's and to utilize them (or not) as they wish.

We view our effort as a first step in assisting the community going forward.
It remains to be seen what will end up being the best method to provide
this information. 

      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.

Thank you for the kind remark.

--jerry


      Austin






  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault