...

...

In other words, what is the value for an organization to utilize the Route Servers? And if there is value, why is everyone not doing it?

One detractor, to the best of my knowledge, is that the route servers are not exactly 'dynamic', meaning that they are updated a couple of times during the course of the day to reflect any changes in routing policy. Therefore, the possibility for blackhole'ing packets exists.

There is no possibility for blackholing packets. Blackholing means advertising a route and then not delivering the packet.

I'm afraid that I did run into a situation where the route was advertised and the packet was blackholed. I started to peer with AS-2882 at the PB NAP, and I accepted routes from it for another ISP (no finger pointing today -- sorry). Well, the ISP didn't have the VC map config'd in their router, and that route became preferred after a glitch somewhere in their network. Well, since the med's were the same in the routes we were sending to them, they preferred the PB NAP route after their glitch. Needless to say, not a happy situation. Then, of course, there was yet another ISP we were waiting for their router to be config'd, etc. Well, I didn't have time to wait for my advisory to be updated, so, brute force was utilized: (config-router)# no neighbor 198.32.128.130 This was more out of frustration in that I had my config's ready and I agreed to accept and give routes via the R/S. Needless to say, I'll decline to accept/advertise to that peer until I can ping them. Yes, I know this is more of a initial config issue, but the route servers were "in the way" at this point. Can You Say "neighbor x weight 1" next time :) rob gutierrez / internex information services