Internet Engineering Task Force Internet Routing Protocol Standardization Criteria
The checklist a new routing protocol had to pass to become a Proposed, Draft or full Internet Standard.
Hinden, R.M., "Internet Engineering Task Force Internet Routing Protocol Standardization Criteria", RFC 1264, DOI 10.17487/RFC1264, October 1991, <https://www.rfc-editor.org/info/rfc1264>.
@misc{rfc1264,
series = {Request for Comments},
number = 1264,
howpublished = {RFC 1264},
publisher = {RFC Editor},
doi = {10.17487/RFC1264},
url = {https://www.rfc-editor.org/info/rfc1264},
author = {R.M. Hinden},
title = {{Internet Engineering Task Force Internet Routing Protocol Standardization Criteria}},
pagetotal = 8,
year = 1991,
month = oct,
} RFC text
Contents
Network Working Group R. Hinden
Request for Comments: 1264 BBN
October 1991
Internet Engineering Task Force
Internet Routing Protocol Standardization Criteria
Status of this Memo
This informational RFC presents procedures for creating and
documenting Internet standards on routing protocols. These
procedures have been established by the Internet Activities Board
(IAB) in consultation with the Internet Engineering Steering Group
(IESG). Distribution of this memo is unlimited.
1.0 Introduction
The IAB and the IESG have evolved a three-stage Internet
standardization process. This process is explained in the "IAB
Official Protocol Standards", published as an RFC several times a
year (the current version is RFC 1250).
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). The IAB and
IESG are currently developing a more detailed explanation of the
process, which will be available as an RFC.
The purpose of this document is to provide more specific guidance for
the advancement of routing protocols. All levels of the
standardization process are covered.
There are currently two types of routing protocol in the Internet.
These are Interior Gateway Protocols (IGP) sometimes called Intra-
Domain Routing Protocols and Exterior Gateway Protocols (EGP)
sometimes called Inter-Domain Routing Protocols. This document uses
the terms IGP and EGP.
2.0 Motivation
The motivation for these requirements two-fold. The first is to
reduce the risk that there will be serious technical problems with a
routing protocol after it reaches Draft Standard. The second is to
insure that the new routing protocol will support the continued
growth of the Internet.
Routing protocols are complex, widely distributed, real-time
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.
The Internet is currently growing at an exponential rate. Routing
protocols and the management of internet addressing are key elements
in the successful operation the Internet. It is important that new
routing protocols be designed to support this rapid growth.
3.0 General Requirements
1) Documents specifying the Protocol and its Usage. This may be
one or more documents. The specifications 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. Routing protocols, like all other internet protocols,
need a MIB defined so they can be remotely managed.
3) A security architecture of the protocol must be defined. The
security architecture must include mechanisms for authenticating
routing messages and may include other forms of protection.
4) Generally, a number of 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 operational experience with the routing
protocol. The level of operational experience required is
dependent on which level of standardization is requested. 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.
7) Two reports must be submitted to the IESG via the Routing Area
Director. The first report must document how requirements 1)
through 6) of this document have been satisfied. It must
include:
- Implementation experience.
- Reference to the MIB for the protocol.
- Description of the authentication mechanisms in the protocol.
- List of implementations including origin of code.
- Test scenarios and test results showing that all features of the
protocols have been tested.
- Description of operational experience. This must include
topology, environment, time and duration, implementations
involved, and overall results and conclusions gained from the
operational experience.
The second report 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 compared
with the existing routing protocols (e.g., RIP, EGP, etc.) as
appropriate. The report should answer several questions:
- What are the key features and algorithms of the protocol?
- How much link bandwidth, router memory and router CPU cycles
does the protocol consume under normal conditions?
- 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.
- What are the limits of the protocol for these metrics? (I.e.,
when will the routing protocol break?)
- For what environments is the protocol well suited, and for what
is it not suitable?
The IESG will forward to the IAB its recommendation for advancement
of the new routing protocol based on its evaluation of protocol
specifications and these reports.
4.0 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 routing messages and may include other forms of
protection.
4) One or more implementations must exist.
5) There must be evidence that the major features of the protocol
have been tested.
6) No operational experience is required for the routing protocol
at this stage in the standardization process.
7) A report must be submitted to the IESG via the Routing Area
Director. The report must document the key features of the
protocol and describe how requirements 1) through 5) have been
satisfied. It must include:
- 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?
- Description of the authentication mechanisms in the protocol.
- Reference to the MIB for the protocol.
- Implementation experience.
- List of implementations including origin of code.
- Test scenarios and test results showing that the major features
of the protocols have been tested.
The IESG will forward to the IAB its recommendation for advancement
of the new routing protocol to Proposed Standard based on its
evaluation of protocol specifications and this reports.
5.0 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) Two or more interoperable implementations must exist. At least
two must be written independently.
4) 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.
5) 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.
6) Two reports must be submitted to the IESG via the Routing Area
Director. The first report must document how requirements 1)
through 5) of this document have been satisfied. It must include:
- Reference to the MIB for the protocol.
- Description of the authentication mechanisms in the protocol.
- List of implementations including origin of code.
- Implementation experience.
- Test scenarios and test results showing that all features of the
protocols have been tested.
- Description of operational experience. This must include
topology, environment, time and duration, implementations
involved, and overall results and conclusions gained from the
operational experience.
The second report 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 compared
with the existing routing protocols (e.g., RIP, EGP, etc.) as
appropriate. The report should answer several questions:
- What are the key features and algorithms of the protocol?
- How much link bandwidth, router memory and router CPU cycles
does the protocol consume under normal conditions?
- 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.
- What are the limits of the protocol for these metrics? (I.e.,
when will the routing protocol break?)
- For what environments is the protocol well suited, and for what
is it not suitable?
The IESG will forward to the IAB its recommendation for advancement
of the new routing protocol to Draft Standard based on its evaluation
of protocol specifications and these reports.
6.0 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 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) Three or more interoperable implementations must exist. At least
two must be written independently.
4) 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.
5) 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.
6) Two reports must be submitted to the IESG via the Routing Area
Director. The first report must document how requirements 1)
through 5) of this document have been satisfied. It must include:
- Reference to the MIB for the protocol.
- Description of the authentication mechanisms in the protocol.
- List of implementations including origin of code.
- Implementation experience.
- Test scenarios and test results showing that all features of the
protocols have been tested.
- Description of operational experience. This must include
topology, environment, time and duration, implementations
involved, and overall results and conclusions gained from the
operational experience.
The second report should be a revision to the report prepared when
the protocol 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.
The IESG will forward to the IAB its recommendation for advancement
of the new routing protocol to Standard based on its evaluation of
protocol specifications and these reports.
Security Considerations
Security issues are not discussed in this memo.
Author's Address
Robert M. Hinden
Bolt Beranek and Newman, Inc.
50 Moulton Street
Cambridge, MA 02138
Phone: (617) 873-3757
EMail: hinden@bbn.com
AI ELI5
On this page
§1Why Routing Protocols Get Extra Scrutiny
RFC 1264 gives more specific guidance for advancing routing protocols through the three-stage Internet standardization process run by the IAB with the IESG. The stages are Proposed (a well written, openly reviewed specification), Draft (Proposed status, multiple implementations and some operational experience) and full Internet Standard (Draft status and more extensive operational experience). All levels are covered.
The memo recognises two kinds of routing protocol: Interior Gateway Protocols (IGP, also called intra-domain routing protocols) and Exterior Gateway Protocols (EGP, also called inter-domain routing protocols). It uses the terms IGP and EGP.
Getting a routing rulebook approved works like earning belts in a sport. This memo says what you must show for each belt.
§2Motivation
The motivation is two-fold. The first aim is to reduce the risk of serious technical problems after a routing protocol reaches Draft Standard. The second is to ensure that the new protocol supports the continued growth of the Internet, which the memo describes as growing at an exponential rate.
The memo explains that a protocol may work in one environment with one implementation without working in a different environment with multiple vendors. It may also work well within a range of topologies and numbers of routers, then fail when an unforeseen limit is reached. Even with considerable operational experience, maturity is hard to guarantee.
A bridge that holds a few bicycles might still collapse under a truck. The checks try to find that out before everyone drives across.
§3General Requirements and Reports
The general requirements are seven items: specification documents good enough that independent, interoperable implementations can be built without consulting the original developers; a MIB so the protocol can be managed remotely; a security architecture that includes mechanisms for authenticating routing messages; several interoperable implementations, at least two written independently; evidence that all features have been tested between at least two implementations; operational experience; and two reports.
The first report documents how the requirements were met, including implementation experience, the MIB reference, the authentication mechanisms, a list of implementations, test results and a description of operational experience. The second report summarizes the key features and analyzes how the protocol will perform and scale, compared with existing protocols such as RIP and EGP where appropriate. It should say how much link bandwidth, router memory and router CPU the protocol uses, how that scales (including topologies at least an order of magnitude larger than the current environment), where the protocol will break, and which environments suit it.
The IESG sends its recommendation on advancement to the IAB based on the specifications and the reports.
The team has to show a clear rulebook, a way to check on the routers, a lock against cheaters, and proof it works on more than one kind of machine. It also has to write down when it would stop working.
§4Proposed Standard and Draft Standard
For Proposed Standard, the specification must be implementable by others, and the MIB must be at least an Internet Draft (it need not be submitted at the same time). The security architecture must be set out explicitly. One or more implementations must exist, and there must be evidence that the major features have been tested. No operational experience is required at this stage. A single report covers the key features, suitable environments, authentication, the MIB, implementation experience, implementations and test results.
For Draft Standard, the documents must be revised to reflect experience, with a section summarizing the changes, and the MIB must be at the Proposed Standard level. Two or more interoperable implementations must exist, at least two written independently, and all features (including the security features) must have been tested between at least two implementations. There must be significant operational experience in the operational Internet, in a moderate number of routers in a moderately complex topology, exercising all significant features. An IGP must carry both interior and exterior routes unless another mechanism is provided for exterior routes, and an EGP must carry the full complement of exterior routes. Both reports are required.
The first belt only needs a working example and a good plan. The second belt needs several builders, real use on the live network, and a report on how big it can grow.
| Stage | Implementations | MIB | Operational experience | Reports |
|---|---|---|---|---|
| Proposed | One or more | At least an Internet Draft | None required | One |
| Draft | Two or more, two independent | Proposed Standard level | Significant, moderate topology | Two |
| Standard | Three or more, two independent | Submitted for Standard with the protocol | Significant, large and multi-vendor | Two (second is a revision) |
§5Full Standard and Security Considerations
For full Standard, the documents are revised again, but only to clarify the protocol or guide implementers; no significant changes may be made at this stage. The MIB must be submitted for Standard at the same time as the protocol. Three or more interoperable implementations must exist, at least two written independently, and all features must be tested between at least two independently written implementations.
Operational experience must be significant: a large number of routers in a complex topology, part of the operational Internet, including multi-vendor operation. The second report is a revision of the Draft Standard report describing the additional knowledge gained since then.
The memo's Security Considerations section says only that security issues are not discussed in the memo. Security enters through the requirement for an authentication-capable security architecture in the protocols being judged.
The top belt needs even more builders, a big busy network, and no big last-minute changes to the rules.