Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/drafts/draft_ietf_q_t/draft-ietf-rps-transition-00.txt

Text File | 1997-03-25 | 8KB | 223 lines

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
   [e-mail]





























Kessens                                                         [Page 4]