Skip to main content

You're viewing an archived page. It is no longer being updated.


RIPE Meeting:


Working Group:




Revision Number:


Please mail comments/suggestions on:

R I P E 4 1 A M S T E R D A M
Routing Working Group Session
15/16-January-2002 Minutes

Chair: Joachim Schmitz - JS395-RIPE
Scribe: Matthew Williams-Bywater

A. Preliminaries

Joachim welcomed us all to the meeting and declared it open. The
Participant's list was then handed out by the chair and Matthew
from RIPE-NCC volunteered to take the minutes.

The proposed agenda for this session and minutes from the previous
at RIPE40 were approved without hesitation by the attendees.

Action points from earlier meetings:

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

39.R1 on J.Schmitz, D.Kessens and F.Parent
Initiate IPv6 IRR task force

The item above was considered done by participants. Florent
Parent has already published an Internet draft proposal,
"RPSL extensions for IPv6 and Multicast Routing Policies",
which can be found at URL:

40.R1 on Kurt Keyser, Joachim Schmitz and Philip Smith
Create "Multihoming Document" for LIRs

First Session: 15-January-2002
- ------------------------------

B. Henk Uijterwaal: Routing Information Service, Status and Plans

Presentation available at URL:

Two Route Collectors will be added to the Routing Information Service:

one located at Netnod-IX in Stockholm and another at NSPIXP2 in Tokyo.

The latter has received a feed from APNIC since August last year, but
its announcement as a service was delayed until January 2002 due to
hardware issues. Next steps include finding one or two locations in
the United States and investigating the added value of more collectors
in Europe.

Currently, Route Collectors are present at:
* LINX, London
* SFINX, Paris
* AMS-IX, Amsterdam
* CIXP, Geneva
* VIX, Vienna
* NSPIXP2, Otemachi (Tokyo)
[Planned: Netnod-IX, Stockholm]

Total of 178 BGP sessions

As part of the continuous improvement of the RIS, a 700GB RAID was
installed at the RIPE NCC. It is estimated that the new hardware will
fulfil storage needs until the end of this year. Additional changes
improvements will be announced to the mailing list,
[email protected],
maintained by majordomo at RIPE NCC. Hopefully, the mailing-list will
also become the natural forum for discussions about RIS data.

Since the last meeting, manuals and FAQ's have been added to the web
The manual pages contain typical examples on usage and interpretation
different RIS query options. More cases will be appended in the

Due to the time-gap of one hour between data collection and insertion,
it was
decided to implement a Looking Glass on each of the Remote Route
It has most of the standard options found elsewhere on the Internet. A
query type has been created for users as an attempt to target flaps,
RIS TopN Utility. It produces lists of prefixes on demand, where high
withdrawal or announcement activity was registered over a specified
interval. High counts could indicate some kind of problem for certain
The RIS team will start running the queries regularly to produce
Top Ten reports over "active" prefixes and AS numbers.

The utility can be found at URL:

Furthermore, Henk and his team will continue its work on finding
flaps". In February 2002, a student will start devoting his time to an
experiment that involves announcing/withdrawing fake routes and
when changes are registered by Remote Route Collectors. A
of people from AT&T Research and RIPE NCC will analyze results from

Another project, the RISreport, has had to be redesigned due to
issues when adding new plots. The switch to the re-implementation will

commence within the next few weeks.



C. Engin Gunduz: Routing Registry Consistency Check Project

Slides available at URL:

Engin held a short introductory presentation regarding the RRCC
project and
its future. The main objectives of the project are targeting
between the RIPE Routing Registry, making the RIPE RR reflect de facto

Internet Routing Policies and, by making it more accurate, also more
for Network Administrators. The RRCC will use RIS data, currently from
and compare it to information stored in the RIPE RR.

RIPE201, published in December 2001, provides an overview of the
project and
is intended to solicit input from interested parties. It can be found
at URL:

There is also a prototype available on the RRCC web site.
See URL:

