summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1371.txt
blob: 8accab77d51fd962a58516a8e8dd0457ac453657 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L