Minutes of the Routing WG session (first draft)

 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@localhost
 DFN Network Operation Center
 Rechenzentrum der Universitaet Stuttgart                ++ 711 685 5576 voice
 Allmandring 30                                          ++ 711 678 7626  FAX
 D-70550 Stuttgart                                       FRG (Germany)
_______________________________________________________________________________