RFC 1371

Choosing a "Common IGP" for the IP Internet ✨

(The IESG's Recommendation to the IAB) 🎀

• Group: Network Working Group 🌸
• RFC: 1371 💖
• Author: P. Gross, Editor, IETF/IESG Chair 👑
• Date: October 1992 📅
• Category/status: this memo provides information for the Internet community and does not specify an Internet standard 🧚
• Obsoletes/Updates: the title block doesn't list anything for either one 🤷‍♀️

---

Status of this Memo 💖

Okay so this memo just gives info to the Internet community 🧚. It does not specify an Internet standard, so no pressure lol. Distribution of this memo is unlimited 🌈.

Special Note 🎀

This doc started as an Internet Engineering Steering Group (IESG) recommendation to the Internet Architecture Board (IAB) in mid-summer 1991, and it reached its current version by the date up top 📅. Is it kinda dated now? Ngl, yes. CIDR and RIP II aren't mentioned 💀. But the IESG felt it was important to publish it alongside the recent OSPF Applicability Statement [11] so people get the context and motivation 🫶.

Abstract ✨

This memo is basically the motivation, the rationale, and all the background tea that led to the IESG's recommendation to the IAB for a single "common IGP" for the IP parts of the Internet 🍓.

Here we define the term "common IGP," explain why we need one, cover how this connects to other ongoing Internet Engineering Task Force (IETF) routing protocol work 🧠, and look at how it relates to the goal of multi-protocol integration in the Internet 🦋.

Finally, a specific IGP gets recommended as the "common IGP" for the IP parts of the Internet: the Open Shortest Path First (OSPF) routing protocol 👑.

The goal here is for all vendors of Internet IP routers to make OSPF available as one of the IGPs they provide with their routers 💅.

Table of Contents 📚

1. Background ....................................................  2
2. Multiple Internet Standard Routing Protocols Possible .........  3
3. A Common IGP ..................................................  3
4. Impact of Multi-protocol Topology and Integrated IP/CLNP Routing 3
5. Commitment to Both IP and CLNP ................................  5
6. Some History ..................................................  5
7. IESG Recommendations ..........................................  6
7.1 Regarding the Common IGP for the IP Internet .................  6
7.2 Regarding Integrated IP/CLNP Routing .........................  7
7.3 Limits of the Common IGP Recommendation ......................  7
8. References ....................................................  8
9. Security Considerations .......................................  9
10. Author's Address .............................................  9

---

1. Background 🌸

There is a seriously pressing need for a high-functionality, non-proprietary "common" Interior Gateway Protocol (IGP) for the TCP/IP protocol family 🔥. An IGP is the routing protocol used inside a single administrative domain, commonly called an "Autonomous System" (AS).

By "common," we just mean a protocol that is ubiquitously available from all router vendors (as in "in common") 💅. Users and network operators have expressed a strong need for routers from different vendors to be able to interoperate within an AS through use of a common IGP 🫶.

Note: Routing between ASes is handled by a different type of routing protocol, called an "Exterior Gateway Protocol" ("an EGP," of which the Border Gateway Protocol [2] and "The Exterior Gateway Protocol" [3] are examples.) The issues of routing between ASes using "an" EGP are not considered in this memo.

There are two IGPs in the Internet standards track capable of routing IP traffic: Open Shortest Path First (OSPF) [4] and Integrated IS-IS [5] (based on the OSI IS-IS). Both are modern "link state" routing protocols based on the Dijkstra algorithm 🤓. There has been substantial interaction and cooperation among the engineers on each effort, and the protocols share some similar features 🤝.

However, there are a number of technical design differences. Most notably, OSPF has been designed solely for support of the Internet Protocol (IP), while Integrated IS-IS has been designed to support both IP and the OSI Connectionless Network Layer Protocol (CLNP) simultaneously 👀.

2. Multiple Internet Standard Routing Protocols Possible 🦋

The Internet architecture makes a distinction between "Interior Gateway Protocols (IGPs)" and "Exterior Gateway Protocols (EGPs)" 💅. IGPs are routing protocols used within an Autonomous System (AS), and EGPs are routing protocols used between different ASes.

Therefore, the Internet architecture supports the use and standardization of multiple IGP routing protocols 🌈. For example, it's perfectly reasonable for one standard routing protocol to be used within one AS, while a second standard routing protocol is used within a second AS, at the same time that a non-standard proprietary routing protocol is used within a third AS 🙈.

The primary purpose for making standards is to allow interoperability. Setting a protocol standard in the Internet says, in effect, "if you wish to use this protocol, you should do it as specified in the standard so that you can interoperate with others who also wish to use this protocol." It is important to understand that simply specifying a standard does not, by itself, designate a requirement to use the standard. It is merely meant to allow interoperability among those who choose to follow the standard 🎀.

Therefore, it is reasonable for both OSPF and Integrated IS-IS to be progressed through the Internet Standards process as appropriate (based on the criteria specified in [6]). In addition, it is possible that other IGPs may be developed and standardized in the future ✨.

3. A Common IGP 💖

Although the Internet architecture allows for multiple standard IGP routing protocols, interoperability of router products from different vendors within a single AS would be greatly facilitated if a single "common" IGP were available from all router vendors. Designating a single common IGP would have the goal of enabling multi-vendor router interoperation with a modern, high-functionality routing protocol 🧚.

However, designating a common IGP does not mandate the use of that IGP, nor would it be meant to discourage the use of other IGPs in situations where there may be sound technical reasons to do so 🫶.

4. Impact of Multi-protocol Topology and Integrated IP/CLNP Routing 🌐

There are topology considerations which will affect the designation of a "common" Internet IGP 🗺️.

The Internet requires support for a wide variety of protocol suites. If we consider only IP and OSI CLNP, then the Internet is expected to contain:

1. Pure IP ASes (in which IP is used but OSI CLNP is not used);
2. Pure CLNP ASes (in which CLNP is used but IP is not used);
3. Dual IP/CLNP ASes, with a common topology (i.e., all links and routers in the AS support IP and CLNP, and a single common topology is used for both protocol suites);
4. Dual, overlapping IP/CLNP ASes with differing topologies (i.e., some links are dual, while some are IP-only and some are CLNP-only, resulting in different topologies for IP routing and CLNP routing).

For (1), (i.e., a pure IP environment) any IGP capable of routing IP traffic could be used (e.g., OSPF or Integrated IS-IS) 💅.

For (2), (i.e., a pure CLNP environment) any IGP capable of routing CLNP traffic could be used (e.g., OSI IS-IS or Integrated IS-IS) 🦋.

For (3), (i.e., routing environments in which both IP and CLNP are present in a common topology) there are two possibilities for managing routing:

1. Separate routing protocols could be used for each supported protocol suite. For example, OSPF may be used for calculating routes for IP traffic and OSI IS-IS may be used for calculating routes for OSI traffic. Or Integrated IS-IS could be used for calculating routes for IP traffic and OSI IS-IS could be used for calculating routes for CLNP traffic.

This approach of using separate routing protocols and management for each supported protocol family has come to be known as "Ships in the Night" because the two routing protocols share the hardware/software resources of the router without ever actually interacting on a protocol level 🌙.

2. "Integrated routing" could be used, in which a single routing protocol is used for both IP and CLNP. At this time, Integrated IS-IS is the only choice for "integrated routing" 👑.

For (4), (i.e., routing environments in which both IP and CLNP are present but in an overlapping different topology) separate routing protocols are required for the IP and CLNP environments (i.e., "Ships in the Night"). This is equivalent to two separate cases of (1) and (2), but it is pointed out here as a separate case for completeness 🧚.

6. Some History ✨

Okay so, back in February 1990 the IESG said "let's hold off on picking a common IGP until we know more about each protocol" 🧚. More than a year has passed since then, and both protocols have leveled up in specification, implementation, and operational experience. So it's totally reasonable to reopen the question of designating a "common IGP" 💅.

At the March 1991 IETF meeting, the IETF Routing Area Director presented a set of criteria for advancing routing protocols through the Internet standards process [6]. You can find more about the IAB Internet Standards process in [1] 📚.

Also at that March 1991 meeting, the OSPF Working Group asked for OSPF to be considered for advancement to Draft Internet Standard 🦋. They submitted four documents to back that up:

• a revised protocol specification to update [4];
• an SNMP Management Information Base (MIB);
• two technical reports giving a technical analysis and operational experience with OSPF. These reports follow the format recommended in [6].

These four documents have now been published as [7, 8, 9, 10] respectively. Iconic 🎀.

In summary for OSPF:

• all features of OSPF have tested (although not all features have been used in operation),
• OSPF has been shown to operate well in several operational networks containing between 10 and 30 routers,
• interoperation among routers from multiple vendors has been demonstrated at organized "bakeoffs".

In May 1991, the IAB approved the IETF/IESG recommendation to advance OSPF to Draft Internet Standard 👑.

Integrated IS-IS, as specified in [5], is currently a Proposed Internet Standard. In July 1991, the status of Integrated IS-IS is as follows:

• there are several separate implementations of integrated IS-IS under development,
• Integrated IS-IS has worked well in several multi-area operational networks, one containing between 20 and 30 routers,
• these recent operational results have not yet been fully documented. Documentation, showing satisfaction of the criteria given in [6] for advancing routing protocols, will be submitted to the IESG when Integrated IS-IS is submitted for Draft Internet Standard status 🌸.

---

7. IESG Recommendations 💖

7.1 Regarding the Common IGP for the IP Internet

Okay, the main event 🔥. Based on the available operational experience and the pressing need for a high functionality IGP for the IP protocol family, the IESG recommends that OSPF be designated as the common IGP for the IP portions of the Internet. To help ensure that this IGP is available to all users, the IESG recommends that the IETF Router Requirements Working Group specify OSPF as "MUST IMPLEMENT" in the document "Requirements for Internet IP Routers". The vibe is very much everyone gets OSPF 🧚.

7.2 Regarding Integrated Routing

As mentioned above, the IESG is committed to multiprotocol environments, and expects usage of OSI CLNP to increase in the Internet over time 🌈.

However, at this time, the IESG is not prepared to take a position regarding the preference of either "Ships in the Night" or Integrated routing for such mixed routing environments. At this time, the "Ships in the Night" approach is most widely used in the Internet. Integrated routing has the potential advantage of reducing resource utilization. However, additional operational experience is needed before any potential advantages can be fully evaluated 🤔.

Therefore, the IESG wishes to encourage implementation of Integrated IS-IS so that a reasonable position can be determined based on operational experience. All implementers of Integrated IS-IS are encouraged to coordinate their activity with the IETF IS-IS Working Group, which is actively collecting information on such experience 🦋.

7.3 Limits of the Recommendation

It is useful to recognize the limits of this recommendation. This recommendation does not take a position on any of the following issues:

1. What IGP (if any) users should run inside an AS. Users are free to run any IGP they wish inside an AS.
2. What IGP is technically superior, or has greater operational utility.
3. What IGP any vendor should recommend to its users for any specific environment.
4. What IGP should be used within a CLNP-only environment.

Again, this recommendation is meant to designate one modern high functionality IGP that should be implemented by all vendors of routers for the IP portion of the Internet. This will enable routers from vendors who follow this recommendation to interoperate within a single IP Autonomous System 🫶.

It is not our intent to discourage the use of other routing protocols in situations where there may be sound technical reasons to do so. Therefore, developers of Internet routers are free to implement, and network operators are free to use, other Internet standard routing protocols, or proprietary non-Internet-standard routing protocols, as they wish 💜.

---

8. References 📚

[1] Internet Activities Board, "The Internet Standards Process", RFC 1310, IAB, March 1992.

[2] Lougheed, K., and Y. Rekhter, "A Border Gateway Protocol 3 (BGP-3)", RFC 1267, cisco Systems, T.J. Watson Research Center, IBM Corp., October 1991.

[3] Mills, D., "Exterior Gateway Protocol Formal Specification", STD 18, RFC 904, UDEL, April 1984.

[4] Moy, J., "OSPF Specification", RFC 1131 (Superceded by [7]), Proteon, October 1989.

[5] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments", RFC 1195, DEC, December 1990.

[6] Hinden, R., "Criteria for Standardizing Internet Routing Protocols", RFC 1264, BBN, October 1991.

[7] Moy, J., "OSPF Version 2", RFC 1247, Proteon, July 1991.

[8] Baker, F., and R. Coltun, "OSPF Version 2 Management Information Base", RFC 1253, ACC, Computer Science Center, August 1991.

[9] Moy, J., "Experience with the OSPF Protocol", RFC 1246, Proteon, July 1991.

[10] Moy, J., "OSPF Protocol Analysis", RFC 1245, Proteon, July 1991.

[11] Internet Architecture Board, "Applicability Statement for OSPF", RFC 1370, IAB, October 1992.

---

9. Security Considerations 😱

Security issues are not discussed in this memo. 😭 Not one single word about security in here, bestie. Keep that front and center.

---

10. Author's Address 🎀

Phillip Gross, IESG Chair
Advanced Network & Services
100 Clearbrook Road
Elmsford, NY

Phone: 914-789-5300
EMail: pgross@ans.net