Internet Engineering Task Force David Kessens Draft ISI Expires September 1997 March 1997 <draft-ietf-rps-transition-00.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 steps. Decisions for going from one stage to another need to be approved (if applicable) by the RIPE routing & database working Kessens [Page 1]
Draft RPSL transition March 1997 group. We give an estimate on the time that each stage will take but explicitly leave room for more/less time if desired/needed by the user community. The fourth stage will be most painfull since it involves a switch to new software at the same time and date and the tools that use the Internet Registry data are required to support RPSL syntax by then. However, the databases will still accept RIPE181 updates during the whole transition period and thereafter to ease the whole process for the end-users. The whole transition is focussed around the two Internet registries which have the largest number of routes and AS numbers registered. It is believed that this makes the process more easier to manage while it doesn't compromize the integrity of the routing registry system since the two biggest registries will have the tools to convert RIPE181 databases to RPSL format and make them available as such which will ensure that all routing registry data will be available in RPSL for those who need it. The other registries have the option to change to RPSL in stage 4 together with the RA and RIPE registry or at a later stage when they are better prepared. First stage (2 months): testing the new software The new RPSL extensions developed at ISI will be integrated with the then current RIPE database software and installed on a well published test port at the RIPE & RA locations for testing purposes. Merit/RA will introduce the rpsl-(in|out): 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 rpsl-(in|out): lines but it is not required to. Tools are supposed to use the rpsl-(in|out): 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 rpsl-(in|out): lines which is exactly what we want to ensure backwards compatibility. ISI will give a tutorial on the new routing language at one of the RIPE and NANOG meetings. Merit/RA & RIPE 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:, community:). Everybody will be invited to experiment on the new test database. Some people might even want to try the rpsl-(in|out): lines in a production environment. Kessens [Page 2]
Draft RPSL transition March 1997 Second stage (1 month): 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. Third stage (2 months): ISI will provide scripts for conversions from RIPE181 and RPSL fomats. RIPE & RA will run RPSL databases on test ports using the converted data. Near-real time mirroring is used to keep the RPSL & the RIPE181 database in sync. People can test tools during this period on both databases and compare the results. Fourth stage (2 months): ISI adds support to the new software that will auto translate RIPE181 (or rpsl-(in|out): lines) to RPSL format. RIPE & RA change to this software at the same day and time. The default update method is RIPE181, that means RIPE181 updates are translated to RPSL format and stored in RPSL format. People can start sending RPSL updates by using the 'RPSL' keyword in the subject line of their updates. Fifth stage & final stage: The default updating mechanism changes from RIPE181 to RPSL. People can still send RIPE181 updates by using the keyword 'RIPE181' in the subject line. The RIPE181 functionality will be removed when it's usage is not significant anymore. 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, Gerald Winters, Joachim Schmitz, Curtis Villamizar, Cengiz Alaettinoglu, and everybody that contributed to the work of the rps IETF working group in general, for Kessens [Page 3]
Draft RPSL transition March 1997 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-00.txt, March 1997. Author's Address: David Kessens, ISI 4676 Admiralty Way, Suite 1001 Marina del Rey, CA 90292-6695 USA davidk@ISI.EDU Kessens [Page 4]
