diff options
Diffstat (limited to 'doc/rfc/rfc1371.txt')
| -rw-r--r-- | doc/rfc/rfc1371.txt | 507 |
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc1371.txt b/doc/rfc/rfc1371.txt new file mode 100644 index 0000000..8accab7 --- /dev/null +++ b/doc/rfc/rfc1371.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group P. Gross, Editor +Request for Comments: 1371 IETF/IESG Chair + October 1992 + + + Choosing a "Common IGP" for the IP Internet + (The IESG's Recommendation to the IAB) + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard. Distribution of this memo is + unlimited. + +Special Note + + This document was originally prepared as an Internet Engineering + Steering Group (IESG) recommendation to the Internet Architecture + Board (IAB) in mid-summer 1991, reaching the current version by the + date shown above. Although the document is now somewhat dated (e.g., + CIDR and RIP II are not mentioned), the IESG felt it was important to + publish this along with the recent OSPF Applicability Statement [11] + to help establish context and motivation. + +Abstract + + This memo presents motivation, rationale and other surrounding + background information leading to the IESG's recommendation to the + IAB for a single "common IGP" for the IP portions of the Internet. + + In this memo, the term "common IGP" is defined, the need for a common + IGP is explained, the relation of this issue to other ongoing + Internet Engineering Task Force (IETF) routing protocol development + is provided, and the relation of this issue to the goal for multi- + protocol integration in the Internet is explored. + + Finally, a specific IGP is recommended as the "common IGP" for IP + portions of the Internet -- the Open Shortest Path First (OSPF) + routing protocol. + + The goal of this recommendation is for all vendors of Internet IP + routers to make OSPF available as one of the IGP's provided with + their routers. + + + + + + + + +IESG [Page 1] + +RFC 1371 Choosing a "Common IGP" October 1992 + + +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 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 within a single + administrative domain (commonly referred to as an "Autonomous System" + (AS). + + By "common", we simply 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 have the capablity to interoperate within an AS through + use of a common IGP. + + Note: Routing between AS's 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 AS's using "an" EGP + is 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). These two protocols are both modern + "link state" routing protocols, based on the Dijkstra algorithm. + There has been substantial interaction and cooperation among the + engineers involved in each effort, and the protocols share some + similar features. + + However, there are a number of technical design differences. Most + noteably, 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) + + + +IESG [Page 2] + +RFC 1371 Choosing a "Common IGP" October 1992 + + + 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 AS's. + + Therefore, the Internet architecture supports the use and + standardization of multiple IGP routing protocols. For example, it + is 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. + + + +IESG [Page 3] + +RFC 1371 Choosing a "Common IGP" October 1992 + + + 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 AS's (in which IP is used but OSI CLNP is not used); + + 2. Pure CLNP AS's (in which CLNP is used but IP is not used); + + 3. Dual IP/CLNP ASs, 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 ASs 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 separates cases of (1) and + + + +IESG [Page 4] + +RFC 1371 Choosing a "Common IGP" October 1992 + + + (2), but it is pointed out here as a separate case for completeness. + +5. Commitment to both IP and CLNP + + The IAB/IETF are committed to a timely introduction of OSI into the + Internet. In recognition of this commitment, the IETF has an entire + area devoted to OSI integration. + + However, while this introduction is taking place, it is essential + that existing services based on IP be continued. Furthermore, IESG + also feels that even after more widespread introduction of CLNP, IP + and CLNP will continue to coexist in the Internet for quite some + time. This view is consistent with the IAB goal of a multi-protocol + Internet. + + Therefore, the IESG has a strong commitment to the continued support + for IP throughout the Internet. Maintenance of this IP support + requires selection of a common IGP suitable for support of IP, and + requires that this selection be based on operational experience. + +6. Some History + + In February 1990, the IESG recommended that the question of + designating a "common" IGP be postponed until more information was + available from each protocol. More than a year has now passed since + the IESG's recommendation. There have been significant advancements + in specification, implementation, and operational experience with + each protocol. It is now reasonable to re-open the consideration of + designating a "common IGP". + + At the March 1991 meeting of the IETF, the IETF Routing Area Director + presented a set of criteria for the advancement of routing protocols + through the Internet standards process [6]. More information + regarding the IAB Internet Standards process can be found in [1]. + + Also, at the March 1991 meeting of the IETF, the OSPF Working Group + requested that OSPF be considered for advancement to Draft Internet + Standard. The OSPF WG submitted four documents to the IETF to + support its request: + + o a revised protocol specification to update [4]; + + o an SNMP Management Information Base (MIB); + + o two technical reports giving a technical analysis and operational + experience with OSPF. These reports follow the format recommended + in [6]. + + + + +IESG [Page 5] + +RFC 1371 Choosing a "Common IGP" October 1992 + + + These four documents have now been published as [7, 8, 9, 10] + respectively. + + In summary for OSPF: + + o all features of OSPF have tested (although not all features have + been used in operation), + + o OSPF has been shown to operate well in several operational + networks containing between 10 and 30 routers, + + o 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: + + o There are several separate implementations of integrated + IS-IS under development, + + o Integrated IS-IS has worked well in several multi-area operational + networks, one containing between 20 and 30 routers, + + o 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 + + 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". + + + + + + + +IESG [Page 6] + +RFC 1371 Choosing a "Common IGP" October 1992 + + +7.2 Regarding Integrated Routing + + As mentioned above, the IESG is commited 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 + + + +IESG [Page 7] + +RFC 1371 Choosing a "Common IGP" October 1992 + + + 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. + + + + + + + + + + + + + + + + +IESG [Page 8] + +RFC 1371 Choosing a "Common IGP" October 1992 + + +9. Security Considerations + + Security issues are not discussed in this memo. + +10. Author's Address + + Phillip Gross, IESG Chair + Advanced Network & Services + 100 Clearbrook Road + Elmsford, NY + + Phone: 914-789-5300 + EMail: pgross@ans.net + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +IESG [Page 9] +
\ No newline at end of file |