RIPE 35

Chair : Joachim Schmitz (JS395-RIPE)
Scribe : Emil Gorter (EMIL-RIPE)
Attenders: 92


A. Preliminaries (Joachim Schmitz)

Joachim welcomed the participants, passed around the participants' list,
and asked for a volunteer scribe. Emil Gorter 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 31.R1 RIPE NCC, D.Kessens, J.Schmitz
Basic design for an IPv6 IRR
-postponed-
Even though this topic is still considered important, there
had been not enough input to continue

o 32.R1 RIPE NCC, JLS.Damas
Prepare draft document on RIPE-181 -> RPSL transition issues
-in progress-
The draft document is prepared, but not yet publicly available

o 34.R1 C.Panigl
Provide updates to RIPE-178
-to be closed-
Needs to be published

B. Report from the RIPE NCC (JLS Damas)

The report consisted of two parts:
- transition to RPSL
- consistency checking of the IRR
which were discussed in a combined presentation

- Transition to RPSL

RPSL will be implemented in the RIPE database software v3.0 which is nearly
complete and beta code is available for downloading. The new db can be
tested at

reimp.ripe.net:43

It will accept no updates, only queries on an almost real time mirror of
the
current database. It will be tested for 2 months (already started), so
testers are welcome to try. Any RPSL object stored in the test database
will
not be mirrored back into the RIPE-181 production database. Thus, we are
still in step one of a three step process:

1. Mirror current db in RPSL
2. Accept updates in RPSL and RIPE-181, RIPE-181 will be converted to RPSL
3. Only accept updates in RPSL

For details more information may be found at

www.ripe.net/ripencc/pub-services/db/reimp/index.html

If there are concerns about the procedures, RIPE NCC would appreciate input
to be incorporated in the reimplementation document (action 32.R1).

The question arose what happens with any RPSL update done today. They are
definitely not visible on the current database. However, it is obvious that
during the transition process any test objects in the RPSL part must not be
moved into the new RPSL production database.

- Consistency Checking of the IRR

The goal of the project is to compare BGP data from life Internet to
routing information stored in the RIPE IRR, and analyze the results.
The input gathered so far will be incorporated in a draft document.
This document is expected to become available around RIPE 36.

However, it is important to note that the reimplementation effort and the
transition to RPSL is run at a higher priority, and this project will only
be worked on fully after the reimplementation has been finished.


C. RADB/IRRd Update (Gerald Winters)

http://www.ripe.net/ripe/meetings/archive/ripe-35/presentations/ripe35-radb-GW
/index.html

Gerald gave an overview of the topics presented
- recent developments
- IRRj
- scaling issues
- on the horizon
which were then discussed in detail.

* Recent developments

Probably the most important item with regard to the database was that
Merit/RADB converted to RPSL which was completed in Nov-99. For two
months, in parallel any RIPE-181 updates would overwrite existing RPSL
objects. On 1-Jan-2000, RIPE-181 was discontinued, meaning that RADB is
now fully and only accepting RPSL.

The experience with RPSL is that most users are satisfied, but only very
few users actually make use of advanced RPSL features. In a whole it
seems
that the community still becomes used to RPSL.

The second very important topic relates to the organizational structure
of RADB. In the past it has been fully subsidized by Merit. Now, Merit
is completing the transition to a commercial funding model, which charges
a yearly fee to all maintainers registered in RADB.

The consequence is that maintainers who do not pay the yearly fee, in
the end may be removed from RADB, including all their objects. However,
RADB is important, and nobody shall be excluded. People, who do not want
to pay fees are therefore encouraged by Merit to open and run their own
registries, which is supported by Merit to publish the code of the db
software. There is already some interest for this, and Merit will then
mirror those who request it. Actually, Merit expects to reduce its role
as a database administrator.

This statement caused a lot of discussion. Concerns uttered covered
- do ISPs need to register in all databases?
the answer is no - "private" registries will be mirrored at RADB
- how to avoid duplicates then, or correct references (Christian Panigl)
this is likely to be a problem; there are some measures taken or
under consideration. Merit will definitely start removing old
duplicates themselves. It is strongly recommended that when a
company starts its own mirrored registry, they should remove their
object from RADB.
- the existence of duplicates actually is not a new problem, but it will
be more difficult to handle if the number of registries explodes?
in principle this could be solved by prioritizing registries, which
may be difficult thinking of which criteria to use. Therefore, clear
criteria must be defined for the "private" registries where to query,
and what to store
- while prioritization probably solves the question of retrieving data,
it does not solve the question of consistency; does the IRR consistency
project help here?
probably yes, at least as a supportive action; however, getting
registry data is also a matter of completeness
- who is allowed to open a registry, and who is then allowed to insert,
delete, manipulate copies of objects in which registry?
in principle, any body may open a registry; however, ownership of
objects should not change in this process (AS, route objects).
Actually,
nobody should be allowed to delete or work on these objects. This may
really become a problem if upstream providers decide to set up their
own registries, even more for multihomed services. This would require
multiple registrations, not necessarily transparent for downstreams.
The general feeling was that this development should be very closely
observed.
- is Merit acting here a bit early with RPS Dist not yet in place?
actually, we are currently on the move, starting to develop procedures.
It is quite obvious, that someone running a registry being disjoint
from the others, the data may not be used for configurations on the
Internet, meaning that the corresponding networks will not or will only
be reachable partly. This will generate peer pressure to at least
mirror
each other properly. Nonetheless, at least for small registries, there
is a definite need for central support, and most likely also for a
resolution authority in cases of dispute.

