briand@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@senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com