RIPE 33

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