RIPE 37

R I P E   3 7    A M S T E R D A M
Routing Working Group Session
14-Sep-2000 Draft Minutes

Chair: Joachim Schmitz (JS395-RIPE)
Minutes: Mark Bukowy
Participants: 97

A. Preliminaries

Joachim chaired the meeting, gave a brief introduction, and passed around
the participants' list. Asking for a scribe to take the minutes of the
session lead to the usual panic in the audience that one of them may be
chosen deliberately by the chair, but to general relief Marek Bukowy
volunteered, and took the minutes you are reading now.

The agenda for the session was accepted without changes.

The minutes of last RIPE meeting (RIPE36) distributed earlier on the mailing
list were accepted by the audience, and thus are declared final.

Remaining actions from earlier meetings were:

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

This has become part of the RIPE NCC activity plan for 2001,
allocating resources for this project; also a part on multicast
has been added. From the point of view of that this has been
initiated, the action is considered closed.
Both the IPv6 and the Routing WG will continue to follow the
development.

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

The draft document has been prepared and is available at the URL
http://www.ripe.net/ripencc/pub-services/db/reimp/new-transition-v3.ps

34.R1 on C.Panigl
Provide updates to RIPE-178
-done-

Christian has provided the updates which are available as RIPE
document RIPE-210. However, the contents has triggered additional
dicussion; accordingly, we will have some short presentations and
input from the audience later during the session

36.R1 on RIPE NCC
During the transition phase to the RPSL software
- verify with RADB on their test suites for RPSL implementations
- coordinate with RADB on consistent mirroring of databases (NRTM)
- coordinate with RADB on consistent whois interface of databases
including irrd

This action is still ongoing

Multicast Workshop Report

As part of the introduction, Joachim reported on the Multicast Application
Workshop which had been held on Tuesday. It had been fully organized and
prepared by Patrick de Muynck (BELNET). He himself gave some presentations
and got additional contributions from Steve Simlo (Cisco), and Andreas Bogk
(integrated media). Both BELNET and Cisco provided the hardware, making
the practical presentations possible. Together with the RIPE NCC they built
the demonstration network.

Joachim thanked all people who worked to make the workshop a success, in
particular Patrick who spent most of the time on that. The audience of
70 participants was definitely very pleased with the workshop which is
considered to be a great success.


C. RADB Update (Gerald Winters, Frontier Global Crossing)
presentation available at
http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/gerard_winters
/

Gerald summarized status, development, and future projects around RADB.
In particular
* recent developments were
- conversion to RPSL complete
- Merit's maintainer fee program receives broad community support
- additional features around interface like autoformatting and atomic
transaction support
- PGP key-cert object support
- work is ongoing regarding "RPS Dist"
* Relational DB backend
Instead of using flat files, RADB now employs a relational database
backend (TimesTen), allowing relational queries when using IRRd. For
several features this has already proven its usefulness, but there
are also concerns whether the software will meet the performance
requirements. This is being tested.
An important note is that the IRRd integration with the TimesTen backend
will become available as open source code.
* Scaling issues
Due to the growth of the community, RADB is faced with various scaling
issues. Work has been done to improve the situation but not all of it
is easily tackled.
* Future projects
Gerald mentioned the following projects which will be dealt with in the
future
- RPS auth implementation
- GPG support
- IRRd v2.0 release
- introducing software for bug tracking which will be open to the
community

The presentation was particularly interesting because it did not only show
the status of RADB as one of the main registries in the world, but also
the different development and focus due to differing boundary conditions
and requests from the community compared to the RIPE database.


E. RIS, Status and Plans (Henk Uijterwaal, RIPE NCC)
presentation available at:
http://www.ripe.net/ripencc/pub-services/np/Talks/0009_RIPE37/

Henk gave a brief overview of several items, glancing first at
administrative
stuff like more staff becoming available for the project, and announcing
the PAM2001 workshop dealing with measuring data on the Internet. Details
are available at the URL http://www.ripe.net/pam2001

The highlights of the past months were
- upgrades of the database server to handle the increased load
- introduction of a 2nd router collector, installed at the LINX
- development of the new tool showing ASs in use, which can be tried at
http://abcoude.ripe.net/ris/asinuse.cgi
- generation of daily reports

