RFC 1264

RFC 1264 🎀 Internet Routing Protocol Standardization Criteria

Okay bestie, first the basics ✨ This is RFC 1264, written by R. Hinden at BBN. It was filed under the Network Working Group as a piece of the Internet Engineering Task Force, and it's dated October 1991. The category is Informational, and it doesn't list anything it obsoletes or updates, so it isn't replacing or changing any other RFC 💅

Status of this Memo 📜

So this informational RFC lays out the procedures for creating and documenting Internet standards on routing protocols 🌸 The Internet Activities Board (IAB) set these up in consultation with the Internet Engineering Steering Group (IESG). Distribution of this memo is unlimited 🌈

1.0 Introduction 🦋

Okay so the IAB and the IESG cooked up a three-stage Internet standardization process 👑 It's explained in the "IAB Official Protocol Standards" doc, which comes out as an RFC several times a year (the current version is RFC 1250).

The three stages are Proposed (needs a well written, openly reviewed specification), Draft (needs Proposed status, multiple implementations and some operational experience), and full Internet Standard (needs Draft status and more extensive operational experience) 🪜 The IAB and IESG are still cooking up a more detailed explanation of the process, which will also come out as an RFC 🫶

This doc gives more specific guidance for moving routing protocols up that ladder, and every level of the standardization process is covered 💜

Right now there are two types of routing protocol on the Internet 🌐 There 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, so get comfy with them 😌

2.0 Motivation 🌷

The reasons behind these requirements are two-fold. First, they're trying to lower the odds of serious technical problems popping up after a routing protocol hits Draft Standard 😬 Second, they want to make sure the new routing protocol keeps up with the Internet's continued growth 📈

Routing protocols are complex, widely distributed, real-time algorithms, and they're hard to implement AND test 🤯 Just because a protocol works in one environment with one implementation doesn't mean it'll work somewhere else with multiple vendors 🙈 A routing protocol might work great across a range of topologies and numbers of networks and routers, then faceplant the second it hits an unforeseen limit 💀 So even with lots of operational experience, it's hard to guarantee the protocol is mature enough for widespread deployment.

The Internet is growing at an exponential rate right now 🚀 Routing protocols and the management of internet addressing are key to the Internet running successfully. It's important that new routing protocols get designed to handle 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 so that independent, interoperable implementations can be developed solely based on the specification. Like, it SHOULD be possible to build an interoperable implementation without asking the original developers of the routing protocol for help 🫠
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 it 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 🏃‍♀️ How much you need depends on which level of standardization you're going for. All significant features of the protocol MUST be exercised. If it's an Interior Gateway Protocol (IGP), both interior and exterior routes MUST be carried (unless another mechanism is provided for the exterior routes). If it's an 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 it'll perform and scale on the Internet 📊 The goal here 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?

Then the IESG forwards its recommendation to the IAB for advancing the new routing protocol, based on its evaluation of the 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 so 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 be submitted for Proposed Standard at the same time as the routing protocol, but it 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 it MAY include other forms of protection 🛡️
4. One or more implementations MUST exist 🧑‍💻

5.0 Requirements for Draft Standard 💖

okay bestie, this is where the protocol levels up from Proposed Standard to Draft Standard, and the bar is HIGH 👑 here's everything it has to do:

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 is the big one, ngl 📊 It MUST summarize the key features of the protocol and analyze how the protocol will perform and scale in the Internet. The whole point 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. Main character energy, honestly. 💜

---

6.0 Requirements for Standard 👑

Okay so Standard is the final boss level 😭 Everything from Draft Standard still applies, plus a few extra hoops:

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. Yes, I'm gasping too. 😭

---

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