INTERNET-DRAFT Carol Orange
Expires May 26, 1998 RIPE NCC
<draft-ietf-rps-transition-02.txt> David Kessens
ISI
21 November 1997
RIPE-181 to RPSL Transition Plan
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also distribute working doc-
uments as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
The standardization of RPSL (Routing Policy Specification Language) is
imminent, and there is a user community eager to make use of the power-
ful features it offers in the Routing Registry (IRR). Thus, a plan of
action is needed to assure a successful transition from the RIPE-181
language currently employed to describe routing policies in the IRR to
the more expressive RPSL. This document describes such a plan, which
the authors believe can be used to bring about a successful transition
in a timely fashion with a minimum of disruption to the IRR and its cur-
rent role in Internet routing. This document will be modified to
reflect the progress of the transition if appropriate.
1. Introduction
The Routing Registry (IRR) is a set of 5 (soon to be more) public
databases in which network operators can publish their routing policies
and their routing announcements such that other network operators can
make use of the data. In addition to making Internet topology visible,
the IRR is used by network operators to check on peering agreements,
determine optimal policies, and more recently, to configure their
routers.
Orange, Kessens Expires May 26, 1998 [Page 1]
Internet Draft RIPE-181 to RPSL Transition Plan November 21, 1997
Currently, the language used to describe peering policies is that
described in RIPE-181 [1]. The usefulness of the IRR has inspired the
development of a more powerful language, namely the Routing Policy Spec-
ification Language (RPSL). The primary benefits of RPSL in comparison to
RIPE-181 result from its increased expressiveness. More specifically,
network operators are able to express precisely the specifications they
use to configure their routers. This results in an easy mapping between
the router configuration language and the data contained in the IRR.
In this document, we describe a transition plan for moving the IRR from
RIPE-181 to RPSL. The transition plan is designed to meet the following
criteria:
Stability
The IRR is currently used both as a source of information, and as a
tool in performing daily operations such as router configuration.
Therefore, it must remain stable and operational throughout the
transition.
User Support
Whereas RPSL brings a wealth of improvements to the IRR, at no
point in time should current users face uncertainties about its
state and how to make the best use of it. If users become confused
about the proper mechanisms and language at some point in time,
they may turn their backs on the IRR, and stop using it altogether.
As the IRR is only as useful as the data maintained in it, this can
put the success of the current system at risk, rather than allow us
to benefit from RPSL.
Timeliness
Certainly with the specification of RPSL in its final stages, many
people are keen to make use of the new language features. The tran-
sition should therefore take place as quickly as feasible.
In the remainder of this document, we will describe a plan designed to
meet the criteria listed above. Before doing so, we will review briefly
the set of changes to take place.
2. Changes
Before discussing how to perform the transition from RIPE-181 to RPSL,
let's consider briefly the differences in these two languages.
The information maintained in the Routing Registry is stored in a number
of RIPE database objects [2]. Peering policies are described in aut-num
objects; routing announcements in route objects, and a group of AS's can
be defined in an as-macro object. The syntax used in these objects is
referred to as RIPE-181 [1].
Orange, Kessens Expires May 26, 1998 [Page 2]
Internet Draft RIPE-181 to RPSL Transition Plan November 21, 1997
The RPSL language is also expressed in a set of RIPE database objects.
Any expression that can be described in RIPE-181 can be described in
RPSL. Much of the RPSL language cannot, of course, be described in
RIPE-181. The key differences are:
More Expressive Syntax
The syntax to describe routing policies in aut-num objects is simi-
lar to that of RIPE-181, but significantly richer. This allows net-
work operators to register real world routing policies precisely
and concisely.
A RIPE-181 route object translated to RPSL is almost identical to
its original form. However, the RPSL route object syntax is far
more expressive. For example, one can describe the route type
(static, aggregate, etc.).
New as-set Object
The new as-set object in RPSL replaces the as-macro object in
RIPE-181. The syntax is slightly different.
New route-set Object
The route-set object in RPSL has no equivalent in RIPE-181. It
allows the grouping of address prefixes, and can be used, for exam-
ple to limit the set of address space for which routes will be
accepted from an AS.
A good introduction to RPSL can be found in [3], and the definitive lan-
guage description is in [4].
3. Transition Plan
In this section, we describe the RIPE-181 to RPSL transition in terms of
four stages. The four stages are distinguished by the user view of the
database, and in particular which specification language can be written
to the authoritative database, and in what language the data can be
read. Each of these stages is intended to be stable and to facilitate
some specific parts of the transition process.
3.1. Phase 1: Write RIPE-181, Read RIPE-181
This is the phase we are in at the time of this writing. During this
phase, the RIPE-181 IRR continues to be used.
Activities currently underway are:
Software Development
Software is currently being written to parse the RPSL language.
Orange, Kessens Expires May 26, 1998 [Page 3]
Internet Draft RIPE-181 to RPSL Transition Plan November 21, 1997
User Documentation
Both [2] and [3] provide some good information to new users of
RPSL.
Coordination
It is important that the current users be well informed of the
transition plan, which is of course the purpose of this document.
Transition Software
Software must be developed to support various mechanisms required
for the transition.
Additional work that must take place before we can proceed:
RPSL Extensions for RIPE Database software
Modifications required to support RPSL must be incorporated into
the RIPE database code and thoroughly tested.
Schedule
Work on the coding of RPSL has been going on since the start of 1997,
and is expected to be completed by the end of the year.
The code required to support the first transition step (convert RIPE-181
to RPSL for reading) has been done. See http://www.isi.edu/ra/rps/tran-
sition/ for more information.
The new RPSL code will be incorporated into the core RIPE database code
as soon as it is made available. This process, including testing, is
expected to be completed sometime during the first quarter of 1998.
3.2. Phase 2: Write RIPE-181, Read Both
During the second phase, users are able to continue working as usual,
both writing and reading RIPE-181. However, they can query an RPSL mir-
ror of the database, and view the objects they enter in the new specifi-
cation language. This gives users the opportunity to start modifying
their local tools to parse RPSL syntax rather than RIPE-181. It is
important to remember, however, that only a small subset of RPSL can be
studied in this phase, namely that which can already be expressed in
RIPE-181. This means that the as-set and route-set objects cannot yet be
worked with, nor can the more powerful policy specification mechanisms
to be used in aut-num objects.
In order to allow users to gain more experience in both reading and
writing policies in RPSL, we will allow aut-num objects to be written
and read from the RPSL data set as well as the RIPE-181 set. There are
a number of key points to be made about this setup:
Orange, Kessens Expires May 26, 1998 [Page 4]
Internet Draft RIPE-181 to RPSL Transition Plan November 21, 1997
+ Changes made to the RPSL data set will not be reflected in the
RIPE-181 data set.
+ Changes made to an aut-num object in the RPSL data set will gener-
ate a lock so that the object will not be overwritten the next time
the object is updated in the RIPE-181 data set. This is so one can
both operate normally, and experiment with the new language. The
lock will generate a warning when RIPE-181 changes are made, so one
can select to remove the RPSL changes.
+ The old RIPE-181 object which is converted to RPSL will reappear in
the RPSL mirror when the updated RPSL version is deleted by the
user.
+ RIPE-181 will continue to be used by most people as the authorita-
tive data set. Changes made to the RPSL data set will therefore not
be noted by the majority of users.
+ Modifications to objects which cannot be expressed in RIPE-181 are
unlikely to be correctly interpreted by tools written by others due
to the rarity of their appearance.
Development efforts that will take place during the second phase are in
the area of getting as many users as possible aware of the upcoming
changes and how to work with RPSL. This means improving the documenta-
tion available. Whereas, (as pointed out in Section 3.1) there is some
good documentation available, there is no extensive documentation on how
to exploit the expressive language features provided by RPSL.
Moreover, during this phase a significant training effort should be
underway. This includes but is not limited to:
+ the creation of an interactive web based training,
+ offering public workshops in conjunction with appropriate meetings
(RIPE, NANOG, APRICOT, IETF, etc.), and
+ the set up of a 1-2 day course program as proved successful in the
PRIDE project.
Schedule
It is expected that we can move into Phase 2, in the first quarter of
1998.
3.3. Phase 3: Write Both, Read RPSL
Orange, Kessens Expires May 26, 1998 [Page 5]
Internet Draft RIPE-181 to RPSL Transition Plan November 21, 1997
In the third phase, we move to RPSL as the key working language in the
IRR. Those who haven't had time to prepare to work exclusively with RPSL
can continue to submit objects in RIPE-181, but objects will automati-
cally be converted to RPSL and stored as such in the database.
Ideally, all registries participating in the IRR will transition to this
phase simultaneously. This will prevent confusion among users, and maxi-
mize the benefits for the users who make the transition.
Prerequisites
Because this phase forces users to move to RPSL (for all intents and
purposes), there are a number of conditions which must be met before
this step is taken. This is so we can meet the criteria for a successful
transition stipulated in the introduction.
+ There must be a solid body of user documentation available. Reg-
istries then have somewhere to point users when numerous questions
start coming about the new syntax and objects.
+ Training as described in the previous section should be well under-
way.
+ The setup described for Phase 3 should have already been running
for a number of months on a local test site of each registry. This
will allow the following to take place:
1. Tool development based on the full RPSL language.
2. Users can adjust to the new language.
3. Problems (which you probably do not ever want to have happen on
the live database) can be detected and corrected.
4. A system will be in place for the training of users.
+ Individual Registry Requirements. (For RIPE this means a go ahead
from the Routing WG, Database WG, and Local IR WGs. Other reg-
istries will have other restrictions.)
Schedule
The schedule should be determined by the users and if possible coordi-
nated among the participating registries.
Orange, Kessens Expires May 26, 1998 [Page 6]
Internet Draft RIPE-181 to RPSL Transition Plan November 21, 1997
3.4. Phase 4: Write RPSL, Read RPSL
In this phase, we simply remove the final support for RIPE-181. We
assume that the prerequisites for Phase 3 have been met.
Schedule
Again, the schedule will be determined by the users and hopefully coor-
dinated among the participating registries.
4. Summary
We have described a plan for the transition of the IRR from using the
current RIPE-181 language to using RPSL. The plan is designed to ensure
continuity and stability of the IRR, to help the user community adjust
to the transition, and finally to be performed in a timely fashion, with
hopes of completion during 1998. Given the scale and the distribution
of the IRR and the user community, which requires this transition to be
carefully coordinated, we consider this plan to be both optimistic and
realistic.
Acknowledgements
The ideas presented here, while consolidated by the authors, are the
result of a fruitful discussion with Cengiz Alaettinoglu, Chris
Fletcher, Daniel Karrenberg, Joachim Schmitz, and Wilfried Woeber.
Scott Huddle, Jake Kuhoun, Cleveland Mickles, John Stewart, Gerald Win-
ters and Jeff Young also contributed useful input. Any errors in design
or detail are, however, the responsibilities of the authors.
References
1. Tony Bates, Elise Gerich, Laurent Joncheray, Jean-Michel Jouanigot,
Daniel Karrenberg, Marten Terpstra, and Jessica Yu, "Representation
of IP Routing Policies in a Routing Registry," RFC1786 (October
1994).
2. A.M.R. Magee, "RIPE NCC Database Documentation," RIPE-157 (May
1997).
3. David Meyer, Joachim Schmitz, and Cengiz Alaettinoglu, "Application
of Routing Policy Specification Language (RPSL) on the Internet,"
<draft-ietf-rps-appl-rpsl-01.txt> (July 1997).
4. Cengiz Alaettinoglu, Tony Bates, Elise Gerich, Daniel Karrenberg,
David Meyer, Marten Terpstra, and Curtis Villamizer, "Routing Pol-
icy Specification Language (RPSL)," <draft-ietf-rps-
Orange, Kessens Expires May 26, 1998 [Page 7]
Internet Draft RIPE-181 to RPSL Transition Plan November 21, 1997
rpsl-04.txt,.ps> (November 1997).
Authors' Addresses
Carol Orange
RIPE NCC
Singel 258
1016 AB Amsterdam
The Netherlands
Email: orange@ripe.net
David Kessens
ISI
4676 Admiralty Way, Suite 1001
Marina del Rey, CA 90292-6695
USA
Email: davidk@isi.edu
Orange, Kessens Expires May 26, 1998 [Page 8]
