[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
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]