Routing WG M I N U T E S Thursday, 12-10-95, 9:00 - D R A F T - (additions/corrections welcome) Chairman Jan Willem Scheun was ill. Rob Blockzijl volunteered as temporary chairman for this specific session. There was no draft agenda. It was set up on the fly with three topics 1. The RA Project a presentation by Brian Renaud (Merit) 2. The RIPE Routing Registry an overview by Daniel Karrenberg (RIPE NCC) 3. RIPE Routing Registry, R & D overview by Daniel Karrenberg (RIPE NCC) There were no additions from the audience. 1. The Routing Arbiter Project presentation by Brian Renaud (Merit) After filling in the historical background an overview was given of the transition from the old NSFNET PRDB to the new RADB and a description of the current situation including Route Servers and some current data from the present RADB. Then the current initiatives were presented, e.g. continued clean-up of the database, generation of usage and analytical reports, support for RSPL extensions, and support for PGP authentication (with a trial setup running at the moment). Afterwards, Brian Renaud gave a review of the tools recently developed at the RA Project. There are several tools which handle, e.g. configuration from the database policy generator from configuration monitoring of running networks These tools are now not only developed for the Router Servers (which are Sun Workstations) but also for Cisco Routers. There are also various tools under development which among other things feature a GUI for selected tasks. Brian Renaud wants input on the tools from anybody who wants to use them or has contributions/suggestions. Mail addresses are on the transparencies which will be made available soon. A C T I O N on Brian Renaud: Making the transparencies of his presentation of the RA Project publicly available (both on the Merit and the RIPE FTP/ WWW servers) 2. The RIPE Routing Registry Daniel Karrenberg only had a few remarks - The RIPE database is cleaned up from obsolete data. In most cases the responsible persons are directly contacted - The data in the registry are compared to the real world - Tools for the router configuration from the database are most valuable. The NCC wants to make the Merit tools better known in Europe and wants to participate in their development (see below) and immediately opened the discussion. The topis were: - How to handle changes with large numbers of objects (both RADB, RIPE)? They may be done using the automatical machine interface or by submission to the human interface by personal mail (especially for global changes). - Is the RADB publicly available like the RIPE database? It may be fetched via FTP from the Merit server. However, it may be made available on the RIPE server. They mirror it anyway. A C T I O N on the RIPE NCC and Merit: making the RADB publicly available on the the RIPE FTP server (if Merit concords) - What is the status of the advisory tag? The advisory is not yet obsolete. ANS still needs it for operation. For European ISPs advisories are only necessary in the RIPE database. There is no encouragement to register in more than one registry because of the planned GRR which is under construction. A C T I O N on the RIPE NCC: find a FINAL date together with ANS when to give up advisory tags. This was especially stressed by Daniel Karrenberg. - Do ISPs register in the RIPE database? They do not only register but surprisingly many also maintain their data. This is enforced by the RIPE NCC a bit which makes registration of a routing policy mandatory when registering a new AS. There is a general feeling that many more will register and maintain data if proper tools exist to make it easier. Data on the database population will be made available again (as it was done in the PRIDE project). The quality of the data will be checked by RIPE NCC (whether data are updated, consistent, correct...) - There was some discussion on authentication, PGP, and cryptography, mostly related to the RADB as first implementation and future ideas for the RIPE database. PGP authentication by signature is formally a simple new value of the "auth"-tag in the maintainer object (RADB test suite). However, the PGP keys must be savely stored at the database site. There was some discussion on how to do this (in or out of the database). From the experience of both RIPE NCC and Merit there were only very few attempts to willingly change objects of other parties when not being allowed to. They were all detected through the notification facility (which is the same for RADB and RIPE database because the same database manager code is used). Therefore, it does not seem to be necessary to have strong authentication (or even cryptography). However, some organisations like PTTs have stronger security demands and ask for it. They would not register without. 3. RIPE Routing Registry, R & D Rob Blockzijl points out that the RIPE NCC wants to enforce R & D again. Daniel Karrenberg states that the RA people do more for the progress than the RIPE NCC. The RIPE NCC and the Routing WG should/want to do more. A focus should be found to make information in the routing databases significantly more useful. A first step had been taken by development of diagnostic tools in the PRIDE project. This effort should be extended not only on diagnose but also on tools for configuration and real time analysis and monitoring. There are other fields which should be considered but these are the most important. More useful architectural work should be done and one area should be chosen to join the efforts of the RA project group. The following discussion in the audience did not lead to a final conclusion on which area to chose. Therefore, two actions are placed on the RIPE NCC: A C T I O N on the RIPE NCC (Daniel Karrenberg): to trigger the discussion on the mailing list of the Routing WG, which focus to choose for a future tool development project and to come to concensus on it. A C T I O N on the RIPE NCC (Daniel Karrenberg): based upon the focus found in the Routing WG to prepare a draft paper for the new project and to present it at the next RIPE meeting in January. Scribe: Joachim Schmitz, DFN-NOC ---------- If I forgot anything or did not record something correctly just send me your additions/corrections. Thank You! Regards Joachim Schmitz _______________________________________________________________________________ Dr. Joachim Schmitz schmitz@rus.uni-stuttgart.de DFN Network Operation Center Rechenzentrum der Universitaet Stuttgart ++ 711 685 5576 voice Allmandring 30 ++ 711 678 7626 FAX D-70550 Stuttgart FRG (Germany) _______________________________________________________________________________