Internet Engineering Task Force David Kessens Draft ISI Expires January 1998 July 1997 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]