draft minutes of the RIPE33 Routing WG session

Dear colleagues,

please find enclosed the *draft* minutes of the RIPE33 Routing WG session.
I apologize for late distribution which was caused on my side due to not
finding any allocatable time slots lately...
If you have comments, corrections, or additions, please bring them to the
WG session on Wednesday the latest.
Thanks
   Joachim
--- JS395-RIPE -- standard disclaimer ---

Draft Minutes of Routing WG session - RIPE 33, 5 May 1999
---------------------------------------------------------

Chair:     Joachim Schmitz (JS395-RIPE)
Scribe:    Roman Karpiuk (RK-RIPE), Ambrose Maggee (AMRM-RIPE)
Attenders: around 80


A. Preliminaries (Joachim Schmitz)

   Joachim welcomed the participants, passed around the participants' list,
   and asked for a volunteer scribe. Roman Karpiuk volunteered to take the
   minutes.

   The working group agreed upon the minutes of the previous meeting, and
   accepted the agenda circulated earlier on the mailing list.

   Review of previous actions:

   o 29.R1 G.Winters, J.Schmitz, RIPE NCC
           Definition of the IRR and an AUP
     -in progress-
           Work is ongoing. Action still open.

   o 31.R1 RIPE NCC, D.Kessens, J.Schmitz
           Basic design for an IPv6 IRR
     -in progress-
           Work is ongoing. Action still open

   o 32.R1 RIPE NCC, JLS.Damas
           Prepare draft document on RIPE-181 -> RPSL transition issues
     -in progress-
           We will have a presentation from the RIPE NCC on this topic
           Work is ongoing. Action still open

   o 32.R2 J.Schmitz
           Write project definition for Routing Registry reality checking
     -in progress- 


B. Status Report: RPS Standards & Drafts (Cengiz Allaettinoglu)
   http://www.ripe.net/meetings/ripe/ripe-33/pres/rps-status.ps

   Joachim welcomed the chairmain of the IETF RPS working group Cengiz
   Allaettinoglu. He gave a status report on the RPS standards and drafts.
   The report is also available at the RIPE web server.

   He first gave an overview of current work items. The most important news
   was that RPSL (Routing Policy Specification Language) is now a proposed
   standard. A series of tutorials had been held at various Internet meetings
   around the world, and RPSL has been implemented at several registries or
   is currently worked on.

   Cengiz then talked in more detail about two more topics, the RPS WG deals
   with
   - Routing Policy System Security
   - Distributed Routing Policy System
   which were then discussed in more detail.

   * Routing Policy System Security

     Again and again, there are occurrences that someone on the Internet
     leaks someone else's prefix, in most cases accidentally due to errors
     in configurations. To establish means to improve stability and integrity
     of Internet routing, a security model has been developed within the
     scope of the RPS WG. It includes
     - authentication
       essentially based on the work of the RIPE DBsec taskforce which has
       developed a model using PGP (draft-ietf-rps-dbsec-pgp-authent-01)
       as an example for authentication
     - authorization
       ongoing work of the RPS WG which is already pretty mature and discussed
       in draft-ietf-rps-auth-03
     A set of simple exmaples was given illustrating where questions arise
     who has authority over a set of prefixes. Accordingly, as set of rules
     had been developed, to create, update, or delete objects. At the
     registries this may be achieved by introducing a set of new keywords
     in the respective objects.

     Since this is still ongoing work, further input from the community was
     requested.

   * Distributed Routing Policy System

     The current status of this topic is summarized in draft-ietf-rps-dist-01.
     There are two main issues, finding
     - a protocol for replication of data
     - rules to ensure correctness of data
     The first of the two is relatively easy and commercially available,
     based on a flooding mechanism including pull and push with automatic
     discovery. For simple copies of the data a light-weight option will
     be available.
     The second issue is much more difficult to deal with. The correctness
     of data must be ensured in all copies. This can only be achieved by
     proper delegation while maintaining true authorization throughout.
     In addition, changes must propagate correctly to maintain overall
     consistency. Finally, a method must be found for grand fathering legacy
     objects.