As a general bottom line, it became very much obvious that the Internet
is very much differently organized in the US compared to Europe. Much
of the problem for Merit is posed by introducing its new funding model,
where for RIPE it already exists and is accepted in the community. In
the US, the community is much more heterogeneous than in Europe.

* Scaling issues

Funding is not the only issue, Merit has been working on. The demand
of users of the database has risen that much, that scaling has become
an issue. The load on the production server has increased that much,
that a second one had been introduced, where requests are distributed
applying a DNS round robin mechanism. Updates are only done on one
machine, requests are handled by both. To handle slow connections, small
pipes, or large queries, parts of the software have been adapted to
speed up processing.

* IRRj

A new development is the routing registry tool IRRj, opening another
interface to the database. It is programmed in Java, and connection
based,
in contrast to the usual e-mail interface. It allows fast updates and
features a graphical interface, which works more efficiently than updates
by e-mail.

It is obvious that IRRj can not make use of the "mail from"
authentication
method, which should be eliminated anyway because it does not supply
real authentication (easily forged). The idea is to move to PGP in
general.

* On the horizon

With the projects running and new developments, a list of action items
results. Most pressing is an implementation of RPS Dist, allowing
distributed databases. Merit is working to get an RPS Dist prototype
built which also depends on progress of the corresponding Internet
draft. However, it have already been decided that for authentication
between the distributed databases, PGP certificates will be used.

Another demand from the community is strong authentication/authorization
in the database. Accordingly, Merit is considering implementation of
the RPS Auth draft. Depending on resources work may commence around
mid-summer.

Finally, there is some new development on the database software itself.
With the help of Global Crossing, a relational database backend is
developed, where the TimesTen relational database is used. The work
will integrate IRRd in the backend. Resulting code from this project
will be open source.

The expected advantage of the project consists in higher performance
(due to structures intrinsic to the relational database software),
allowing relational queries, and better support for the allocation
registry functions.


D. Routing Information Service Status and Plans (Ripe NCC) Henk Uijterwaal

http://www.ripe.net/ripe/meetings/archive/ripe-35/presentations/ripe35-ris-hen
k/

Details of this report are available at the url specified above. In
addition
the RIS project has its own web pages at

http://www.ripe.net/ripencc/pub-services/np/ris-index.html

The goal of RIS is to collect default-free BGP data with timestamps, to
give a current and historical view of the Internet routing table. The
user interface will have the feel of a looking-glass "with memory". Once
deployed, RIS will also be used for consistency checking of the routing
registry.

The setup consists of major data collectors at major exchange points,
which transmit the data to a central collector and database at the
RIPE NCC.

Since Oct-99 the first test version is in use. However, there are still
a few items which need to be taken care of like
- open questions in the draft RIS document (RIPE-200)
- the hardware for the final setup must still be ordered
- consider process of data collection and storage, especially with regard
to the high data volume
The prototype currently implemented is available at

http://abcoude.ripe.net/ris/risalpha.cgi

A demonstration was available in the terminal room. The current setup
consists of one collector at AMSIX, and one machine for storage and
running the database. At AMSIX, currently 12 peering relationships are
active. Data volume collected is around 40 MBytes per peer and per day.
The total peering relationships are probably going to be increased to
around 70. Collected are BGP IPv4 announcements and withdrawals with all
BGP attributes. The collector sends updates to the central collector
daily - this frequency may be increased in the future.

Some results derived so far show
- there is a very high number of updates per day, which seems to
indicate a high level of instability; however at the same time the
number of withdrawals is very low
- the more peers we are looking at, the more prefixes are visible which
is interesting because we expect that some upper limit of prefixes
should be reached relatively fast (the full Internet routing table);
since they do not appear on the Internet routing table, these addtl
prefixes are called "dark prefixes"; the question is whether this
effect results just from more specifics being visible which are
otherwise simply aggregated
- this statement is supported by the finding that more than 50% of the
prefixes are /24
Besides these statistics, RIS will enable to find out who routes what
when. On top of this, flap-statistics may be generated. Suggestions on
additional usage is very much welcome from the audience.

