On Wed, 3 Jan 1996, Hans-Werner Braun wrote:
It even predates the T1/... NSFNET backbone. We already used something like that for the 56kbps Fuzzball based NSFNET backbone. In a sense, the RIPE db etc. are latecomers here. Susan is correct, the NSFNET implemented and formalized the routing data base in evolutionary stages. Often despite complaints from many sites that wanted free and uncontrolled flow of routing information.
isn't this exactly what is achieved by providing radb? including the individual's routing policies, so my system can find a nice compromize between what the providers around me want, and what I need? 'in spite of': guess the job is done just for that. For me, it is important to have access to routing info and policy advertisements, so I know better what's going on around us here. ... and if someone wants to make it a secret: hint: from ... accept any to ... announce <mine> with this, your routes are all represented, your AS is well defined, and what your route maps do (in cisco lingo), or your netsentry, or your filter, is your private issue. No reason not to participate, even with a blank statement like the one above. BTW: mine is blank, because I do a conservative approach: accept anything, announce clean. ;-) Or tell anybody how you want it, guess what: bgp makes it happen as close as possible.(with RS and some little wood shims, no effort no gain of course) Database format: a fight about 'better' or 'worse' is , mho, just stupid: better changes with time. New features bring new ideas and new needs for, guess what: new features. The evolutionary process is the best one, since every worthy contribution will prevail, and good meant tries will vanish silently. The informal process existing is excellent too: no red tape for real good improvements. To me, the radb is worth a hell of a lot for all kinds of tasks, not only routing (e.g. location, performance tests, yni). I personally say here: this is a good thing, no matter from where it comes. And if a provider with particularly bright and friendly people is heavily envolved: the better for all the others, no? Mike
I am not arguing about whether the RIPE and the RA DB should or should not be merged, just that there is a history to the steps taken, and reconciling into a homogenious DB (format) would have to be a concious effort by the parties seeing mutual benefit. Not that it should not happen otherwise, it just won't, given project priorities.
Gordan:
On Thursday 12/28 you enclosed with the text below:
May I ask: Is AS690 the Autonomus System number for ANS? I understand indeed that the PRDB was ANS specific but how exactly did that make the Ripe Database a better format? If it was a better format, it couldn't be used because the PRDB had components that were not transferrable to RIPE? Are you saying that to transfer the ANS database into RIPE format would have taken a very sizable number of person months?
To help you understand the PRDB, I offer some historical information from an engineer's perspective:
The concepts and the some of the code for the PRDB database system predate even ANS's creation. The PRDB concepts come from the early days of the NSFNET and trying to run that specific network. The multiple ISP/NSP world has come upon the Internet to replace the NSFNET. This change was requested by some people to provide a fair marketplace in the Internet.
The routing registration shift from PRDB to RIPE/IRR format reflects a shift in the Internet reality, not an ANS database specific project. The effort to keep the NSFNET service current was an engineering effort over years. We moved from 1/3 T1 to T1 to T3. Our databases also migrated implementations and service capabilities. The PRDB was the third in a series of the databases. RIPE could be considered the fourth.
I hope this has helped fill in some history around Curtis's comments.
Sue Hares Merit
********************************************************************* * Unsolicited Commercial E-Mail will cost $500/message under USC 47 * * which can be found online at http://www.law.cornell.edu/uscode/47/* ********************************************************************* ---------------------------------------------------------- IDT Michael F. Nittmann --------- Senior Network Architect \ / (201) 928 1000 xt 500 ------- (201) 928 1888 FAX \ / mn@ios.com --- V IOS