In the upcoming months, RIS development will be contined, in particular
improving performance, and increasing data input. The intent is to move
this to production during the course of 2001.

In a question from the audience, it was referred to an observation of RIS
during the previous RIPE meeting: RIS sees more prefixes in the union of
all peers than what is generally known as the defaultless routing table.
The question was whether this is now understood?
Henk reported that no definite answer has yet been found. Discussions were
held at SitCom, IETF, and some ideas on how to attack this problem have come
up. However, this is still work in progress.


F. The Routing Registry Consistency Project (Shane Kerr, RIPE NCC)
presentation available at:
http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/rrc/

Shane gave an introduction to this new project initiated in the Routing WG.
Essentially, it builds on
- RIS, the Routing Information Service, where life data from the Internet
is collected
- and the RIPE IRR
comparing both sets of data. The main goal of the project is to make the
database more accurate, and thus more useful.

Suggestions of user interfaces were presented, and what the current status
of the project is: As this presentation was a introduction to new work,
the project is still in the initial research phase, but they also start to
build comparison tools.


G. Study of BGP Convergence (Abha Ahuja, Internet Network Services)
presentation available at:

http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/RIPE-37-conver

gence/

The title of the presentation had been changed to "Delayed Internet Routing
Convergence", focussing on a very interesting facet of BGP convergence.

Essentially, the question is how well the Internet infrastructure does
tolerate faults. According to conventional wisdom fault toleration seems
to be high and problems are resolved fast.

This has been put to the test with a simple failure analysis: To this end,
a route is inserted or withdrawn at one point on the Internet, and its
visibility is measured at other places on the Internet.

There were quite some surprises found in the analysis of the results.
In particular, the idea that "bad information travels fast" is actually
wrong. It was shown that in 60% of the cases, complete withdrawal of an
invalid route takes more than 2 minutes.

The reason for that lies in the fact that all possible paths must be
explored and then individually invalidated. This becomes a problem which
grows as the factorial of the number of BGP speakers, and results from
avoidance of loops. Essentially, this means that in the extreme, BGP may
not converge at all.

So far, we are saved by BGP policies, and several BGP timers which put a
bound on some of the behaviour. However, with an ever growing Internet,
this becomes more and more of a problem.

The presentation caused a vivid discussion, in detail:

Q: What was the path length between the point of injection of the
withdrawal
and the measuring point ?
A: variable (different ISPs were used in the measurement). Conclusion is
that
it has no influence.

Q: Does route flap dampening help achieve better convergence ?
A: Yes, it would bound some of the announcements. However, the worst case
scenarios don't really occur in real life.

Q: The effectiveness of dampening is though determined by its settings?
A: Definitely. Some people in the room have been affected by wrongly set
dampening parameters. Injected announcements alternated with withdrawals
will be dampened if they are "oscillating" faster than the flap dampening
timers allow.

Q: This was also the reason for ripe-178. Have you been able to reproduce
this effect in the following situation: 2 AS's connected in 4 places, a
withdrawal would travel 4 times between the AS's. In effect, one route
flap would appear 4 times, and consequently the BGP neighbours would
damp the route immediately.
A: There was no real conclusion on that question; however, it is obvious
that complex situations are generated easily. Christian Panigl who
described this example, will discuss this in detail with Abha for
further real life studies.

Q: On internet exchange points all peers are directly connected to each
other. Would that be a potential for similar effects?
A: Ideally, these peers are not exchanging full routing tables, but only
their internal and their customers' routes. The theoretical worst case
scenario shown here can happen if you provide mutual transit.

Q: Does it also apply to IGP meshes as they are growing bigger ?
A: There is obviously some impact, but details are not known, because Abha
and her colleagues have not yet looked at it. However, it will be taken
up


H. Routing Table Analysis (Philip Smith, Cisco)
presentation available at:

http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/RIPE37-sept200

0-Smith.pdf

