Are the Route Servers Viable Solutions That Are Being Held Hostage?

Stan Barber sob at academ.com
Wed Dec 20 07:03:50 UTC 1995


>From Gordon Cook:
> To refresh folk's minds, here is what Sean said:
> 
> The principal problem is that the RSes and the whole IRR
> are only as good as the databases are, and the bulk of the
> RADB was populated from the wrong source.  Rather than
> doing what I would consider the correct thing -- that is,
> watching peerings between the RSes and the providers
> participating in the various RS tests and tracking down
> all the information from the IRR based on what was seen
> there, verifying routing policies with end sites -- they
> started with the PRDB and hoped that fate would cause the
> RADB to become more correct.

I think that is a bit strong to say that the RA was hoping that
fate would cause the RADB to become more correct. I think the 
RA was hoping that the community would work with the RA to
correct errors in the data originally loaded into the RA.
Certainly, that has been my intent as I have worked with
the data for the various ASes which I watch over. 

My understanding of RADB and the IRR concept in general is
that it should serve as a source of information, not as 
a reflection of observed behavior. So filling the RADB
with observed data from the RSes would not be appropriate.

However, having some resource that does compare observed data
to the information in the RADB would be useful. This has
previously been discussed at NANOG and I recall the RA team
taking some interest in exploring the possible creation of 
such a resource.

> To be brief and blunt, the RA team started with
> information explicitly designed to PREVENT connectivity
> between "bad" (evil, greedy, commercial) networks and
> "good" networks which would be AUP compliant.  I'd think
> common sense would indicate doing some extra (and well
> paid) work to instead start off with something approaching
> a model of the reality of interconnectivity.

I agree that using the PRDB as the original source may have caused
more harm than good. In my opinion, the only other approach would 
have been to start with an empty database and have the various 
providers fill it with their data from scratch. Would we now have
a more accurate RADB? Maybe. Since that was the path not taken, 
we'll never know for sure. I believe that the more folks 
participate with data in the IRR, the likelyhood that errors in 
the data can be identified increases. 

> Moreover, another disappointment is that one could easily
> assert that a strong reason for using the PRDB as the
> source of information from day #1 was that MERIT was
> already spending its resources maintaining that database
> and toolset in a deal with ANS to keep ANS's network
> routing working much the same way during the many months
> while they figured out how to move on from the end of the
> NSFNET backbone service.

I am sure that the transition of ANS from the NSFNET days to the 
current situation involved a number of operational adjustments. I believe
that anything done to help this transition go smoothly was good for 
everyone and not just ANS. Perhaps I am not enough of an "evil greedy 
bastard" (though I am an "sob" :-) to believe that ANS having problems
resulting the transition is a good thing for everyone else.


> In short, I think the chief failing of the RADB is not the
> toolset, the concept, or the long-term plan, all of which
> make some to alot of sense.  Instead, what seems to have
> killed it dead is that the RA was too busy to commit the
> *serious* effort it would have taken to populate the RADB
> with information from reality in the first place.

This paragraph begs the question: Can the patient be saved? That is,
if the concept, toolset and long-term plan make some to alot of sense,
do we move forward by fixing the existing problems or starting over?


-- 
Stan   | Academ Consulting Services        |internet: sob at academ.com
Olan   | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob
Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.



More information about the NANOG mailing list