Internet Engineering Task Force David Kessens
Draft ISI
Expires January 1998 July 1997
<draft-ietf-rps-transition-01.txt>
A strategy for the transition from RIPE-181 to RPSL
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents 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 learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This document describes a transition strategy for the Internet
routing registries from the RIPE181 [1] routing language to RPSL [2].
Introduction
Changing from one routing policy language to another is a complicated
matter due to the number of involved parties. First of all it is
important that the major routing databases will support the new
language, secondly it is very important that the user community and
tool developers are informed very well in advance over the changes to
avoid a loss in the database information quality and to give a chance
to the tools developers to adapt their tools to the new formats.
Therefore it seems best to take some time for a smooth transition.
The transition as proposed here is divided in a small number of
distinct and managable steps.
Kessens [Page 1]
Draft RPSL transition July 1997
We are currently in stage one and can soon start with stage two.
The third stage will be most painfull since it involves a switch to
the RPSL language at the same time and date. This wasn't strictly
necessary but avoids a lot of confusion and problems for registries
that still needed access to the old formats which becomes obviously
impossible after a registry is transitioned.
The databases will still accept RIPE181 updates during the whole
transition period and thereafter to ease the whole process for the
end-users.
First stage: testing and playing
The new RPSL extensions developed at ISI will be installed on a well
published test port at ISI for testing purposes. Everybody will start
working on converting their tools to RPSL.
Second stage: RIPE181 & RPSL databases run in parallel
All registrations will be made at the RIPE-181 databases and
registrations will be immediately mirrored in the RPSL database using
the real-time mirroring feature of the server. Clients and tools
should be able to run using either server and give similar output.
Merit/RA will add the RAWhoisd functionality to the new RIPE/ISI
code. RIPE and RA will install this software for testing purposes.
ISI will have a RPSL capable RAtoolset available.
Merit/RA will introduce the 'import|export:' lines in the production
version of their database. Those lines will give limited RPSL
functionality. This will give tool developers and users a chance to
use some of the functionality of RPSL in an early stage. These extra
attributes will not affect the other registries. Any other registry
might want to decide to support the 'import/export:' lines but it is
not required to. Tools are supposed to use the 'import|export:' lines
if present and the 'as-(in|out):' lines when not. Old tools will
automatically use the RIPE181 'as-(in|out):' lines and ignore the
compatibility.
ISI will give a tutorials on the new routing language at RIPE, NANOG
and APRICOT meetings. All registries will put a small but clear
banner in the acknowledgment messages of the poduction databases with
a pointer to a website with more information on RPSL and the
transition strategy. This banner will only appear in acknowledgement
messages which updated objects that are part of the routing registry
('route:', 'aut-num:', 'as-macro:', database. Some people might even
want to try the 'import|export:' lines in a production environment.
Kessens [Page 2]
Draft RPSL transition July 1997
Third stage: switch over to RPSL
The RIPE181 database is phased out. All registrations are done
directly in the RPSL database. Users may still send objects in the
RIPE-181 format in addition to the RPSL format. In this case,
dbupdate will automatically covert the object to RPSL format,
register it, and send a warning to the user about the conversion.
Eventually, RIPE-181 data will not be accepted and will be returned
back to the user as an error.
Security considerations
There are no security implications. The transition will solely deal
with a different representation of routing policies in the Internet
Registry databases. The update process and access protocol will stay
the same and will thus have the same properties as previous Internet
Registry databases had in the past.
Acknowledgments
I would like to thank Carol Orange, Chris Fletcher, everybody from
MCI, Bell Canada & Telstra who made invaluable reccomendations, John
Stuart, Gerald Winters, Joachim Schmitz, Curtis Villamizar, Tony
Bates, Cengiz Alaettinoglu, and everybody that contributed to the
work of the rps IETF working group in general, for their various
comments and suggestions.
References
[1] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg,
M. Terpstra, and J. Yu, "Representation of IP Routing Policies
in a Routing Registry", ripe-181, RIPE NCC, Amsterdam,
Netherlands, October 1994.
[2] C. Alaettinoglu et. al., draft-ietf-rps-rpsl-02.txt,
April 1997.
Author's Address:
David Kessens,
ISI
4676 Admiralty Way, Suite 1001
Marina del Rey, CA 90292-6695
USA
Kessens [Page 3]
Draft RPSL transition July 1997
davidk@ISI.EDU
Kessens [Page 4]