The prototype is updated daily using, as previously mentioned, RIS
data and
provides the following query types:
* unregistered, but advertised prefixes
* registered, but not advertised prefixes
* unregistered peerings

Future plans include making different subscription services available
to the
community and producing metrics that measure improvements in RR data
quality. Community feedback can be sent to: [email protected].



D. Philip Smith: Internet Routing Table Analysis Update

Slides available at URL:

Philip Smith has added a number of new variables to the Internet
Routing Table
statistics, which are available at URL:

New variables include:
* "Count Unique Prefixes" - Eliminate all subnets of prefixes
appearing in the
routing table, e.g. is announced, but all subnets are
ignored. Represents the Internet Routing Table's smallest
theoretical size
without losing address space, but may lead to routing problem if
* "Prefixes after Maximum Aggregation" - Eliminate all subnets of
appearing in the Internet Routing Table that appear originating from
same AS, e.g. is announced from AS1849 and all subnets
the same AS are dropped/ignored. Represents the aggregation effort
from AS,
not taking traffic engineering into account, and the smallest
size of the routing table without losing any detailed reachability
* "IP Addresses in Use" - Previous error which over-counted address
* "Origin-only ASes" - Counts ASes which only originate prefixes and
are not
seen in transit paths from Smith's BGP view.
* "Transit-only ASes" - Counts ASes which are NOT originating prefixes
only in transit paths from BGP view.

The Internet Routing Table had 107232 entries on the 11th of January
Smith's view. On the same day, counts for 'Unique Prefixes' and
after Maximum Aggregation' were 52095 and 71370 respectively, where
latter gives us a theoretical estimate of the routing table's size if
aggregation were to be employed. Philip had also observed some
trend changes in the BGP table since early last year after the
collapse. A previously non-linear growth of the amount of tables
entries has
practically stabilized itself at approximately 107k routes. Similar
can also be seen in the amount of announced ASes on the Internet.
other examples on how to interpret statistics, including comparative
observations between RIR regions, were presented at the meeting.



E. Andre Oppermann: BGPDNS - "Using BGP Topology Information for DNS RR
a Scalable Way of Multi-Homing"

Presentation available at URL:

BGPDNS is both concept and protocol for achieving server multi-homing
needing your own AS and PI address space. Reasons for multi-homing
servers to several ISPs include:
* Link Redundancy
* Load-Balancing
* Independency

However, this approach has drawbacks for the community as large:
* Fragmentation of IP address space
* Excessive memory and CPU requirements on Internet Core Routers
* Exhaustion of current AS number space

Considering that BGPDNS overcomes many disadvantages of traditional
multi-homing, it may someday become the viable alternative. The method
not require an unique AS number or PI address space, while still fully

maintaining aggregates. When a request is received by the authorative
at the site, it will interact with the BGPDNS server, via the protocol
the same name, to determine which of its 'A Records', all
corresponding to a
particular server, is the best reachable IP for the requester. This
can be
achieved by having the BGPDNS server establish its own listening-only
sessions with route servers at each upstream provider.

The mechanisms for determining which IP that should be listed first in
DNS response, i.e. used by the source, are relatively easy to
Firstly, the BGPDNS server performs a "show ip bgp" for the requesters
to establish the best path back to the source and, secondly, another
ip bgp regexp" for the left-most AS in order to determine the
originating from there. The A record IP that belongs to that address
will be given priority over the others. When the DNS server sees the
it will list the corresponding IP first in the response packet sent
back to
the requester. The source will then use this destination IP to
establish a
session with the target server. More detailed information can be
attained by
reading the RFC draft.

RFC draft and patches are available at URL:


Q: Other solutions using NAT yet?
A: BGPDNS with NAT is in the pipeline.
Q: Does BGPDNS support IPv6?
A: Yes.



Second Joint Session with the Database WG: 16-January-2002
- ----------------------------------------------------------

F. Marc Blanchet: IPv6 and Multicast routing policies using RPSL

Slides can be found at URL:

