Internet DRAFT - draft-fenner-zinin-rtg-standard-reqts
draft-fenner-zinin-rtg-standard-reqts
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
<http://rtg.ietf.org/area/procedures/proto_wgchair_writeup>.
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] <http://www.ietf.org/html.charters/newtrk.html>
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]