The development is on schedule, a demo is available. Plans are built
on the actions indicated above, comprising implementation details,
and including more peerings. The basic question in the end how to turn
this into a regular service will be answered after these preliminaries
are resolved.

There was input from the audience, that similar things have already been
done in other areas of the world (e.g. a project at Merit). Results and
experience will be shared.

With these presentations the first slot of the meeting was closed.

E. Multicast Routing

The second slot of the Routing WG meeting was dedicated to Multicast
Routing, more precisely to show how providers have deployed it or are
planning to do it. This includes both backbone and Internet service
providers, and public exchange points. Not all of the presentations
are available yet, but will become available on the RIPE NCC web server
soon.

* Reports from Backbones

There are two prominent pan-European backbone providers: TEN-155 for the
education/research community, and the commercial Ebone network. For both
the current status, experience, and some plans were presented.

The TEN-155 multicast setup was presented by Jan Nowak. Due to the
different demands, levels of development, or specific implementations,
the network structure is highly heterogeneous. Quite a lot of problems
result from this. It was also recognized that some elements of multicast
are very sensitive to frame/cell/packet loss (depending on the under
lying carrier protocol).

In contrast, Peter Lothberg showed that Ebone is using native multicast
(avoiding any tunnels), only employing sparse mode, avoiding MHRSP
which removes problems like ghosting issues. MSDP is very much favored.
The result is a very clearly structured homogeneous network, which
is easy to manage and configure. The design includes backup scenarios
with redundant RPs to circumvent router failures.

* Reports from Public Exchange Points

Peter Lothberg immediately continued with his presentation on multicast
routing on the Stockholm DGIX. He gave some general design rules, and
shared his thoughts and experience. It was interesting to note that
DPT rings based on dark fiber are used for both unicast and multicast.

Niels den Otter followed with his presentation on the plans, AMSIX has
to add multicast (Amsterdam Internet Exchange). They are still in the
planning phase. According to Steve Walker, the LINX (London Internet
Exchange) is already a step further down the road: even though they are
still in the developing phase, they already have a testbed running with
several multicast feeds. On the one hand, more multicast feeds are
expected, and the LINX wants to switch to production sometime during
year 2000.

It is interesting to note that both AMSIX and LINX are deploying
multicast
on separate hardware, keeping it away from their unicast exchange
infrastructure. However, on the Stockholm DGIX unicast and multicast
are run on a common shared infrastructure.

* Reports from Active ISP Networks

Originally, there were reports planned from three networks.
Unfortunately,
Peter Heiligers on very short notice could not join the meeting, and
thus
the report from DFN was dropped.

The two remaining reports from Renater by Bernard Tuy and on Surfnet by
Niels den Otter showed the same situation like described for the backbone
networks. Renater has started relatively early with the French Multicast
Backbone (FMbone), and thus for historical reasons there are still
various protocols in use, and the network has been running on dense
mode. When the network grew, configuration with all the filters required
became just too complex. Therefore, Renater is now moving to sparse
mode, and will reduce the number of protocols used in their network.
Surfnet has also tested a few protocols, but for final implemenation
is adopting a model similar to Ebone, with PIM sparse mode throughout,
MSDP with backup RPs etc. The Surfnet multicast backbone will be
congruent to the unicast network, using the same routers.


Y. General I/O with other WGs

There has been no immediate I/O with other WGs.


Z. AOB

There was no AOB for this working group session.

Joachim announced that there will be held a multicast tutorial during
the next RIPE meeting in Budapest.

- - ---

Agenda
- - ------

R I P E 3 5 A M S T E R D A M
Routing Working Group Session
24-February-2000 Draft Agenda

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

B. Report from the RIPE NCC (JLS Damas)
- transition to RPSL (15min)
- consistency checking of the IRR (5min)

C. Report on the IRR at RADB (Gerald Winters) (20min)

D. Report on RIS (RIPE NCC) (20min)

E. Multicast Routing
- reports from backbones
* TEN-155
* Ebone
- reports from exchange points (15min each)
* Stockholm D-GIX
* AMS-IX
* LINX
- reports from active networks (15min each)
* Renater
* DFN (skipped)
* SURFnet

Y. General I/O with Other WGs

Z. AOB


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

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

32.R1 on RIPE NCC, JLS.Damas
Prepare draft document on issues of RIPE-181 to RPSL transition
- in progress -

34.R1 on C.Panigl
Provide update to RIPE-178
- in progress -

Emil Gorter, Joachim Schmitz, May-2000