Currently, RPSL doesn't define IPv6 nor multicast routing policies.
At RIPE-40, a task force was initiated to document the usage of
above in current classes and then, if required, define modifications
to the present implementation of RPSL.

The current proposal aims at making the changes generic, i.e. not only

limited to IPv6 and multicasting, and also minimizing the number of
additional classes/attributes. These goals are based on ideas from
Florent Parent's initial draft and discussions on the mailing list
([email protected]) and at IETF52.

See URL for the latest draft proposal:

Although the current RPSL database will remain intact, the suggestions
that a new server will be required for both the present database and
protocol extensions. Obviously, clients and current tools, e.g.
will also have to support these changes.

Next steps include porting the IRRtoolset to support the new
moving the document forward at IETF and continuing the discussion on
mailing list. Members can subscribe to it by sending an email to:
[email protected].

Discussion - "The Inconsistent Syntax of Proposed Sub-Attributes

João Luis Silva Damas (RIPE NCC) - a) Does not like afi/safi because
not easily read/written by humans, easily processed by machines
Better to do classes. b) Prune things that are not used or required.
c) Describe transition IPv4 -> IPv6, in particular tunnels.

David Kessens (Nokia) - a) Wants to add minimal IPv6 support b) Does
want to prune nor simplify RPSL, maybe just exclude unused things c)
No new
classes, just add/modify attributes to get running more swiftly.
requires many changes to all tools, not only IRRToolSet, but also
developed tools.

Ping Lu (Cable & Wireless) - Supports new classes as well.

Andrei Robachevski (RIPE NCC) - a) Also supports new classes. Does not
to complicate RPSL just to make it appear more intelligent. b) Charter
far concerns only extensions of RPSL. We also need RPS auth.

David - Distinguish between new classes, new attributes and new
Ping - From an operational standpoint: We want to build an IPv4 route,
so we
want to look for an IPv4 route class. Same goes for IPv6. If the
offers two distinct classes, then the user will only have to use one
hash for
deriving route.

Larry Blunk (Merit Network) - New commands would have to be added to
server. Same would be required for IRRToolSet, IRRd, whois etc.

David - a) The difference between IPv4 and IPv6 can easily be found by
but does this include future address formats? Probably not, so please
use implicit information. b) Another idea would be to identify topics
commencing work on a deployment plan.

Per Heldal (Private) - What about using a proxy as front-end to the
as a method for cloaking syntax or attribute changes from tools and

Wilfried Woeber (UniVie/ACOnet) - Are the IPv4 and IPv6 players the
same? Are
the infrastructures the same? Do we have an issue at all?

Ping - Again: Please don't change the sub-attribute context. Much too
complicated and will require changes to existing modules that analyze
parse the present RPSL.

Gert Doering (SpaceNet) - Same AS numbers are used, meaning that IPv4
and IPv6
attributes must be in the same class.

Ping - Agrees, but more concerned about sub-attribute context

Joachim Schmitz (AOL) summarizes the discussion:
* We need to continue our debate regarding the charter: RPSL
(IPv6, multicast, transitional elements) and RPS Auth.
* There is currently no consensus on the future apparition of
RPSLng. We will have ask different groups to take on certain
tasks and then develop proposals.

Z. Input from other WGs

See discussion under item F.

Summary of Open Action Points from the Routing WG

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

40.R1 on Kurt Keyser, Joachim Schmitz and Philip Smith
Create "Multihoming Document" for LIRs

41.R1 on Marc Blanchet, David Kessens, Florent Parent and Joachim
Continue work on "RPSL extensions for IPv6 and Multicast Routing

41.R2 on Joao Damas, Engin Gunduz, Shane Kerr, Andrei Robachevsky and
Joachim Schmitz
Continue work on the Routing Registry Consistency Check project

- ------------------------------------------------------------------------
- ---
In memory of an important contributor to the RIPE Routing Working Group
a valued member of the Internet community - Abha Ahuja (1972-2001)
- -----------------------------------------------------------------------

Joachim Schmitz, Matthew Williams-Bywater, February 2002