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(a)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)
_______________________________________________________________________________
