idnits 2.17.1 draft-ietf-rps-transition-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (21 November 1997) is 9653 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 98 looks like a reference -- Missing reference section? '2' on line 149 looks like a reference -- Missing reference section? '3' on line 149 looks like a reference -- Missing reference section? '4' on line 127 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Carol Orange 3 Expires May 26, 1998 RIPE NCC 4 David Kessens 5 ISI 6 21 November 1997 8 RIPE-181 to RPSL Transition Plan 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working docu- 13 ments of the Internet Engineering Task Force (IETF), its areas, and its 14 working groups. Note that other groups may also distribute working doc- 15 uments as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference material 20 or to cite them other than as "work in progress." 22 To view the entire list of current Internet-Drafts, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 The standardization of RPSL (Routing Policy Specification Language) is 31 imminent, and there is a user community eager to make use of the power- 32 ful features it offers in the Routing Registry (IRR). Thus, a plan of 33 action is needed to assure a successful transition from the RIPE-181 34 language currently employed to describe routing policies in the IRR to 35 the more expressive RPSL. This document describes such a plan, which 36 the authors believe can be used to bring about a successful transition 37 in a timely fashion with a minimum of disruption to the IRR and its cur- 38 rent role in Internet routing. This document will be modified to 39 reflect the progress of the transition if appropriate. 41 1. Introduction 43 The Routing Registry (IRR) is a set of 5 (soon to be more) public 44 databases in which network operators can publish their routing policies 45 and their routing announcements such that other network operators can 46 make use of the data. In addition to making Internet topology visible, 47 the IRR is used by network operators to check on peering agreements, 48 determine optimal policies, and more recently, to configure their 49 routers. 51 Currently, the language used to describe peering policies is that 52 described in RIPE-181 [1]. The usefulness of the IRR has inspired the 53 development of a more powerful language, namely the Routing Policy Spec- 54 ification Language (RPSL). The primary benefits of RPSL in comparison to 55 RIPE-181 result from its increased expressiveness. More specifically, 56 network operators are able to express precisely the specifications they 57 use to configure their routers. This results in an easy mapping between 58 the router configuration language and the data contained in the IRR. 60 In this document, we describe a transition plan for moving the IRR from 61 RIPE-181 to RPSL. The transition plan is designed to meet the following 62 criteria: 64 Stability 65 The IRR is currently used both as a source of information, and as a 66 tool in performing daily operations such as router configuration. 67 Therefore, it must remain stable and operational throughout the 68 transition. 70 User Support 71 Whereas RPSL brings a wealth of improvements to the IRR, at no 72 point in time should current users face uncertainties about its 73 state and how to make the best use of it. If users become confused 74 about the proper mechanisms and language at some point in time, 75 they may turn their backs on the IRR, and stop using it altogether. 76 As the IRR is only as useful as the data maintained in it, this can 77 put the success of the current system at risk, rather than allow us 78 to benefit from RPSL. 80 Timeliness 81 Certainly with the specification of RPSL in its final stages, many 82 people are keen to make use of the new language features. The tran- 83 sition should therefore take place as quickly as feasible. 85 In the remainder of this document, we will describe a plan designed to 86 meet the criteria listed above. Before doing so, we will review briefly 87 the set of changes to take place. 89 2. Changes 91 Before discussing how to perform the transition from RIPE-181 to RPSL, 92 let's consider briefly the differences in these two languages. 94 The information maintained in the Routing Registry is stored in a number 95 of RIPE database objects [2]. Peering policies are described in aut-num 96 objects; routing announcements in route objects, and a group of AS's can 97 be defined in an as-macro object. The syntax used in these objects is 98 referred to as RIPE-181 [1]. 100 The RPSL language is also expressed in a set of RIPE database objects. 101 Any expression that can be described in RIPE-181 can be described in 102 RPSL. Much of the RPSL language cannot, of course, be described in 103 RIPE-181. The key differences are: 105 More Expressive Syntax 106 The syntax to describe routing policies in aut-num objects is simi- 107 lar to that of RIPE-181, but significantly richer. This allows net- 108 work operators to register real world routing policies precisely 109 and concisely. 111 A RIPE-181 route object translated to RPSL is almost identical to 112 its original form. However, the RPSL route object syntax is far 113 more expressive. For example, one can describe the route type 114 (static, aggregate, etc.). 116 New as-set Object 117 The new as-set object in RPSL replaces the as-macro object in 118 RIPE-181. The syntax is slightly different. 120 New route-set Object 121 The route-set object in RPSL has no equivalent in RIPE-181. It 122 allows the grouping of address prefixes, and can be used, for exam- 123 ple to limit the set of address space for which routes will be 124 accepted from an AS. 126 A good introduction to RPSL can be found in [3], and the definitive lan- 127 guage description is in [4]. 129 3. Transition Plan 131 In this section, we describe the RIPE-181 to RPSL transition in terms of 132 four stages. The four stages are distinguished by the user view of the 133 database, and in particular which specification language can be written 134 to the authoritative database, and in what language the data can be 135 read. Each of these stages is intended to be stable and to facilitate 136 some specific parts of the transition process. 138 3.1. Phase 1: Write RIPE-181, Read RIPE-181 140 This is the phase we are in at the time of this writing. During this 141 phase, the RIPE-181 IRR continues to be used. 143 Activities currently underway are: 145 Software Development 146 Software is currently being written to parse the RPSL language. 148 User Documentation 149 Both [2] and [3] provide some good information to new users of 150 RPSL. 152 Coordination 153 It is important that the current users be well informed of the 154 transition plan, which is of course the purpose of this document. 156 Transition Software 157 Software must be developed to support various mechanisms required 158 for the transition. 160 Additional work that must take place before we can proceed: 162 RPSL Extensions for RIPE Database software 163 Modifications required to support RPSL must be incorporated into 164 the RIPE database code and thoroughly tested. 166 Schedule 168 Work on the coding of RPSL has been going on since the start of 1997, 169 and is expected to be completed by the end of the year. 171 The code required to support the first transition step (convert RIPE-181 172 to RPSL for reading) has been done. See http://www.isi.edu/ra/rps/tran- 173 sition/ for more information. 175 The new RPSL code will be incorporated into the core RIPE database code 176 as soon as it is made available. This process, including testing, is 177 expected to be completed sometime during the first quarter of 1998. 179 3.2. Phase 2: Write RIPE-181, Read Both 181 During the second phase, users are able to continue working as usual, 182 both writing and reading RIPE-181. However, they can query an RPSL mir- 183 ror of the database, and view the objects they enter in the new specifi- 184 cation language. This gives users the opportunity to start modifying 185 their local tools to parse RPSL syntax rather than RIPE-181. It is 186 important to remember, however, that only a small subset of RPSL can be 187 studied in this phase, namely that which can already be expressed in 188 RIPE-181. This means that the as-set and route-set objects cannot yet be 189 worked with, nor can the more powerful policy specification mechanisms 190 to be used in aut-num objects. 192 In order to allow users to gain more experience in both reading and 193 writing policies in RPSL, we will allow aut-num objects to be written 194 and read from the RPSL data set as well as the RIPE-181 set. There are 195 a number of key points to be made about this setup: 197 + Changes made to the RPSL data set will not be reflected in the 198 RIPE-181 data set. 200 + Changes made to an aut-num object in the RPSL data set will gener- 201 ate a lock so that the object will not be overwritten the next time 202 the object is updated in the RIPE-181 data set. This is so one can 203 both operate normally, and experiment with the new language. The 204 lock will generate a warning when RIPE-181 changes are made, so one 205 can select to remove the RPSL changes. 207 + The old RIPE-181 object which is converted to RPSL will reappear in 208 the RPSL mirror when the updated RPSL version is deleted by the 209 user. 211 + RIPE-181 will continue to be used by most people as the authorita- 212 tive data set. Changes made to the RPSL data set will therefore not 213 be noted by the majority of users. 215 + Modifications to objects which cannot be expressed in RIPE-181 are 216 unlikely to be correctly interpreted by tools written by others due 217 to the rarity of their appearance. 219 Development efforts that will take place during the second phase are in 220 the area of getting as many users as possible aware of the upcoming 221 changes and how to work with RPSL. This means improving the documenta- 222 tion available. Whereas, (as pointed out in Section 3.1) there is some 223 good documentation available, there is no extensive documentation on how 224 to exploit the expressive language features provided by RPSL. 226 Moreover, during this phase a significant training effort should be 227 underway. This includes but is not limited to: 229 + the creation of an interactive web based training, 231 + offering public workshops in conjunction with appropriate meetings 232 (RIPE, NANOG, APRICOT, IETF, etc.), and 234 + the set up of a 1-2 day course program as proved successful in the 235 PRIDE project. 237 Schedule 239 It is expected that we can move into Phase 2, in the first quarter of 240 1998. 242 3.3. Phase 3: Write Both, Read RPSL 243 In the third phase, we move to RPSL as the key working language in the 244 IRR. Those who haven't had time to prepare to work exclusively with RPSL 245 can continue to submit objects in RIPE-181, but objects will automati- 246 cally be converted to RPSL and stored as such in the database. 248 Ideally, all registries participating in the IRR will transition to this 249 phase simultaneously. This will prevent confusion among users, and maxi- 250 mize the benefits for the users who make the transition. 252 Prerequisites 254 Because this phase forces users to move to RPSL (for all intents and 255 purposes), there are a number of conditions which must be met before 256 this step is taken. This is so we can meet the criteria for a successful 257 transition stipulated in the introduction. 259 + There must be a solid body of user documentation available. Reg- 260 istries then have somewhere to point users when numerous questions 261 start coming about the new syntax and objects. 263 + Training as described in the previous section should be well under- 264 way. 266 + The setup described for Phase 3 should have already been running 267 for a number of months on a local test site of each registry. This 268 will allow the following to take place: 270 1. Tool development based on the full RPSL language. 272 2. Users can adjust to the new language. 274 3. Problems (which you probably do not ever want to have happen on 275 the live database) can be detected and corrected. 277 4. A system will be in place for the training of users. 279 + Individual Registry Requirements. (For RIPE this means a go ahead 280 from the Routing WG, Database WG, and Local IR WGs. Other reg- 281 istries will have other restrictions.) 283 Schedule 285 The schedule should be determined by the users and if possible coordi- 286 nated among the participating registries. 288 3.4. Phase 4: Write RPSL, Read RPSL 290 In this phase, we simply remove the final support for RIPE-181. We 291 assume that the prerequisites for Phase 3 have been met. 293 Schedule 295 Again, the schedule will be determined by the users and hopefully coor- 296 dinated among the participating registries. 298 4. Summary 300 We have described a plan for the transition of the IRR from using the 301 current RIPE-181 language to using RPSL. The plan is designed to ensure 302 continuity and stability of the IRR, to help the user community adjust 303 to the transition, and finally to be performed in a timely fashion, with 304 hopes of completion during 1998. Given the scale and the distribution 305 of the IRR and the user community, which requires this transition to be 306 carefully coordinated, we consider this plan to be both optimistic and 307 realistic. 309 Acknowledgements 311 The ideas presented here, while consolidated by the authors, are the 312 result of a fruitful discussion with Cengiz Alaettinoglu, Chris 313 Fletcher, Daniel Karrenberg, Joachim Schmitz, and Wilfried Woeber. 314 Scott Huddle, Jake Kuhoun, Cleveland Mickles, John Stewart, Gerald Win- 315 ters and Jeff Young also contributed useful input. Any errors in design 316 or detail are, however, the responsibilities of the authors. 318 References 320 1. Tony Bates, Elise Gerich, Laurent Joncheray, Jean-Michel Jouanigot, 321 Daniel Karrenberg, Marten Terpstra, and Jessica Yu, "Representation 322 of IP Routing Policies in a Routing Registry," RFC1786 (October 323 1994). 325 2. A.M.R. Magee, "RIPE NCC Database Documentation," RIPE-157 (May 326 1997). 328 3. David Meyer, Joachim Schmitz, and Cengiz Alaettinoglu, "Application 329 of Routing Policy Specification Language (RPSL) on the Internet," 330 (July 1997). 332 4. Cengiz Alaettinoglu, Tony Bates, Elise Gerich, Daniel Karrenberg, 333 David Meyer, Marten Terpstra, and Curtis Villamizer, "Routing Pol- 334 icy Specification Language (RPSL)," (November 1997). 337 Authors' Addresses 339 Carol Orange 340 RIPE NCC 341 Singel 258 342 1016 AB Amsterdam 343 The Netherlands 345 Email: orange@ripe.net 347 David Kessens 348 ISI 349 4676 Admiralty Way, Suite 1001 350 Marina del Rey, CA 90292-6695 351 USA 353 Email: davidk@isi.edu