The studies of Abha were nicely complemented by the routing table analysis,
Philip does and has recently started sending to the Routing WG mailing list.
He described the work he is doing there in his presentation, thanking APNIC
for their support, also showing some interesting findings and developments.

Essentially, Philip analyzes the full defaultless Internet routing table,
taken in daily snapshots. An important part is the correlation to the
three regional registries and IANA definitions.

Important findings are in the global summary
- routing tables again growing exponentially, in particular
100k prefixes will be reached by end Dec 2000 (6 months ago predicted
to be Sep 2001)
same applies to ASs (10k will be reached Dec 2000)
- origin AS rising very significantly
- average AS path length more or less stable somewhere 5...6
- max path length 15 also quite stable (removing prepends)
- worried in particular about exploding /24 announcements
- and longer prefixes (why should they be announced?)

An interesting observation is that
- only 62% of address space allocated is actually announced
- less than half of 17000 assigned ASs are actually announced

This presentation also triggered some discussion:

Q: Do you strip out duplicate ASN's (to compensate for providers with funny
routing policies)
A: I think I do. I am certainly stripping out any ASpath pre-paths.

Q: Assigned and not announced ASN's: some might not wish to exchange
traffic.
A: Looking at the ASN's < 10000 there are clusters of not announced ASN's,
most notably US military, but also others.

Q: Is there an effect of prefix filtering and who is doing it?
A: This would most likely become real apparent only when looking at several
sources of routing information because it is difficult to determine where
more specifics disappear


I. RIPE-210 - Updates with contributions from the audience
(Philip Smith, Cisco, & Christian Panigl, Vienna IX)
presentation available at:

http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/dampening.pdf

First, Philip gave a presentation discussing issues he has seen in the
RIPE-210 document. He found that RIPE-210 and RIPE-178 have different
network lists which leads to confusion. Moreover, the damping parameters
as described do not work. However, the discussion showed that the effect
of the parameters depend on the Cisco IOS version, which seems to indicate
a Cisco implementation bug, which would need further study. There was no
information available about other implementations.

Philip then showed some pages from Cisco teaching materials explaining
route flap damping, especially the definition of the parameters involved,
and how to properly combine them. There was general consensus that it makes
sense to incorporate something like this in the document, but also try to
get input about how to configure flap damping for other platforms. Philip
also found some open questions like whether we would want to suppress
slowly oscillating prefixes, or whether we may want to make damping
dependent on prefixes, AS paths, or communities.

From the audience, the question arose whether any data exists on route
oscillations on the Internet, and whether any studies were done. Philip
was not aware of any research effort. He had started gathering some flap
statistics in Australia, but thinks that doing this at a more central
place on the Internet would be much more useful. Abha reported that Merit
did a study on announcements/withdrawals a couple of years ago at some US
exchange points, measuring oscillations rates etc (for reports about this
experiment please contact Abha Ahuja). However, currently no measurements
are done. Abha indicated that she is interested to take it up again in her
measurements, and data is collected at the RIPE RIS project anyway - it
just needs to be analyzed (which is an additional input for RIS
development).
Nonetheless, in a whole it is interesting to see that damping methods exist
but no studies on their effect or efficiency on route flaps on the Internet.

Finally, Christian had a few more comments. He explained that he had come
up with a list of "golden networks" to exclude from route flap damping due
to an incident on a network: routes to the TLD/root nameservers became
dampened and those unreachable for more than two hours. The reason for that
was insufficient connection to the global Internet, so flapping on the
upstream backbone (single connection to the global Internet) can cause
exactly this problem. However, keeping the list of networks uptodate is
difficult, and we want to avoid having different versions of the same
document around. One suggestion was to explicitely flag it as an example
which should not be implemented as is. However, experience shows that
exactly those examples are most often just copied without crosschecking.
Therefore, the idea was to remove the explicite list in its entirety from
the document. Instead, Daniel Karrenberg offered to write a script and
make it available, which generates a list of the "golden networks",
essentially the networks of the TLD/root nameservers (using "dig" on
one of the root nameservers).


J. Promoting IP Multicast deployment in Europe (Tony Ballardie
)
presentation available at:

http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/RIPE37-sept200

0-Ballardie/

