Internet Draft Cengiz Alaettinoglu Expires May 20, 1998 USC/ISI draft-ietf-rps-extending-00.txt David Meyer University of Oregon David Kessens USC/ISI November 20, 1997 Guidelines for Extending RPSL Status of this Memo This document is an Internet Draft, and can be found as draft-ietf-rps- extending-00.txt in any standard internet drafts repository. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. 1 Introduction This Internet Draft describes guidelines for extending the Routing Policy Specification Language (RPSL) [3, 4]. Our experiences with PRDB [2], RIPE-81 [6], and RIPE-181 [5] taught us that RPSL had to be extensible. These languages were not extensible and each transition to a new language turned out to be quite painful. As a result, extensibility was a primary design goal for RPSL. New routing protocols or new features to existing routing protocols can be easily handled using RPSL's dictionary class. New classes or new attributes to the existing classes can also be added. Objects specified in the policy language are stored in the Internet Routing Registry (IRR) [1, 7, 4]. Replacing the specification language often involves re-registering the existing objects in the new syntax. Software, Internet Draft Extending RPSL November 20, 1997 either public domain or in-house, needs to be updated to understand the new syntax. And the user community needs to be informed and trained of the changes. The initial RPSL dictionary object can be used to express most or all of the policies being used in the Internet today. However, extensions to RPSL will be necessary as new routing protocols or new features to existing routing protocols are introduced. This document provides guidelines for extending RPSL. These guidelines are designed with an eye toward maintaining backward compatibility with existing tools and databases. 2 Guidelines In this section, we list the available options for extending RPSL. We list them from the most preferred to the least preferred order. 2.1 Extensions by changing the dictionary class Before proceeding with any extensions, the dictionary class should be studied in depth. The dictionary class is the primary mechanism provided to extend RPSL. Dictionary objects define routing policy attributes, types, and routing protocols. Routing policy attributes may correspond to actual protocol attributes, such as the BGP path attributes (e.g. community, dpa, and AS-path), or they may correspond to router features (e.g. BGP route flap damping). We recommend updating the RPSL dictionary object to include appropriate rp-attribute and protocol definitions when new path attributes or router features are introduced. For example, in an earlier version of the RPSL document, it was only possible to specify that a router performs route flap damping on a peer, but it was not possible to specify the parameters of route flap damping. Later the parameters were added by changing the dictionary. When changing the dictionary, full compatibility should be maintained. For example, in our flap damping case, we made the parameter specification optional in case this level of detail was not desired by some ISPs. This also achieved compatibility. Any object registered without the parameters will continue to be valid. Any tool based on RPSL is expected to do a default action on routing policy attributes that they do not understand (e.g. issue a warning and otherwise ignore). Hence, old tools upon encountering a flap damping specification with parameters will ignore the parameters. Alaettinoglu et. al. Expires May 20, 1998 [Page 2]
Internet Draft Extending RPSL November 20, 1997 2.2 Extensions by adding new attributes to existing classes New attributes can easily be added to any class. To ensure full compatibility, new attributes should be optional and should not contradict the semantics of the objects they are attached to. Any tool that uses the IRR should be designed so that it ignores attributes that it doesn't understand. Most existing tools adhere to this design principle. We recommend adding new attributes to existing classes when a new aspect of a class is discovered. For example, RPSL route class extends its RIPE-181 predecessor by including several new attributes that enable aggregate and static route specification. 2.3 Extensions by adding new classes New classes can be added to RPSL to store new types of policy data. Providing full compatibility is straight forward as long as existing classes are still understood. Since a tool should only query the IRR for the classes that it understand, full compatibility should not be an issue in this case. New classes should be added with care. Before adding a new class, one should question if the information contained in the objects of the new class could have better belonged to some other class. For example, if the geographic location of a router needs to be stored in IRR, it may be tempting to add a new class called, say router-location class. However, the information better belongs to the inet-rtr class, perhaps in a new attribute called geographic-loc. RPSL added several new classes to RIPE-181. For example, we added the route-set class which assigns a name to a set of address prefixes. None of the classes in RIPE-181 were appropriate for storing this binding. 2.4 Extensions by changing the syntax of existing RPSL attributes If all of the methods described above fail to provide the desired extension or extensions, it may be necessary to change the syntax of RPSL. Any change in RPSL syntax must provide backwards compatibility, and should be considered only as a last resort since full compatibility may not be achievable. That is, old tools may break when they encounter the new syntax. However, we require that the old syntax to be still valid. One of the innocent changes we made to RIPE-181 was to add comments that started on a hash character (i.e. '#') and ended at the end of the line. These comments can be inserted anywhere. However, this innocent new feature is expected to break some of the existing tools since they are not written Alaettinoglu et. al. Expires May 20, 1998 [Page 3]
Internet Draft Extending RPSL November 20, 1997 to skip over comments. 3 Conclusions In this document, we have provided guidelines for extending RPSL. However, for extensions to be adapted, IRRs may need to deploy new software. The ISPs need to learn of the extensions. Hence, the extensions must be documented, most preferable as an IETF standards RFC. Registries may also require some proof of user interest in the extensions before proceeding. References [1] Internet Routing Registry. Procedures. http://www.ra.net/RADB.tools.docs/, http://www.ripe.net/db/doc.html. [2] NSFNET Policy Routing Database (PRDB). Maintained by MERIT Network Inc., Ann Arbor, Michigan. Contents available from nic.merit.edu.:/nsfnet/announced.networks/nets.tag.now by anonymous ftp. [3] C. Alaettinouglu, T. Bates, E. Gerich, D. Karrenberg, D. Meyer, M. Terpstra, and C. Villamizer. Routing Policy Specification Language (RPSL). Internet Draft draft-ietf-rps-rpsl-04, Network Information Center, November 1997. [4] C. Alaettinouglu, D. Meyer, and J. Schmitz. Application of Routing Policy Specification Language (RPSL) on the Internet. Internet Draft draft-ietf-rps-appl-rpsl-01, July 1997. Work in progress. [5] 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. Technical Report RFC-1786, Network Information Center, March 1995. [6] T. Bates, J-M. Jouanigot, D. Karrenberg, P. Lothberg, and M. Terpstra. Representation of IP Routing Policies in the RIPE Database. Technical Report ripe-81, RIPE, RIPE NCC, Amsterdam, Netherlands, February 1993. [7] A. M. R. Magee. RIPE NCC Database Documentation. Technical Report RIPE-157, RIPE, RIPE NCC, Amsterdam, Netherlands, May 1997. Alaettinoglu et. al. Expires May 20, 1998 [Page 4]
