Network Working Group B. Fenner Internet-Draft AT&T Labs - Research Expires: April 26, 2006 A. Zinin Alcatel October 23, 2005 Internet Routing Protocol Standardization Criteria draft-fenner-zinin-rtg-standard-reqts-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 26, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document provides guidance for the advancement of the protocols produced within the IETF Routing Area. It places implementation and interoperability constraints on protocols earlier in the standards process than RFC 2026, based on RFC 2026's provision that the IESG may require implementation and/or operational experience prior to granting Proposed Standard status to a specification that materially affects the core Internet protocols or that specifies behavior that Fenner & Zinin Expires April 26, 2006 [Page 1] Internet-Draft Routing Standards Criteria October 2005 may have significant operational impact on the Internet. We also discuss the applicability of these rules to protocols and their extensions. Table of Contents 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Note on protocol extensions . . . . . . . . . . . . . . . 5 3.2. Variance procedure . . . . . . . . . . . . . . . . . . . . 6 3.3. Appeal processes . . . . . . . . . . . . . . . . . . . . . 6 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Requirements for Proposed Standard . . . . . . . . . . . . 6 4.2. Requirements for Draft Standard . . . . . . . . . . . . . 7 4.3. Requirements for Standard . . . . . . . . . . . . . . . . 7 4.4. Optional Protocol Analysis . . . . . . . . . . . . . . . . 8 5. Submitting . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Submitting for Proposed Standard . . . . . . . . . . . . . 10 5.2. Submitting for Draft Standard or Standard . . . . . . . . 11 6. Changes from RFC 1264 . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 13 A.1. Changes since -00 . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Fenner & Zinin Expires April 26, 2006 [Page 2] Internet-Draft Routing Standards Criteria October 2005 1. Problem Statement The three-stage IETF standardization process is described in BCP 9, RFC 2026 [RFC2026]. In brief, the three stages of Internet standardization are Proposed (which requires a well written, openly reviewed specification), Draft (which requires Proposed status, multiple implementations and some operational experience), and full Internet Standard (which requires Draft status and more extensive operational experience). Historically, increased requirements, originally documented in RFC 1264 [RFC1264], have been applied to protocols produced within the Routing Area. NOTE: There is also ongoing work in the NEWTRK Working Group [1] on an updated IETF Standards Track. At this time the document uses the current standards track specified in RFC 2026. It will be modified to reflect changes in the IETF standards track as needed. The purpose of this document is to provide more specific guidance for the advancement of the protocols produced within the IETF Routing Area, consistent with RFC 2026's guidance: The IESG may require implementation and/or operational experience prior to granting Proposed Standard status to a specification that materially affects the core Internet protocols or that specifies behavior that may have significant operational impact on the Internet. Different types of protocols and all levels of the standardization process are covered. 2. Motivation The reason for elevated requirements for routing-related technologies is in the greater cost of a mistake compared to other technologies used in the Internet, as well as in particular attention to the scaling characteristics. Unlike other Internet technologies that require cooperation of a limited set of devices (e.g., two stations in case of a transport protocol, or a group of devices on the same subnet in case of ARP), routing protocols and related technologies normally implement some version of a distributed algorithm involving a large number of nodes (routers) in the network. As an example, a single OSPF domain [RFC2328] may consist of a thousand routers, and the total number of Autonomous Systems participating in global Internet routing via BGP [I-D.ietf-idr-bgp4] is currently around 20,000 [Huston]. Routing protocols are complex, widely distributed, real-time Fenner & Zinin Expires April 26, 2006 [Page 3] Internet-Draft Routing Standards Criteria October 2005 algorithms. They are difficult to implement and to test. Even though a protocol may work in one environment with one implementation, that does not ensure that it will work in a different environment with multiple vendors. A routing protocol may work well within a range of topologies and number of networks and routers, but may fail when an unforeseen limit is reached. The result is that even with considerable operational experience, it is hard to guarantee that the protocol is mature enough for widespread deployment. Because of the distributed nature of routing, the effects of a problem (resulting from, e.g., underspecification or ambiguities in protocol documents leading to interpretation differences in implementations) may easily propagate through the network, and result in service degradation or complete loss of connectivity. Scalability-related issues may have a similar effect -- a solution with poor scaling characteristics may behave well in small deployments, but collapse as the network grows further. The goals intended to be achieved by elevating standardization requirements for routing-related technologies can be summarized as follows: 1. Ensure that the documentation is adequate for multiple interoperable implementations of the technology to be developed independently without the need to consult the original authors or reverse-engineer an existing implementation. 2. Ensure that first-order problems in the technology have been discovered and fixed, its basic scaling properties, limitations, dynamics, and security aspects have been analysed before it is put on the Internet standards track and gets widely deployed. 3. Ensure that a technology becomes a full Internet Standard only if it has been independently implemented by multiple parties, has received sufficient operational experience, and has shown reasonable characteristics (e.g., scaling, convergence) in the environments it has been already deployed and will be deployed in the foreseeable future. 4. Ensure that it's possible to monitor (and optionally configure) the system using an open, standard interface. 3. Applicability The IETF Routing Area does not work exclusively on the routing protocols. Its work scope includes encapsulation and forwarding Fenner & Zinin Expires April 26, 2006 [Page 4] Internet-Draft Routing Standards Criteria October 2005 behavior (e.g., MPLS or multicast), MPLS label propagation and signalling protocols (e.g. LDP, and RSVP-TE), first-hop redundancy protocols (VRRP), router-internal protocols like FORCES, as well as extensions to all of these. Not all requirements defined in this document apply to every specification produced in the IETF Routing Area. All Routing Area submissions: In addition to the requirements described in the Internet Standards Process [RFC2026], a requirement that applies to all documents submitted to the IESG for Internet Standards track publication within the Routing Area is that a protocol or an extension to it SHOULD NOT be put on the Standards Track if no implementation exists for it. If it is desirable to encourage implementation of a specification, publication as an Experimental RFC SHOULD be considered. Protocols subject to further requirement elevation: Elevated requirements described in Section 4 of this document are applicable to protocols implementing a distributed algorithm whose functional domain spans more than one network segment (link) or otherwise affects the state of the distributed routing system or per-hop forwarding behavior, and extensions to such protocols. To give specific examples, routing protocols like OSPF [RFC2328], BGP [I-D.ietf-idr-bgp4], or PIM [I-D.ietf-pim-sm-v2-new] would fall within the category of algorithms spanning more than one segment, and hence elevated requirements would apply to them. The same is true for LDP [RFC3036] and RSVP-TE [RFC3209]. On the other hand, protocols like VRRP [RFC3768] or FORCES [I-D.ietf-forces-framework] run on a single segment or even inside the node, and hence would not fall into this category. 3.1. Note on protocol extensions As stated above, the procedures described in this document are equally applicable to both base protocol specifications and extensions to them. However, as explained in Section 5, the documentation required for protocol extensions is generally lighter than for the base protocol specifications. Note that even if a specification developed within the Routing area is an extensions to a protocol initially developed elsewhere (other IETF area or outside the IETF), principles laid out in this document still apply. For example, RSVP-TE [RFC3209], [RFC1195]. Also note, that all extensions to protocols that fall within the elevated requirements category are automatically subject to at least the same level of requirements as the base protocol, regardless of Fenner & Zinin Expires April 26, 2006 [Page 5] Internet-Draft Routing Standards Criteria October 2005 the envisioned application or where in the IETF the extension has been developed. 3.2. Variance procedure In consultation with the community, the IESG MAY decide to waive some or all of the requirements specified in this document. A situation where this might be needed is when factors not envisioned in this document arise and applying elevated requirements does more harm than good. If the IESG decides to waive some or all of the requirements, the IETF Last Call message SHALL include the explanation of reasoning for the variance. This will allow IETF participants to challenge the IESG decision. 3.3. Appeal processes All procedures described in this document are subject to the appeal process described in [RFC2026], including the variance procedure in that document's section 9. 4. Requirements 4.1. Requirements for Proposed Standard 1. Documents specifying the Protocol and its Usage. The specification for the routing protocol must be well written such that independent, interoperable implementations can be developed solely based on the specification. For example, it should be possible to develop an interoperable implementation without consulting the original developers of the routing protocol. 2. A Management Information Base (MIB) must be written for the protocol. The MIB does not need to submitted for Proposed Standard at the same time as the routing protocol, but must be at least an Internet Draft. 3. The security architecture of the protocol must be set forth explicitly. The security architecture must include mechanisms for authenticating protocol messages and may include other forms of protection. 4. Two or more independent interoperable implementations must exist. 5. There must be evidence that the major features of the protocol have been tested. Fenner & Zinin Expires April 26, 2006 [Page 6] Internet-Draft Routing Standards Criteria October 2005 6. No operational experience is required for the routing protocol at this stage in the standardization process. See Section 5.1 for submission guidelines for the required reports. 4.2. Requirements for Draft Standard 1. Revisions to the Protocol and Usage documents showing changes and clarifications made based on experience gained in the time between when the protocol was made a Proposed Standard and it being submitted for Draft Standard. The revised documents should include a section summarizing the changes made. 2. The Management Information Base (MIB) must be at the Proposed Standard level of standardization. 3. The security architecture of the protocol must be set forth explicitly. The security architecture must include mechanisms for authenticating protocol messages and may include other forms of protection. 4. Two or more interoperable implementations must exist. At least two must be written independently. 5. There must be evidence that all features of the protocol have been tested, running between at least two implementations. This must include that all of the security features have been demonstrated to operate, and that the mechanisms defined in the protocol actually provide the intended protection. 6. There must be significant operational experience. This must include running in a moderate number routers configured in a moderately complex topology, and must be part of the operational Internet. All significant features of the protocol must be exercised. In the case of an Interior Gateway Protocol (IGP), both interior and exterior routes must be carried (unless another mechanism is provided for the exterior routes). In the case of a Exterior Gateway Protocol (EGP), it must carry the full complement of exterior routes. See Section 5.2 for submission guidelines for the required reports. 4.3. Requirements for Standard 1. Revisions to the Protocol and Usage documents showing changes and clarifications made based on experience gained in the time between when the protocol was made a Draft Standard and it being submitted for Standard. The changes should be to clarify the Fenner & Zinin Expires April 26, 2006 [Page 7] Internet-Draft Routing Standards Criteria October 2005 protocol or provide guidance in its implementation. No significant changes can be made to the protocol at this stage. The revised documents should include a section summarizing the changes made. 2. The Management Information Base (MIB) must be submitted for Standard at the same time as the routing protocol. 3. The security architecture of the protocol must be set forth explicitly. The security architecture must include mechanisms for authenticating protocol messages and may include other forms of protection. 4. Three or more interoperable implementations must exist. At least two must be written independently. 5. There must be evidence that all features of the protocol have been tested, running between at least two independently written implementations. This must include that all of the security features have been demonstrated to operate, and that the mechanisms defined in the protocol actually provide the intended protection. 6. There must be significant operational experience. This must include running in a large number routers configured in a complex topology, and must be part of the operational Internet. The operational experience must include multi-vendor operation. All significant features of the protocol must be exercised. In the case of an Interior Gateway Protocol (IGP), both interior and exterior routes must be carried (unless another mechanism is provided for the exterior routes). In the case of a Exterior Gateway Protocol (EGP), it must carry the full complement of exterior routes. See Section 5.2 for submission guidelines for the required reports. 4.4. Optional Protocol Analysis When a protocol introduces previously unknown algorithms or techniques, the Area Directors may require that the working group produce a Protocol Analysis. This protocol analysis will be a separately-chartered working group work item, and may be a prerequisite for publication at Draft Standard or Standard. The Protocol Analysis must summarize the key features of the protocol and analyze how the protocol will perform and scale in the Internet. The intent of this requirement is to understand the boundary conditions of the routing protocol. The new routing protocol must be Fenner & Zinin Expires April 26, 2006 [Page 8] Internet-Draft Routing Standards Criteria October 2005 compared with the existing routing protocols (e.g., OSPF, BGP, etc.) as appropriate. The report should answer several questions: o What are the key features and algorithms of the protocol? o How much link bandwidth, router memory and router CPU cycles does the protocol consume under normal conditions? o For these metrics, how does the usage scale as the routing environment grows? This should include topologies at least an order of magnitude larger than the current environment. o What are the limits of the protocol for these metrics? (I.e., when will the routing protocol break?) o For what environments is the protocol well suited, and for what is it not suitable? When submitting for Standard, this report should simply be a revision of the report that was submitted for Draft Standard; it must describe the additional knowledge and understanding gained in the time between when the protocol was made a Draft standard and when it was submitted for Standard. 5. Submitting Before submitting a Technical Specification for publication, the WG chairs must ensure that the following steps have been completed: 1. The documents have undergone a Last Call in the Working Group, major technical issues have been resolved, and there's a clear support for publication. 2. The documents being submitted have been reviewed by the Routing Area Directorate and all identified issues have been discussed and, if necessary resolved. It is recommended that a review request to the Directorate is initiated during the Working Group Last Call. 3. The implementation and interoperability report has been submitted to the IETF secretariat, and is publicly available at the IETF web site. This report should include: * Implementation experience. * List of implementations including origin of code. Fenner & Zinin Expires April 26, 2006 [Page 9] Internet-Draft Routing Standards Criteria October 2005 * Interoperability report. * Test scenarios and test results showing that the major features of the protocols have been tested. 5.1. Submitting for Proposed Standard When submitting a specification or a bundle of documents to the ADs for publication as Proposed Standard, the WG chairs (or the document authors in case of an individual submission) send an E-mail message to the Routing ADs, with a copy (in the "Cc:" field) to the IETF secretariat (iesg-secretary@ietf.org) with the following information: 1. The name of the Internet-Draft(s) that contain the Technical Specification(s) being submitted, as well as the desired publication level (Proposed Standard in this case). Note that if more than one document is submitted, each document may have a different target status. These documents will be grouped in a bundle, and will be processed for the IETF Last Call and IESG review as a group. 2. If an Applicability Statement is included in the submission, the name of the I-D containing the AS, as well as the target publication status for it. Note that per [2026] the publication level of the AS cannot be higher than the publication level of the Technical Specification (item 1 above). 3. A brief description (technical summary) of the protocol. This information will be used during the IETF Last Call and the IESG review processes. The summary should include information such as: * What are the key features and algorithms of the protocol? * For what environments is the protocol well suited, and for what is it not suitable? 4. A pointer (e.g. URL) to the implementation and interoperability report previously submitted to the IETF secretariat. 5. A pointer to the corresponding MIB document with an explanation of how the MIB maturity requirement has been satisfied, or an explanation of why no MIB modifications are required to support functionality described in the Technical Specification. 6. Summary of the Routing Directorate review results, major issues that were identified, whether they were discussed and resolved. Fenner & Zinin Expires April 26, 2006 [Page 10] Internet-Draft Routing Standards Criteria October 2005 7. Any other reports or pointers to the documents otherwise required by the IETF process, such as the PROTO writeup described at . 5.2. Submitting for Draft Standard or Standard In addition to the requirements listed in Section 5.1, when submitting for Draft Standard or Standard, the submission must include an additional report: Description of operational experience. This must include topology, environment, time and duration, implementations involved, and overall results and conclusions gained from the operational experience. For a protocol, this report must be a separate document; for an extension to an existing protocol, it may be sent as part of the submission email. 6. Changes from RFC 1264 o Update to require two interoperable implementations for Proposed Standard. o Add explicit descriptions of what does and doesn't need to be treated under the extended rules. o Require an implementation for any standards-track document. o Add an escape mechanism (IETF Last Call) so that the community can comment on the decision of whether or not to apply these rules. o Clarify protocol submission guidelines. o Clarify how the process applies to protocol extensions. o Remove security description from reports; it's required in the specification already. 7. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. Fenner & Zinin Expires April 26, 2006 [Page 11] Internet-Draft Routing Standards Criteria October 2005 8. Security Considerations 9. Acknowledgments Bob Hinden wrote the original version of this document (RFC 1264 [RFC1264]) when he was Routing Area Director and the IETF was a very different place. Most of the original document remains. 10. References 10.1. Normative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 10.2. Informative References [I-D.ietf-forces-framework] Yang, L., "Forwarding and Control Element Separation (ForCES) Framework", draft-ietf-forces-framework-13 (work in progress), January 2004. [I-D.ietf-idr-bgp4] Rekhter, Y., "A Border Gateway Protocol 4 (BGP-4)", draft-ietf-idr-bgp4-26 (work in progress), October 2004. [I-D.ietf-pim-sm-v2-new] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode PIM-SM): Protocol Specification (Revised)", draft-ietf-pim-sm-v2-new-11 (work in progress), October 2004. [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. [RFC1264] Hinden, R., "Internet Engineering Task Force Internet Routing Protocol Standardization Criteria", RFC 1264, October 1991. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., Fenner & Zinin Expires April 26, 2006 [Page 12] Internet-Draft Routing Standards Criteria October 2005 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [RFC3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", RFC 3768, April 2004. URIs [1] Appendix A. Change Log A.1. Changes since -00 o Changed "SHALL NOT" to "SHOULD NOT" in the requirement of one implementation for all standards-track Routing Area Documents. o Added that the two implementations for PS must be independent o Moved the Protocol Analysis out of the required set of documents to Section 4.4. Fenner & Zinin Expires April 26, 2006 [Page 13] Internet-Draft Routing Standards Criteria October 2005 Authors' Addresses Bill Fenner AT&T Labs - Research 75 Willow Rd Menlo Park, CA 94025 USA Phone: +1 650 330-7893 Email: fenner@research.att.com Alex Zinin Alcatel 701 E Middlefield Rd Mountain View, California 94043 Email: zinin@psg.com Fenner & Zinin Expires April 26, 2006 [Page 14] Internet-Draft Routing Standards Criteria October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Fenner & Zinin Expires April 26, 2006 [Page 15]