Tony is anticipating a large demand for multicast, and thus introduced the
European IP Multicast Initiative (EuMI). He wants to assess sources of
problems with multicast deployment, and pro-actively promote it by proposing
a "one-stop shop" with
- free consulting (limited in time to about a day)
- free forum for exchanging ideas
- gather input and (re)write documents, explain RFC's, etc
to provide for clear, easy to use, documentation. Both sponsors and input
is needed for this project. Details can be found at http://www.eumi.net.

With those presentations the session had significantly run overtime into the
coffee break but thanks to meeting management, there was still enough coffee
available for the participants who then came to visit the joint session of
the routing and database working groups. The joint session was introduced
because of the overlap on the topic of transitioning from the old RIPE-181
database to the RPSL style database.


B. Status of the transition to the RPSL database (Andrei Robachevsky, RIPE
NCC)
presentation available at:
http://www.ripe.net/ripe/meetings/archive/ripe-37/presentations/r37-reimp/

The biggest question was discussed first: what is different in the new
implementation. This was illustrated by a whole set of examples, where
many of them are based on RPSL itself, and its impact on the various
objects and attributes in the RIPE database. Moreover, Andrei pointed out
that there will also be other differences, around working with the database
(querying with a bunch of new options, submissions to the database now with
MIME support extended PGP support), near realtime mirroring, and accounting
and access control.

Andrei then gave an overview about the status the project was in, regarding
functionality and availability of test servers. The software is still in
beta status and is still tested. Certain features are missing, in particular
the overall server infrastructure (backup, cleanup, logging, etc). Others
need further development, most notably MIME support, server configuration
and administration, and portability of the code has room for improvements.

The essential pointers for test usage and information are
- near real time mirror of the RIPE database (contains current data in RPSL
format): "whois -h rpsl.ripe.net"
- test server for submissions: mail for submissions and
"whois -h rpsl.ripe.net -p 4343" for queries
- mailing list db-beta@ripe.net
- RIPE NCC development team reachable at dbrip@ripe.net
- web page http://www.ripe.net/ripencc/pub-services/db/reimp/

Then, Andrei described the transition plan again briefly with its various
phases, which had been agreed upon quite some time ago. The initial phases
I and II have passed, and we are moving to phase III, which moves the
authoritative source of the RIPE database to the new server, with RPSL
format. All output would then be RPSL, submissions will be possible with
RPSL style to an RPSL input, and with RIPE-181 style to the old existing
standard address (mail ). This move will only be done
depending on confidence and consensus in the community.

Only after a certain transition time, phase IV will start, still allowing
RIPE-181 submissions, but to another mail address, while the standard mail
interface at auto-dbm@ripe.net will only accept RPSL style. This will allow
to slowly phase out RIPE-181, which in phase V will then no longer be
accepted.

Finally, Andrei listed a set of obvious transition issues. The list of
issues is definitely not yet final, and any input from the community is
welcome. To present a focus of concerns and to drive the transition, the
Database Migration Task Force has been initiated.


Y. Creation of the Database Migration Task Force.

For the Database Migration Task Force, Ulf Kieber (UK41-RIPE) has agreed
to be its chairman. For communication of the task force, the RIPE NCC will
set up the mailing list

reimp-mig-tf@ripe.net

Everybody is encouraged to participate. Participation of people involved
in:
- mirroring the database (format and software will change)
- parsing the routing registry output (format will change)
is particularly welcome. Topics will also include the portability of the
new db software.


Summary of Open Action Points

36.R1 on RIPE NCC
During the transition phase to the RPSL software
- verify with RADB on their test suites for RPSL implementations
- coordinate with RADB on consistent mirroring of databases (NRTM)
- coordinate with RADB on consistent whois interface of databases
including irrd

37.R1 on C.Panigl, P.Smith, D.Karrenberg, J.Schmitz
Provide updates to RIPE-210
- general editing, review
- explanation of damping parameters
- examples by implementation
- script to determine TLD/root nameservers for "golden network" list

37.R2 on RIS team, Henk Uijterwaal
Implement route flap analysis from RIS data


Marek Bukowy, Joachim Schmitz, January 2001