Who uses RADB/IRR?

Tue Jan 26 14:18:27 UTC 1999

briand at spare.de.teleglobe.net wrote:
> 
> > DA> I started looking at the RADB, but haven't got ourselves setup yet.  Does
> > DA> anyone actually deny routes which aren't listed in the RADB?  I guess what
> > DA> I'm really asking is how important is it to be in the RADB? Does it get
> > DA> more important sometime soon?
> 
> Yes, for peers and customers. Pretty important, at least for international
> connectivity (which is what we provide). Yes. (See below.)

You present several good points for requiring peers to register. Not all
networks require their peers or customers to be in the RADB, as not all
networks use the RADB or other databases.

Interesting problems arise when route filtering is applied by at least
some RADB users.

ANS.NET, for example, does not (at least in some cases) accept data from
the RADB when a prefix is moved from one AS to another. A move in AS
might occur when a portable prefix is shifted to a new ISP, or when a
portable prefix aquires its own AS and goes multi-homed. When this type
of change happens and ANS doesn't pick it up, the prefix which was moved
loses access to sites attached to ANS.

So, why is this a problem? The prefixes in question are not ANS
customers, nor are they peers of ANS customers. How does one find out
there's a lack of routing ability to ANS? Well, cnn.com doesn't work,
and a few other sites. This is a BAD way to find out.

What's needed is a clean way to examine the policy databases of RADB
(and other database) users to verify whether a network is being properly
routed. If your policy says to only accept a particular prefix as coming
from a particular AS, then the owner of the prefix needs to be able to
query your database to find out that you have that policy in place.

Presently there is no list of routing policy database users, and no way
to query the databases of those providers (at least that I've seen any
public info on). So, making any changes to the routing of a prefix is
treacherous. I advise clients with portable address space that when
they're switching providers or multi-homing, there may be loss of
connectivity to some locations for a week or more (while database
changes propagate) and some sites may be cut off entirely until the
other site's ISP is contacted.

I started this thread over just such an incident. If folks think the
policy databases are such a wonderful idea, the repercussions should be
understood. Procedural data (eg. information on when updates are pulled
from which databases, and when applied to routers, which database
changes are ignored) need to be viewable. Access to present policy
database data and looking glass systems also provide the ability to
diagnose reachability problems, make phone calls, and get problems
fixed.

-- 
-----------------------------------------------------------------
Daniel Senie                                        dts at senie.com
Amaranth Networks Inc.            http://www.amaranthnetworks.com