idnits 2.17.1 draft-ietf-rps-extending-00.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-25) 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. ** 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 an Abstract section. ** 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 70 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 103 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 14 has weird spacing: '...ment is an In...' == Line 15 has weird spacing: '....txt in any ...' == Line 17 has weird spacing: '...s, and its W...' == Line 22 has weird spacing: '...e. It is no...' == Line 23 has weird spacing: '...to cite them ...' == (65 more instances...) -- 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 (November 20, 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) == Unused Reference: '1' is defined on line 145, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 153, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 158, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 171, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Unexpected draft version: The latest known version of draft-ietf-rps-rpsl is -03, but you're referring to -04. == Outdated reference: A later version (-06) exists of draft-ietf-rps-appl-rpsl-01 ** Downref: Normative reference to an Informational draft: draft-ietf-rps-appl-rpsl (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 1786 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 15 errors (**), 0 flaws (~~), 12 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Cengiz Alaettinoglu 3 Expires May 20, 1998 USC/ISI 4 draft-ietf-rps-extending-00.txt David Meyer 5 University of Oregon 6 David Kessens 7 USC/ISI 8 November 20, 1997 10 Guidelines for Extending RPSL 12 Status of this Memo 14 This document is an Internet Draft, and can be found as draft-ietf-rps- 15 extending-00.txt in any standard internet drafts repository. Internet 16 Drafts are working documents of the Internet Engineering Task Force (IETF), 17 its Areas, and its Working Groups. Note that other groups may also 18 distribute working documents as Internet Drafts. 20 Internet Drafts are draft documents valid for a maximum of six months. 21 Internet Drafts may be updated, replaced, or obsoleted by other documents 22 at any time. It is not appropriate to use Internet Drafts as reference 23 material, or to cite them other than as a ``working draft'' or ``work in 24 progress.'' 26 Please check the I-D abstract listing contained in each Internet Draft 27 directory to learn the current status of this or any other Internet Draft. 29 1 Introduction 31 This Internet Draft describes guidelines for extending the Routing Policy 32 Specification Language (RPSL) [3, 4]. Our experiences with PRDB [2], 33 RIPE-81 [6], and RIPE-181 [5] taught us that RPSL had to be extensible. 34 These languages were not extensible and each transition to a new language 35 turned out to be quite painful. As a result, extensibility was a primary 36 design goal for RPSL. New routing protocols or new features to existing 37 routing protocols can be easily handled using RPSL's dictionary class. New 38 classes or new attributes to the existing classes can also be added. 40 Objects specified in the policy language are stored in the Internet Routing 41 Registry (IRR) [1, 7, 4]. Replacing the specification language often 42 involves re-registering the existing objects in the new syntax. Software, 43 either public domain or in-house, needs to be updated to understand the new 44 syntax. And the user community needs to be informed and trained of the 45 changes. 47 The initial RPSL dictionary object can be used to express most or all of the 48 policies being used in the Internet today. However, extensions to RPSL will 49 be necessary as new routing protocols or new features to existing routing 50 protocols are introduced. This document provides guidelines for extending 51 RPSL. These guidelines are designed with an eye toward maintaining backward 52 compatibility with existing tools and databases. 54 2 Guidelines 56 In this section, we list the available options for extending RPSL. We list 57 them from the most preferred to the least preferred order. 59 2.1 Extensions by changing the dictionary class 61 Before proceeding with any extensions, the dictionary class should be 62 studied in depth. The dictionary class is the primary mechanism provided 63 to extend RPSL. Dictionary objects define routing policy attributes, types, 64 and routing protocols. Routing policy attributes may correspond to actual 65 protocol attributes, such as the BGP path attributes (e.g. community, dpa, 66 and AS-path), or they may correspond to router features (e.g. BGP route flap 67 damping). 69 We recommend updating the RPSL dictionary object to include appropriate 70 rp-attribute and protocol definitions when new path attributes or router 71 features are introduced. For example, in an earlier version of the RPSL 72 document, it was only possible to specify that a router performs route 73 flap damping on a peer, but it was not possible to specify the parameters 74 of route flap damping. Later the parameters were added by changing the 75 dictionary. 77 When changing the dictionary, full compatibility should be maintained. For 78 example, in our flap damping case, we made the parameter specification 79 optional in case this level of detail was not desired by some ISPs. This 80 also achieved compatibility. Any object registered without the parameters 81 will continue to be valid. Any tool based on RPSL is expected to do 82 a default action on routing policy attributes that they do not understand 83 (e.g. issue a warning and otherwise ignore). Hence, old tools upon 84 encountering a flap damping specification with parameters will ignore the 85 parameters. 87 2.2 Extensions by adding new attributes to existing classes 89 New attributes can easily be added to any class. To ensure full 90 compatibility, new attributes should be optional and should not contradict 91 the semantics of the objects they are attached to. Any tool that uses 92 the IRR should be designed so that it ignores attributes that it doesn't 93 understand. Most existing tools adhere to this design principle. 95 We recommend adding new attributes to existing classes when a new aspect of 96 a class is discovered. For example, RPSL route class extends its RIPE-181 97 predecessor by including several new attributes that enable aggregate and 98 static route specification. 100 2.3 Extensions by adding new classes 102 New classes can be added to RPSL to store new types of policy data. 103 Providing full compatibility is straight forward as long as existing classes 104 are still understood. Since a tool should only query the IRR for the 105 classes that it understand, full compatibility should not be an issue in 106 this case. 108 New classes should be added with care. Before adding a new class, one 109 should question if the information contained in the objects of the new 110 class could have better belonged to some other class. For example, if 111 the geographic location of a router needs to be stored in IRR, it may be 112 tempting to add a new class called, say router-location class. However, the 113 information better belongs to the inet-rtr class, perhaps in a new attribute 114 called geographic-loc. 116 RPSL added several new classes to RIPE-181. For example, we added the 117 route-set class which assigns a name to a set of address prefixes. None of 118 the classes in RIPE-181 were appropriate for storing this binding. 120 2.4 Extensions by changing the syntax of existing RPSL attributes 122 If all of the methods described above fail to provide the desired extension 123 or extensions, it may be necessary to change the syntax of RPSL. Any 124 change in RPSL syntax must provide backwards compatibility, and should 125 be considered only as a last resort since full compatibility may not be 126 achievable. That is, old tools may break when they encounter the new 127 syntax. However, we require that the old syntax to be still valid. 129 One of the innocent changes we made to RIPE-181 was to add comments that 130 started on a hash character (i.e. '#') and ended at the end of the line. 131 These comments can be inserted anywhere. However, this innocent new feature 132 is expected to break some of the existing tools since they are not written 133 to skip over comments. 135 3 Conclusions 137 In this document, we have provided guidelines for extending RPSL. However, 138 for extensions to be adapted, IRRs may need to deploy new software. The 139 ISPs need to learn of the extensions. Hence, the extensions must be 140 documented, most preferable as an IETF standards RFC. Registries may also 141 require some proof of user interest in the extensions before proceeding. 143 References 145 [1] Internet Routing Registry. Procedures. 146 http://www.ra.net/RADB.tools.docs/, http://www.ripe.net/db/doc.html. 148 [2] NSFNET Policy Routing Database (PRDB). Maintained by MERIT 149 Network Inc., Ann Arbor, Michigan. Contents available from 150 nic.merit.edu.:/nsfnet/announced.networks/nets.tag.now by anonymous 151 ftp. 153 [3] C. Alaettinouglu, T. Bates, E. Gerich, D. Karrenberg, D. Meyer, 154 M. Terpstra, and C. Villamizer. Routing Policy Specification Language 155 (RPSL). Internet Draft draft-ietf-rps-rpsl-04, Network Information 156 Center, November 1997. 158 [4] C. Alaettinouglu, D. Meyer, and J. Schmitz. Application of Routing 159 Policy Specification Language (RPSL) on the Internet. Internet Draft 160 draft-ietf-rps-appl-rpsl-01, July 1997. Work in progress. 162 [5] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg, 163 M. Terpstra, and J. Yu. Representation of IP Routing Policies in 164 a Routing Registry. Technical Report RFC-1786, Network Information 165 Center, March 1995. 167 [6] T. Bates, J-M. Jouanigot, D. Karrenberg, P. Lothberg, and M. Terpstra. 168 Representation of IP Routing Policies in the RIPE Database. Technical 169 Report ripe-81, RIPE, RIPE NCC, Amsterdam, Netherlands, February 1993. 171 [7] A. M. R. Magee. RIPE NCC Database Documentation. Technical Report 172 RIPE-157, RIPE, RIPE NCC, Amsterdam, Netherlands, May 1997.