C. Report from the RIPE NCC (JLS Damas)
   http://www.ripe.net/meetings/ripe/ripe-33/pres/routing-wg-report/index.html

   The report gave a brief overview of the RIPE database. More details and
   numbers were included in the extended review of the Database WG. However,
   some interesting numbers were given. The database currently contains
   17,000 route objects, where 8,000 are not announced. One quarter of those
   which are announced, are announced by another AS than they have been
   registered for.

   The database software has now reached version 2.2.2. In the old code only
   bug-fixing is done. The re-implementation of the database software has
   highest priority, and makes good progress.

   At this RIPE meeting, again an RPSL training course has been held. There
   were 40 participants. In the future, RPSL training courses will be offered
   together with the LIR courses as an extension on a separate day.

   Regarding the new strong authentication method by PGP: the number of key
   certificates has now reached 50, and 55 maintainers use PGP (even though
   15 of them still have weaker authentication methods active at the same 
time)
   Thus, even though the PGP implemenation currently is the only secure
   method of authentication, only a minority is using it.


D. RPSL transition: Issues and progress (JLS Damas)
   http://www.ripe.net/meetings/ripe/ripe-33/pres/rpsl/index.html

   The RIPE NCC has been dealing with a number of issues around transition
   from RIPE-181 to RPSL like how to
   * align modifications to data between both formats
   * maintain data availability throughout
   * continue with deployment
   In particular, Joao summarized again which modification occur to the
   presentation of data when moving from the RIPE-181 format to the RPSL
   format.

   As a consequence of the transition process, while all routing registries
   so far have used RIPE-181, from now on, some registries will no longer
   support RIPE-181 and instead use RPSL only, as all new registries will
   do in the future. Therefore, the community was again pointed to the fact,
   that if automatic procedures or programs are used today to process routing
   registry data, everybody must start thinking today of changing these
   procedures.

   Due to the focus on re-implementation of the database software, at RIPE
   we are still in phase II of the transition (for a description of phases
   see discussions and presentations in earlier sessions of the Routing WG).
   Other registries are already close to have reached phase III, the final
   migration to RPSL. This is shown in the following presentations. Actually,
   the only native RPSL server is that written by David Kessens.


E. Reports from other registries

   - Overview (D.Kessens)
     http://www.isi.edu/ra/rps/transition

     David went through the description of transition phases which can also
     be found on the given web pages. This included the software which has
     been developed so far. Much emphasis was on the RIPE-181 to RPSL
     converter tool which plays a crucial role in the transition.

     David and ISI were also deeply involved in the education of RPSL and
     its usage. They held a series of tutorials during NANOG and Apricot
     meetings.

     The registry maintained by David is currently in phase II status as
     well, but ready for phase III. This is still the old style software
     and is not built on the re-implementation of the RIPE database software
     which has not yet been finished.

   - RADB (A.Ahuja)
     http://www.ripe.net/meetings/ripe/ripe-33/pres/radb-status/index.html

     At the RADB there are currently three production servers, two for
     RIPE-181 format, and one for RPSL format. However, the RPSL style
     database may only be queried. All three support the IRRd software,
     which in its gamma release now also supports RPSL queries.

     Thus, RADB is currently in pahse II of the transition. Some development
     is still ongoing, and phase III is expected to be reached towards
     autumn.

     The most important issue which then remains to be solved, is to combine
     all individual routing registries in a true authentication/security
     environment. Work on this has already started.

   After these presentations a few questions were discussed, being related
   to transition issues. People were worried about a smooth transition.
   While submissions in RIPE-181 format will automatically be converted to
   RPSL, reading data from the database with whois is not obvious. There was
   a suggestion to use a different port for RPSL whois queries which is not
   easy to get. Others proposed an additional switch, flag, or option to the
   whois client to deal with RIPE-181 vs RPSL issues, or suggested that
   RIPE-181 support could be done with a separate program, excluding RIPE-181
   support from the whois interface. There was no final conclusion.
   The topic will be included in the transition document to be provided
   by the NCC, and also be discussed in the Database WG.


