INTERNET-DRAFT Carol Orange Expires May 26, 1998 RIPE NCC 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," (July 1997). 4. Cengiz Alaettinoglu, Tony Bates, Elise Gerich, Daniel Karrenberg, David Meyer, Marten Terpstra, and Curtis Villamizer, "Routing Pol- icy Specification Language (RPSL)," (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]