Re: Routing registry was Re: Sprint BGP filters in 207.x.x.x?
At 10:30 PM 12/13/95, cook@cookreport.com wrote: ...
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?
I think you are assuming too much at this point. [About contractually having to play with the RA.] You should address that question to Sprint, rather than the mailing list. I believe SprintLink has voiced their willingness to work with any tool that will help the Internet scale better, so long as it does not have adverse effects on their network. The last time I checked, the _biggest_ argument against using the RA was that alot of the data is incorrect. I have also heard a lot about work that has been done to clean up the RA. Is this still the biggest factor? -Jeff [mssg. from the nanog archive...] ================================================================================== | Knowing Sean for who he is, I'm fairly sure that no RADB or RS will ever be | suitable to him. In particular... On the contrary; I believe Peter Lothberg's proposals for an RS scheme are quite reasonable. I think his criticisms of the current RADB and RS models are pretty well known, and valid. I would point out one more thing though, and that's that at the Stockholm IETF I had a genial chat with a number of folks from MERIT and the RA Team in general, and suggested several ways that the RADB could be made incrementally useful. I hope that some good comes out of that conversation. I'll use any tool that will make my job easier, and help our operation and the Internet scale better. At the moment, though, the RADB does the opposite, and the RS has no value whatsoever. Sean. ===================================================================================
Of course sprint is running a nap too. i understand that their position is that the NAP is full. They have a BUNCH of people trying to get into the NAP who are complaining to me that they get no answqers from sprint as to when that will be possible.
******************************************************************** Gordon Cook, Editor & Publisher Subscriptions: Individ-ascii $85 The COOK Report on Internet Individ. hard copy $150 431 Greenway Ave, Ewing, NJ 08618 Small Corp & Gov't $200 (609) 882-2572 Corporate $350 Internet: cook@cookreport.com Corporate Site Lic. $650 Web: http://pobox.com/cook/ Newly expanded COOK Report Web Pages ********************************************************************
On Wed, 13 Dec 1995 Jeff.Ogden@um.cc.umich.edu wrote:
The large scale provider MichNet uses is MCI and they are required to cooperate with the RA and others. This is in their contract. I suspect that something similar might be in some of the other contracts of providers that provide service to networks that received funding from NSF for Interregional Connectivity. People might want to go read the fine print in their contracts. -Jeff Ogden Merit/MichNet
Perhaps I owe some apologies for being harder on Sprint last night than I should have been. Is there a routing arbiter list to which I should take this discussion?? If so please let me know where and how to join and I'll gladly oblige. In the meantime let me summarize what I am learning. Jeff Hayward points out: The NSF funded regionals, not NSPs. There is no requirement in NSF93-52 that makes use of the RA mandatory. The only requirement placed on the regional's choice of NSP is connection to all priority NAPS. Cook: But apparently NSF funded R&E regionals must ALSO make their routes available to the RA? For a friend at NSF writes privately to me that: There is no requirement that anyone "use" the services of the RA. Specific requirement is that:
Regional Networks and their selected NSPs must route and carry all traffic originated at and/or destined for U.S. Research and Education sites. Moreover, Regional Network Providers must make their routes for all such (U.S.Research and Education) sites within their (respective) regions available to the Routing Arbiter.
Then Jeff Barrows makes and interesting and useful point: The last time I checked, the _biggest_ argument against using the RA was that alot of the data is incorrect. I have also heard a lot about work that has been done to clean up the RA. Is this still the biggest factor? -Jeff
From Nanog archives jeff barrows cites sean doran as having said:
I would point out one more thing though, and that's that at the Stockholm IETF I had a genial chat with a number of folks from MERIT and the RA Team in general, and suggested several ways that the RADB could be made incrementally useful. I hope that some good comes out of that conversation. I'll use any tool that will make my job easier, and help our operation and the Internet scale better. At the moment, though, the RADB does the opposite, and the RS has no value whatsoever. Sean. Now Bill Manning didn't NAME sprint yesterday in his complaint that I have cited. But no one has told me that anyone else besides sprint was intended for the criticism. Perhaps the question boils down to those raised by Sean in the preceding paragraphs? What does need do be done to the RADB and RS to give them value? There seems to be some strong disagreement between the Routing Arbiter and Sprint. Why? What do they see so differently? And if MCI, PSI, UUNET and ANS don't agree with sean's criticisms why don't they? ******************************************************************** Gordon Cook, Editor & Publisher Subscriptions: Individ-ascii $85 The COOK Report on Internet Individ. hard copy $150 431 Greenway Ave, Ewing, NJ 08618 Small Corp & Gov't $200 (609) 882-2572 Corporate $350 Internet: cook@cookreport.com Corporate Site Lic. $650 Web: http://pobox.com/cook/ Newly expanded COOK Report Web Pages ********************************************************************
Now Bill Manning didn't NAME sprint yesterday in his complaint that I have cited. But no one has told me that anyone else besides sprint was intended for the criticism. Perhaps the question boils down to those raised by Sean in the preceding paragraphs? What does need do be done to the RADB and RS to give them value? There seems to be some strong disagreement between the Routing Arbiter and Sprint. Why? What do they see so differently? And if MCI, PSI, UUNET and ANS don't agree with sean's criticisms why don't they?
Thank you for the clarification. I was pointing out a process that would reduce the value of a routing registry. Extrapolations of that description to any specific provider would be presumptous without first hand knowledge. Now there is some truth in the statements wrt data accuracy in some sections of the IRR. I understand that providers who run sections of the IRR and use that data for router configuration tend to keep the data very accurate. In other sections of the IRR, the data has some historical reference and may be out of date. There is continued effort within the RA to identify the bogus data and find ways to remove it from the RAdb portion of the IRR. A process which would improve the accuracy of the data in the IRR is for providers run sections of the IRR on thier own, and use that data for their own router configurations. Now I understand that most large-scale providers do in fact, have databases for account managment. Some even use that data for router configuration. Now if they can export the formats that are specified in for IRR interoperability they are Km ahead in being able to participate in the IRR.. with vastly improved accuracy of data. -- --bill
Gordon Cook writes:
[some text deleted] Then Jeff Barrows makes and interesting and useful point:
The last time I checked, the _biggest_ argument against using the RA was that alot of the data is incorrect. I have also heard a lot about work that has been done to clean up the RA. Is this still the biggest factor?
-Jeff
The Routing Arbiter Service has two components - the Route Servers (RS) and the Routing Arbiter DataBase (RADB). The RADB is one of the components of the Internet Routing Registry (IRR). 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. Another area where the RA team has been agressively making efforts to maintain current information is the maintainer objects. On the recommendation of the RIPE routing working group, the EOF and NANOG, the RA team populated the incomplete maintainer objects from information in the InterNIC. The direction that we received from the community was that the maintainers of the data are the only folks authorized to modify the data. The RA team contacted those maintainers and has indicated that the team is ready to make large scale changes in the data in the RADB based on changes authorized by the maintainers of the information. ESnet, Delphi, PIPEX, ANS, internetMCI and CA*net (and probably other organizations) all maintain up-to-date information in the various components of the IRR (RADB included). And because they maintain up-to-date information, that information is useful to them and the rest of the community. The RA team has announced a tool which converts cisco configurations to database format, and the team is willing to work with any organization which wishes to make large scale changes in stale data. --Elise
-----BEGIN PGP SIGNED MESSAGE-----
"Elise" == Elise Gerich <epg@merit.edu> writes:
Elise> Another area where the RA team has been Elise> agressively making efforts to maintain current Elise> information is the maintainer objects. While I know this is true (I've seen it and applaud efforts to have accurate POC information for everything), I am amused by the maint record for AS 2885: : chops.icp.net-MHRC ; NT-AS2885 mntner: MAINT-AS2885 descr: People authorized to make changes for AS2885 admin-c: Not Available from RADB upd-to: AS2885@ra.net auth: MAIL-FROM epg@merit.edu auth: MAIL-FROM jyy@merit.edu mnt-by: MAINT-AS2885 changed: DB-admin@ra.net 950201 source: RADB since I believe that Jessica Yu now reads email at ANS... Elise> recommendation of the RIPE routing working Elise> group, the EOF and NANOG, the RA team populated Elise> the incomplete maintainer objects from Elise> information in the InterNIC. Hm, what about the "complete" ones? There is a striking comparison to be made here: : chops.icp.net-MHRC ; whois 2885 RA-NAP (ASN-NAP-FOUR) Information Sciences Institute 4676 Admiralty Way, Suite 1001 Marina del Rey, CA 90292-6695 Autonomous System Name: NAP-FOUR Autonomous System Number: 2885 Coordinator: Manning, William [RA Project Mgr] (WM110) bmanning@ISI.EDU (310) 822-1511 Record last updated on 17-Aug-94. between what the InterNIC folks have in their database and what you have in yours. Gee, who's got the RIGHT information??? (Automation wants to know...) Sean. P.S.: Elise> The RA team has announced a Elise> tool which converts cisco configurations to Elise> database format, and the team is willing to Elise> work with any organization which wishes to make Elise> large scale changes in stale data. Well, this is good news, actually. Sean. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP Public Key in ftp://ftp.sprintlink.net/engineer/smd/pgpkey iQCVAwUBMNOockSWYarrFs6xAQFKdQP/UBC01uJHIXV1YzpYZ2f/RhbShmYlAHPa g/CFluhsxTl2+g3Zrc9UGuMHjAFBct7MWV025VFJ3FPxDR1SieXBhUBFO8RJKWwn KAUyLktNBkk6SSKPLHcxBgKl3E9mcWB+mrR+eL6n0z6Z/WDjqhm1mRBC89fqONy3 qOpVjaf0VDM= =tboE -----END PGP SIGNATURE-----
Sean, Thanks for pointing out that the information stored at the InterNIC or any of the other address allocation registries, may be inconsistent with the point of contact information in the routing registries. Folks who apply for addresses often delegate the job of maintaining routing information to others. The information in the InterNIC is a starting point for identifying contacts when information is missing. --Elise
Sean Doran writes:
-----BEGIN PGP SIGNED MESSAGE-----
"Elise" == Elise Gerich <epg@merit.edu> writes:
Elise> Another area where the RA team has been Elise> agressively making efforts to maintain current Elise> information is the maintainer objects.
While I know this is true (I've seen it and applaud efforts to have accurate POC information for everything), I am amused by the maint record for AS 2885:
: chops.icp.net-MHRC ; NT-AS2885 mntner: MAINT-AS2885 descr: People authorized to make changes for AS2885 admin-c: Not Available from RADB upd-to: AS2885@ra.net auth: MAIL-FROM epg@merit.edu auth: MAIL-FROM jyy@merit.edu mnt-by: MAINT-AS2885 changed: DB-admin@ra.net 950201 source: RADB
since I believe that Jessica Yu now reads email at ANS...
Elise> recommendation of the RIPE routing working Elise> group, the EOF and NANOG, the RA team populated Elise> the incomplete maintainer objects from Elise> information in the InterNIC.
Hm, what about the "complete" ones? There is a striking comparison to be made here:
: chops.icp.net-MHRC ; whois 2885 RA-NAP (ASN-NAP-FOUR) Information Sciences Institute 4676 Admiralty Way, Suite 1001 Marina del Rey, CA 90292-6695
Autonomous System Name: NAP-FOUR Autonomous System Number: 2885
Coordinator: Manning, William [RA Project Mgr] (WM110) bmanning@ISI.EDU (310) 822-1511
Record last updated on 17-Aug-94.
between what the InterNIC folks have in their database and what you have in yours.
Gee, who's got the RIGHT information???
(Automation wants to know...)
Sean.
P.S.: Elise> The RA team has announced a Elise> tool which converts cisco configurations to Elise> database format, and the team is willing to Elise> work with any organization which wishes to make Elise> large scale changes in stale data.
Well, this is good news, actually.
Sean.
-----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP Public Key in ftp://ftp.sprintlink.net/engineer/smd/pgpkey
iQCVAwUBMNOockSWYarrFs6xAQFKdQP/UBC01uJHIXV1YzpYZ2f/RhbShmYlAHPa g/CFluhsxTl2+g3Zrc9UGuMHjAFBct7MWV025VFJ3FPxDR1SieXBhUBFO8RJKWwn KAUyLktNBkk6SSKPLHcxBgKl3E9mcWB+mrR+eL6n0z6Z/WDjqhm1mRBC89fqONy3 qOpVjaf0VDM= =tboE -----END PGP SIGNATURE-----
participants (5)
-
bmanning＠ISI.EDU -
Elise Gerich -
Gordon Cook -
jbarrows＠digex.net -
Sean Doran