F. Why the Internet does not scale (Abha Ahuja)
   http://www.ripe.net/meetings/ripe/ripe-33/pres/internet-dev/index.html

   The title of the presentation was changed to "Some Interesting Internet
   Developments". In general, we are still seeing the "standard" Internet
   behaviour of exponential growth, e.g. with amount of traffic flows.
   Accordingly, the imminent collapse of the Internet is predicted since
   years e.g. address space, bandwidth, etc. However, new solutions are
   developed as well (IPv6 address space, DWDM on fiber, etc).

   One important topic in this discussion also is topology. Abha presented
   some data on the global topological state of the Internet. Orginally,
   only one major backbone existed, the NSFnet, showing some strong hierarchy
   in the network. This was given up in favor of a few exchange points. In the
   meantime, the number of exchange points and probably more prominent the
   number of individual connections has led to a dense mesh of links.

   This is clearly visible if looking at the default-less Internet routing
   table. While the number of prefixes has reached a more or less stable
   level below 45,000 the number of routes has continued to increase at a
   steady rate (around 80,000 in Jan-99). Most of this is due to multihoming
   and more paths introduced by more meshs in the network, leading to a
   steeper growth than would be expected from the rising number of ASs in
   the global routing table (from around 1,000 in Jan-96 to about 4,000 in
   Jan-99).

   In this time interval the average AS-path length has first increased from
   2.75 up to 3.25 (around early spring '98) and since then decreased again to
   values about 3.15, meaning that on average only 3 ASs must be traversed to
   reach a destination. At the same time, the average prefix length has very
   slightly decreased and now has a value around 22 bit. This is the only
   visible effect of CIDR, which originally was introduced to reduce the
   number of routes on the Internet. CIDR definitely has its advantages but
   due to changes in Internet topology, it was not able to noticably affect
   the size of the globabl routing table. This is nowadays called the "myth
   of CIDR".

   In a whole the changes lead to problems due to constraints at various
   points, especially the increased volume describing the topological state,
   and the frequency of changes impacts backbone routers. This leads to
   higher end-to-end loss and latency, introducing convergence problems.
   In addition, the network management complexity makes dealing with problems
   in the network much more difficult.


G. MBone Developments (K.Kayser)

   Kurt Kayser gave a very brief overview of MBone developments. As it turns
   out there is not much traffic on the corresponding RIPE mailing list. In
   general, development is slowing down because industry does not support it.
   On their side, real media seems to be of more interest. Thus, MBone is more
   dealt with on the academic side. Projects currently deal with comparison
   of unicast multimedia vs multicast, and questions of stability. Otherwise,
   news on MBone had already been discussed at the EOF session.


Y. General I/O with Other WGs

   There was no input from, and no output to bring to other WGs.

Z. AOB

   Since there were no additional comments or issues, Joachim closed the
   WG session.

---

Agenda
------

 R I P E  3 3         V I E N N A
 Routing  Working  Group  Session
 5-May-1999      2nd Draft Agenda

 A. Preliminaries (Joachim Schmitz)
    - introduction
    - participants' list
    - volunteering of scribe
    - agenda bashing
    - RIPE 32 minutes
    - actions from earlier meetings

 B. Status Report: RPS Standards & Drafts (Cengiz Allaettinoglu)

 C. Report from the RIPE NCC (JLS Damas)

 D. RPSL transition: Issues and progress (JLS Damas)

 E. Reports from other registries
    - RADB (Abha Ahuja)
    - Overview (David Kessens)

 F. Why the Internet does not scale (Abha Ahuja)

 G. MBone Developments (Kurt Kayser)
    - to be confirmed -

 Y. General I/O with Other WGs

 Z. AOB


Summary of open Action Points
-----------------------------

29.R1 G.Winters, J.Schmitz, RIPE NCC
      Definition of the IRR and an AUP

31.R1 RIPE NCC, D.Kessens, J.Schmitz
      Basic design for an IPv6 IRR

32.R1 RIPE NCC, JLS.Damas
      Prepare draft document on RIPE-181 -> RPSL transition issues

32.R2 J.Schmitz
      Write project definition for Routing Registry reality checking

Ambrose Maggee, Roman Karpiuk, Joachim Schmitz, 18-Sep-1999
---