So if they were supposed to use the services of the routing arbiter and appear to have renigged on this, what can anyone do?? Are they determined to make it painfully obvious for all to see that there are no enforcement teeth left at the NSF?
The RA is broken, just relabeling work of Ripe and mess it upp is not very usefull for the Global Internet. Ripe-81 (that most of this is based on) was supposed to be a start of a toolkit for ISP's, not a tol for someone who think they are the network Police. -Peter
Peter,
Peter Lothberg writes:
[stuff deleted]
The RA is broken, just relabeling work of Ripe and mess it upp is not very usefull for the Global Internet. Ripe-81 (that most of this is based on) was supposed to be a start of a toolkit for ISP's, not a tol for someone who think they are the network Police.
-Peter
We've had this discussion many times, and will probably never agree. The RA adopted the RIPE database work since it seemed reasonable to express global information in a standard fashion. Credit is given to RIPE and the PRIDE project whenever there is talk of the IRR, RIPE NCC Database, the RADB, etc. The RA team has announced many tools based on the database and the routes known to the route servers: 1) IRRWeb - graphical interface to query the IRR and to update the RADB 2) Route History Server - provides a mechanism for tracking the announce/ withdraw history of a given prefix for the last 24 hours 3) Route Flap Statistics Generator - provides mechanism for calculating the level of routing instability at all of the four NAPs 4) Route Server Routing Table Statistics Generator - reports on the size an content of the Internet routing tables as seen by the Route Servers at each Network Access Point 5) Peval - policy evaluator that inputs RIPE-181 policy expression, performs certain calculations, and outputs expressions that can be used by other tools, like RTConfig 6) RTConfig - front-end tool that uses Peval and RADBserver to generate router configurations 7) RADBserver - extension of the RIPE whoisd server which provides a protocol for getting information from RIPE-style database files 8) RSd - an enhanced version of GateD routing software that provides multiple views of routing information 9) rrc2r/rrmerge - a package to convert Cisco router configuration files to RIPE-181 objects that can be submitted to a RIPE-style database 10) CiscoBGP - analyzes routing information from production Ciscos and compares the data with routes in the IRR 11) BGPCheck - compares information from BGP4 peering sessions with the route serves with data in the IRR 12) PRtraceroute - developed by the PRIDE project, the RA team provides a version that queries the RADB In addition if you look at the RA web pages, you will find descriptions of other tools which are under development. The RA is committed to working with the community to develop tools that are seen as beneficial. --Elise (does NOT rhyme with police)
On december 14 Elise gerich wrote to the above recipients: Some of the information in the RADB is "historical." It was carried over from the PRDB for purposes of the transition from the NSFNET Backbone Service to the current US Internet Architecture. The RA team has been working with CA*net and ANS to reduce duplicate route objects which are artifacts of the transition. Several months ago, approximately 3000 routes were deleted from the RADB because CA*net worked with us to identify which routes were now being maintained in the CA*net DataBase. Approximately, 1000 route objects have been deleted as a result of a request from ANS more recently. Approximately 20% of the route objects that existed at the time of the transition have been removed. COOK: So when you say 20% of the routes have been removed, how does one judge what remains that is defunct and still remains to be removed???? Of the 80% does anyone have a clue as to whether 95% of the 80% are "good" or whether the real total of good routes might be on 50% of the 80%?? Now Elise has questioned the propriety of using NANOG for questions about the routing arbiter. Fine. But as far as I can tell no one is running a routing arbiter mail list. Without such a list the only choice is to take things to one on one private mail with bill manning and/or elise. Perhaps Merit would be willing to establish such a list? If Merit declines, would someone else do it? ********************************************************************* Gordon Cook, Editor & Publisher Subscriptions: Individ-ascii $85 The COOK Report on Internet Individ. hard copy $150 431 Greenway Ave, Ewing, NJ 08618 USA Small Corp & Gov't $200 (609) 882-2572 Corporate $350 Internet: cook@cookreport.com Corporate Site Lic. $650 http://pobox.com/cook/ for new COOK Report Glossary of Internet terms *********************************************************************
In message <Pine.SUN.3.91.951226143523.1922H-100000@tigger.jvnc.net>, Gordon Co ok writes: Dear concerned netizen, :-)
COOK: So when you say 20% of the routes have been removed, how does one judge what remains that is defunct and still remains to be removed???? Of the 80% does anyone have a clue as to whether 95% of the 80% are "good" or whether the real total of good routes might be on 50% of the 80%??
The US had the PRDB and Europe had the RIPE database and both were good things. The RIPE database was a better format since the PRDB was AS690 specific. The PRDB had accurate data but no origin AS and some field mismatches with the RIPE-181 format, but served as a good seed. For the most part, the 20% that was removed at CANET, ANS, RIPE, and MCI request is now better validated and resides in these databases. The remaining 80% is not neccisarily wrong. The only thing that need to be right is the mapping of prefix to origin AS, since the origin AS is primarily what people who generate prefix lists use as the basis for routing. It would be nice if the contact information was right too, but not essential. The job of removing any inaccuracies due to remnants of the old PRDB AS690 policy which became the AS690 advisories for a (too long) interim period is squarely in the hands of ANS and we're working on it but not by throwing up our hands and throwing it all out as some suggest. We are going through it somewhat systematicly, verifying policy toward origin AS and specific exceptions, with priority given to any routing trouble tickets that arise. Doing this manually is not a very promising approach, so we are hoping for better tools to help identify obvious problems and building some ourselves. The PRDB was used mostly to populate route objects. The stuff that was originally populated from the PRDB, if unchanged would have a "changed field" with nsfnet-admin@merit.edu in it. If that's gone, then someone updated the information. If still there, either the information wasn't updated or whoever updated didn't change the field (it wasn't checked until recently). There are 23,175 such records (with nsfnet-admin@merit.edu in the changed field) of 45,361 in the RADB (local copy ftp'd yesterday). In the 5 IRR databases, there are a total of 342,720 records (counting aut-nums, people, inetnums, route objects, and everything else). The IRR is more than just the RADB and the RADB data, though seeded from the PRDB and initially somewhat questionable, is clearly being maintained. [note: these counts are based on some quick greps, but I think they are accurate.]
Now Elise has questioned the propriety of using NANOG for questions about the routing arbiter. Fine. But as far as I can tell no one is running a routing arbiter mail list. Without such a list the only choice is to take things to one on one private mail with bill manning and/or elise.
I didn't save Elise's message but I think she was asking that the public "feedback" on the quality of Sprint's service (and everyone else mentioned) didn't fall under the umbrella of operational issues requiring cooperation among providers (or whatever the wording was). I don't think any new mailing list is needed. Curtis
Curtis, that was very helpful -- thank you! If I could ask a few further questions. You said: "The RIPE database was a better format since the PRDB was AS690 specific." 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? Just testing whether I understand you correctly. Glad to know that you think nanog is appropriate for this discussion. I am trying to understand where we are at this point and am not trying to saddle any particular person or entity with any blame. You are being helpful and I appreciate that. ********************************************************************* Gordon Cook, Editor & Publisher Subscriptions: Individ-ascii $85 The COOK Report on Internet Individ. hard copy $150 431 Greenway Ave, Ewing, NJ 08618 USA Small Corp & Gov't $200 (609) 882-2572 Corporate $350 Internet: cook@cookreport.com Corporate Site Lic. $650 http://pobox.com/cook/ for new COOK Report Glossary of Internet terms *********************************************************************
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
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. 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
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
hwb@upeksa.sdsc.edu (Hans-Werner Braun) writes: 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.
Indeed there is an evoloution of routing policy databases/registries. The early NSFnet one was done to configure a single backbone. Remember that EGP was the state-of-the-art. NSFNet provided last resort routing and everyone was happy. More complex registries were not needed to keep track of this even when "back doors" appeared. In Europe the situation was not like that at all. Despite great efforts we were never blessed with a single pan-European backbone or even a last-resort routing service. This is why RIPE developed a routing registry that was capable of being useful in a general topology of indepoendent ISPs. We weren't more clever or had more foresight, we simply had the need earlier. I think it has been a good decision by the RA team to use this technology and to contribute to its development rather than inventing something new right away. Given the resources I would hope for more output in the way of tools etc. but I see it coming now.
Often despite complaints from many sites that wanted free and uncontrolled flow of routing information.
This is a great misconception about routing registries which comes from the time of the single backbone model. The routing registry and the backbone were then operated by the same people and used to enforce The Routing Policy. The situation is different now. Each ISP sets and enforces their routing policy. The routing registry only supports them in this. Of course a good routing policy is to not propagate routes to address space which is not assigned and to generally filter announcements from customers. But there is no way to use the routing registry to force ISPs to do reasonable things.
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.
I am pessimistic at all. All routing registies use the same schema or very very similar ones. They currently call come from the ripe-181 specifications which are based on input from the RA people. The RADB, RIPE RR, MCI RR and all the others really form a global Internet RR which is quite useful already and can be made more useful. Two things are needed now: 1) Improve active maintenance by the registrars. This will by itself lead to better alignment between registries and remove duplicate registrations. 2) Produce and *deploy* more useful tools. If this is done well, ISPs will use those registries more and register in them because it is useful and interest. Daniel
participants (8)
-
Curtis Villamizar -
Daniel Karrenberg -
Elise Gerich -
Gordon Cook -
hwb＠upeksa.sdsc.edu -
Mike -
Peter Lothberg -
Susan Hares