Routing Working Group Session
17-May-2000 Draft Minutes
chair: Joachim Schmitz (JS395-RIPE)
scribe: Marek Bukowy, RIPE NCC
70 participants
A. Preliminaries
Due to some cancellations, less time was needed than originally
anticipated,and the first slot was not used, freeing up space for other
Working Groups (LIR overflow ;-) and reducing overlap with parallel
sessions.
The shortened agenda then looked like:
A. Preliminaries
B. Update to RIPE-178 (Christian Panigl)
C. Tnsition to RPSL (Andrei Robachevski, Joao Luis Silva Damas)
D. RIS, Status and Plans (Antony Antony, Henk Uijterwaal)
Y. General I/O with Other WGs
Z. AOB
Joachim welcomed the participants, passed around the participants' list,
and asked for a volunteer scribe. Marek Bukowy volunteered to take the
minutes.
There were no objections to the minutes of the RIPE 35 Routing WG
circulated just prior to the meeting. Joachim apologized for the very late
distribution and announced a period of one week after the meeting to allow
for possible amendments or changes to the minutes. In that time there was
one addition, but otherwise, the minutes were accepted.
Then the status of 3 old action points was reviewed:
o 31.R1 RIPE NCC, D.Kessens, J.Schmitz
Basic design for an IPv6 IRR
-postponed-
This action is sitting around for quite some time without much
progress. To give this a chance to continue, we considere to
define a project out of this and make it part of the NCC activity
plan
o 32.R1 RIPE NCC, JLS.Damas
Prepare draft document on RIPE-181 -> RPSL transition issues
-in progress-
The draft document is still being worked on, but not yet publicly
available, even though done for the most part. A presentation
during this WG session will provide an update
o 34.R1 C.Panigl
Provide updates to RIPE-178
-to be closed-
This is ready to be published as a RIPE document. Details will be
presented by Christian Panigl during this WG session
Before starting with the individual reports, Joachim gave a short overview
of the full day Multicast Routing Tutorial which had been held on the
previous day. There were 30 participants, who were not only following the
presentations, but encouraged by the great way of presentation, also
discussed quite a lot of issues around multicast routing. The thanks go to
Stefano Previdi of Cisco, who took the work on him to present and discuss
this topic at the RIPE meeting. For those interested in reading back on
the slides, look at ftp://ftpeng.cisco.com/ipmulticast.
B. Update to RIPE-178 (Christian Panigl)
The document was updated and will be assigned a new number.
Changes can be summarised as follows:
- access-list has been changed to prefix-list
(supported in IOS for quite some time now)
- list of root nameserver networks has been updated
- recommendations have been added to combine
no bgp fast-external-fallover with
per-neighbor keep-alive
for networks that need faster convergence than available
through default bgp timeout
- there also was a hint about BGP route refresh capability a.k.a.
triggered soft which is part of a set of enhancements (IOS 12.0.7 T&S)
* Discussion
A question was asked why "golden networks" which are recommended to be
excluded from route flap damping, are still needed, and why DNS fallover
to secondary nameservers was considered insufficient renundancy.
The answer is, that at least in Europe, many ISPs still have only one
upstream link. In such a case, if this network's border router operates
with flap damping enabled, route flapping caused by instability up the
stream prevents the network from accessing the whole Internet, including
all root server networks.
C. Transition to RPSL (Andrei Robachevsky, RIPE NCC)
The presentation is available from:
http://www.ripe.net/ripe/meetings/archive/ripe-36/index.html
The history of the project was presented starting 1998, going together
with a complete reimplementation of the database software. Motivation
included performance enhancement, new functionality and maintainability.
A decision was taken to do a full rewrite after modifying the old code
to support the referral mechanism and referential integrity.
The Alpha version has been online since 31 Dec 1999.
Next beta version including almost all queries, NRTM server (Near-real-time
mirroring, using the old protocol but serving RPSL objects) is online since
12 May 2000. It is kept up to date with the primary whois database by means
of NRTM.
The development is still focused on adding functionality. Portability
issues are not yet addressed; currently the development environment is
Solaris 6 and 7 on Sparc/intel and Mysql as the backend. Next steps are
documentation, testing and porting.
General differences between RPSL and ripe-181 were briefly discussed.
Some RPSL modifications will affect all objects, not only routing-related.
Those changes include:
- line continuation
- preservation of the line order and
- invalidity of empty attributes
In the data migration process, a remarks line
"This object is automatically converted from the RIPE181 registry"
will be added to all routing registry objects transferred from the current
RIPE database.
Some features of RPSL with regard to the routing registry specific objects
were presented (route, autnum, as-set). Regarding the related
implementation of rps-auth, several issues were discussed on how to use
member-of and member-by-ref in as-sets and autnum objects, together with
which update paths are included, and the "bilateral" nature of the member
specification.
Members-by-ref of the as-set specifies the mntners which are allowed to
claim membership of an autnum object by listing the as-set name in the
member-of attribute of the aut-num object. The old style specification
using "members" is still valid, but no searches on this attribute are
possible, rendering it nearly equivalent to a "remarks" line.
A comment was made that the irrd has such searches for RADB and this
should also be the case in RIPE. This discussion in conjunction with other
items discussed later on led to an action on the NCC (see below)
The same membership specification applies to route-set (present as
community in ripe-181).
Both sides must specify/allow membership, otherwise it is not effective.
An update of an aut-num object with member-of attribute will be rejected
if the as-set does not allow this membership.
Two attributes of the mntner object enable control over mntner objects
that are outdated and forgotten:
referral-by - pointing to the maintainer that created the mntner, and
auth-override - allowing deletion of the slack mntner by the
mntner listed in the referral-by attribute.
New query switches were also presented, which were implemented
to enable all queries needed by RAtoolset:
general:
-q version - displays version of the server
-q sources - displays available sources
as well as expansions of the collection of switches devoted to
address space related objects:
-l one level less specific lookup
-l / -L / -m / -M also available for in-addr domains now
-x exact match only (default is exact or less specific)
A request for active beta testing was expressed towards the community.
Query functionality of the new software can be tested with an
instance of the database holding real data, available at
reimp.ripe.net port 43 (where peering sets and route sets could not
yet be queried at the time the presentation was given).
Updates in RPSL can be sent to a new test database at auto-rip@ripe.net.
This database can be queried at reimp.ripe.net port 4343.
The PGP authentication is not functional as of yet, though.
Phase II of the transition will start end of June 2000 (current schedule),
Phase III depends on testing and consensus on the final transition.
* Discussion
A question was asked from the audience if the database software was going
to support the domain objects which are not defined by RPSL, and so could
be used by ccTLDs. The answer to this was positive.
Another question was asked if the irrd-style query commands (!commands)
for expansion were going to be provided. This started a short discussion:
while the syntax is not (yet) supported, the functionality of these
commands was already provided. A quick show of hands showed that about 4
people from the audience used this irrd functionality. Consequently, it was
felt to be a low priority issue for the moment.
A suggestion was made to intensify cooperation with Merit on testing the
new software using the test suites that Merit used during the transition
to RPSL.
An interoperability issue was raised. It was felt that it is essential
to ensure compatibility on the user-object level with irrd and whois,
so that the RIPE database could be used as an NRTM client of irrd or a
server for irrd in order to be able to accomodate all databases in a single
whois server. It was suggested to do that with filters if no other
way was possible. Nonetheless the highest possible level of
interoperability shall be maintained.
o 36.R1 on the RIPE NCC
During the transition phase to the RPSL software
- verify with RADB on their test suites for testing RPSL implementations
- coordinate with RADB on consistent mirroring of databases (NRTM)
- coordinate with RADB on consistent whois interface of databases
including irrd
Part of this work is covered by the rps-dist effort, but the Routing WG
explicitely asks RIPE NCC and Merit (RADB) to work closely together here
to guarantee interoperability, because rps-dist is not yet mature.
D. RIS, Status and Plans (Antony Antony, RIPE NCC)
presentation available at
http://www.ripe.net/ripencc/pub-services/np/Talks/0005_RIPE36/
Major topics of the presentation were
* introduction
* progress since RIPE35
* explanation current setup
* observations made
* plans
which are comprised below
* introduction
Goal of RIS: to store the history of inter-as routing information and make
this history queryable for the good of the community. It will also be a
foundation for the reality check project of the routing registry and trend
analysis.
The queries will allow viewing of a routing table at a specific point in
time as well as viewing of the changes observed during specified periods
of time.
This is achieved by collecting BGP data available to the project
participants at different points of the internet and storing at the
RIPE NCC.
New developments in the project since RIPE35 were presented:
- increase of the number of peers to 13
- web interface available at http://abcoude.ripe.net/ris/risalpha.cgi
* Discussion
A suggestion was made that a command line interface would be useful
for scripts.
It was explained that lots of information needs to be transferred to
the program as arguments, infeasible to do by hand, but technically
not a problem, because this is actually what is more or less behind
the web interface. It was suggested that a perl library could be useful.
This issue will be considered in more detail by the NCC.
A question on software availablility was asked.
It was explained, that the software consists of 3 components:
- BGP listener (MRT/Zebra) - available in public domain
- tool to insert the data into the database - written by NCC
- query engine - written by NCC
The components developed by NCC are not publicly available at the
moment, but this may change.
Following these questions, some remaining open questions were presented:
- investigation on hardware/software needed (scalability problems)
- decision on how long keep in the database (current plan for 3 months)
- how often should the dumps occur (now 3/day)
- how this should be turned into a regular service
It is estimated that for most of these questions answers will be found
from the experience during the current alpha phase, and later beta.
* observations made
'dark prefixes' still exist (difference between the union of all prefixes
available at all peers and the set of prefixes available to particular
peers, indicating fragments of the internet unavailable to the peers)
25.4 % of the IPv4 address space is currently announced and can be seen
by at least one RIS peer.
25.36% can be seen at NCC (equivalent of 19 /16s missing w.r.t the union
seen by RIS.)
25.32% can be seen at CERN (53 /16s missing)
(overlaps have been eliminated)
No trend can be observed so far, the instabilities are more of the
random nature and are sometimes high, like a /8 unavailable
at the NCC for a whole day.
The decrease on the graph of the number of prefixes can be explained
by about 8000 /30s observed before RIPE35 that were internal routes
of one of the RIS peers and have been withdrawn.
* Discussion:
These preliminary results triggered the question if there was a distinction
between announcements from the peers, meaning routes this peer tells to any
Internet peers, or the backbone routes, or those for their customers.
So far no consistency was enforced in requesting the peering policy from
RIS peers. Hence some differences in the set of prefixes covered can
appear.
Without the consistency, the results are not really comparable. It is
obvious that such a policy should be developed. This is considered to be
part of RIS, but also input from the community is required here.
Since the policies themselves were not going to be public and practically
no traffic was being sent from the RIS peers, it was pointed out that the
NCC should have no problems requesting RIS peers to peer with the RRC boxes
following specific policy guidelines. NCC will come up with a suggested
policy.
User feedback on usefulness and suggestions for functionality was
requested.
An example on the propagation of the announcement of the meetings' prefix
on the Internet was presented by Daniel Karrenberg, giving an impression
of what can already be done today with the alpha version of RIS. It was
stressed that the tool provides an integrated view eliminating the need
to consult multiple looking-glasses.
* project plans were subsequently summarised:
- 2 more RRC's (Remote Route Collectors) in Europe
- solve scalability problems of the BGP listener
- answer open questions on usability
- examine observed effects closely
Y. General I/O with Other WGs
Besides progress report on the database reimplementation and corresponding
issues, which will be presented at the Database WG session, no other I/O
happened with other WGs.
Z. Any Other Business
No other issues turned up and thus no other business was discussed.
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
- closed -
36.R1 on RIPE NCC
During the transition phase to the RPSL software
- verify with RADB on their test suites for testing RPSL implementations
- coordinate with RADB on consistent mirroring of databases (NRTM)
- coordinate with RADB on consistent whois interface of databases
including irrd
Marek Bukowy, Joachim Schmitz, July 2000
-----
you are here: RIPE -> RIPE Working Groups -> Routing
