File: rfc1403.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (955 lines) | stat: -rw-r--r-- 36,173 bytes parent folder | download | duplicates (8)
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
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955






Network Working Group                                       K.  Varadhan
Request for Comments: 1403                                        OARnet
Obsoletes: 1364                                             January 1993


                          BGP OSPF Interaction

Status of this Memo

   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

Abstract

   This memo defines the various criteria to be used when designing an
   Autonomous System Border Routers (ASBR) that will run BGP with other
   ASBRs external to the AS and OSPF as its IGP.  This is a
   republication of RFC 1364 to correct some editorial problems.

Table of Contents

 1.  Introduction ....................................................  2
 2.  Route Exchange ..................................................  3
 2.1.  Exporting OSPF routes into BGP ................................  3
 2.2.  Importing BGP routes into OSPF ................................  4
 3.  BGP Identifier and OSPF router ID ...............................  5
 4.  Setting OSPF tags, BGP ORIGIN and AS_PATH attributes ............  6
 4.1.  Semantics of the characteristics bits .........................  8
 4.2.  Configuration parameters for setting the OSPF tag .............  9
 4.3.  Manually configured tags ...................................... 10
 4.4.  Automatically generated tags .................................. 10
 4.4.1.  Routes with incomplete path information, PathLength = 0 ..... 10
 4.4.2.  Routes with incomplete path information, PathLength = 1 ..... 11
 4.4.3.  Routes with incomplete path information, PathLength >= 1 .... 11
 4.4.4.  Routes with complete path information, PathLength = 0 ....... 12
 4.4.5.  Routes with complete path information, PathLength = 1 ....... 12
 4.4.6.  Routes with complete path information, PathLength >= 1 ...... 13
 4.5.  Miscellaneous tag settings .................................... 13
 4.6.  Summary of the TagType field setting .......................... 14
 5.  Setting OSPF Forwarding Address and BGP NEXT_HOP attribute ...... 14
 6.  Security Considerations ......................................... 15
 7.  Acknowledgements ................................................ 15
 8.  Bibliography .................................................... 16
 9.  Author's Address ................................................ 17




Varadhan                                                        [Page 1]

RFC 1403                  BGP OSPF Interaction              January 1993


1.  Introduction

   This document defines the various criteria to be used when designing
   an Autonomous System Border Routers (ASBR) that will run BGP
   [RFC1267] with other ASBRs external to the AS, and OSPF [RFC1247] as
   its IGP.

   This document defines how the following fields in OSPF and attributes
   in BGP are to be set when interfacing between BGP and OSPF at an
   ASBR:

           OSPF cost and type      vs. BGP INTER-AS METRIC
           OSPF tag                vs. BGP ORIGIN and AS_PATH
           OSPF Forwarding Address vs. BGP NEXT_HOP

   For a more general treatise on routing and route exchange problems,
   please refer to [ROUTE-LEAKING] and [NEXT-HOP] by Philip Almquist.

   This document uses the two terms "Autonomous System" and "Routing
   Domain".  The definitions for the two are below:

   The term Autonomous System is the same as is used in the BGP-3 RFC
   [RFC1267], given below:

        "The use of the term Autonomous System here stresses the fact
        that, even when multiple IGPs and metrics are used, the
        administration of an AS appears to other ASs to have a single
        coherent interior routing plan and presents a consistent picture
        of what networks are reachable through it.  From the standpoint
        of exterior routing, an AS can be viewed as monolithic:
        reachability to networks directly connected to the AS must be
        equivalent from all border gateways of the AS."

   The term Routing Domain was first used in [ROUTE-LEAKING] and is
   given below:

          "A Routing Domain is a collection of routers which coordinate
          their routing knowledge using a single (instance of) a routing
          protocol."

     This document follows the conventions embodied in the Host
     Requirements RFCs [RFC1122, RFC1123], when using the terms "MUST",
     "SHOULD", and "MAY" for the various requirements.








Varadhan                                                        [Page 2]

RFC 1403                  BGP OSPF Interaction              January 1993


2.  Route Exchange

   This section discusses the constraints that must be met to exchange
   routes between an external BGP session with a peer from another AS
   and internal OSPF routes.

   BGP does not carry subnet information in routing updates.  Therefore,
   when referring to a subnetted network in the OSPF routing domain, we
   consider the equivalent network route in the context of BGP.
   Multiple subnet routes for a subnetted network in OSPF are collapsed
   into one network route when exported into BGP.

   2.1.  Exporting OSPF routes into BGP

      1.   The administrator MUST be able to selectively export OSPF
           routes into BGP via an appropriate filter mechanism.

           This filter mechanism MUST support such control with the
           granularity of a single network.

           Additionally, the administrator MUST be able to filter based
           on the OSPF tag and the various sub-fields of the OSPF tag.
           The settings of the tag and the sub-fields are defined in
           section 4 in more detail.

           o    The default MUST be to export no routes from OSPF into
                BGP.  A single configuration parameter MUST permit all
                OSPF inter-area and intra-area routes to be exported
                into BGP.

                OSPF external routes of type 1 and type 2 MUST never be
                exported into BGP unless they are explicitly configured.

      2.   When configured to export a network, the ASBR MUST advertise
           a network route for a subnetted network, as long as at least
           one subnet in the subnetted network is reachable via OSPF.

      3.   The network administrator MUST be able to statically
           configure the BGP attribute INTER-AS METRIC to be used for
           any network route.

           o    By default, the INTER_AS METRIC MUST not be set.  This
                is because the INTER_AS METRIC is an optional attribute
                in BGP.

           Explanatory text: The OSPF cost and the BGP INTER-AS METRIC
           are of different widths.  The OSPF cost is a two level
           metric.  The BGP INTER-AS METRIC is only an optional non-



Varadhan                                                        [Page 3]

RFC 1403                  BGP OSPF Interaction              January 1993


           transitive attribute.  Hence, a more complex BGP INTER-AS
           METRIC-OSPF cost mapping scheme is not necessary.

      4.   When an ASBR is advertising an OSPF route to network Y to
           external BGP neighbours and learns that the route has become
           unreachable, the ASBR MUST immediately propagate this
           information to the external BGP neighbours.

      5.   An implementation of BGP and OSPF on an ASBR MUST have a
           mechanism to set up a minimum amount of time that must elapse
           between the learning of a new route via OSPF and subsequent
           advertisement of the route via BGP to the external
           neighbours.

           o    The default value for this setting MUST be 0, indicating
                that the route is to be advertised to the neighbour BGP
                peers instantly.

                Note that [RFC1267] mandates a mechanism to dampen the
                inbound advertisements from adjacent neighbours.

   2.2.  Importing BGP routes into OSPF

      1.   BGP implementations SHOULD allow an AS to control
           announcements of BGP-learned routes into OSPF.
           Implementations SHOULD support such control with the
           granularity of a single network.  Implementations SHOULD also
           support such control with the granularity of an autonomous
           system, where the autonomous system may be either the
           autonomous system that originated the route or the autonomous
           system that advertised the route to the local system
           (adjacent autonomous system).

           o    The default MUST be to export no routes from BGP into
                OSPF.  Administrators must configure every route they
                wish to import.

                A configuration parameter MAY allow an administrator to
                configure an ASBR to import all the BGP routes into the
                OSPF routing domain.

      2.   The administrator MUST be able to configure the OSPF cost and
           the OSPF metric type of every route imported into OSPF.

           o    The OSPF cost MUST default to 1; the OSPF metric type
                MUST default to type 2.





Varadhan                                                        [Page 4]

RFC 1403                  BGP OSPF Interaction              January 1993


      3.   Routes learned via BGP from peers within the same AS MUST not
           be imported into OSPF.

      4.   The ASBR MUST never generate a default route into the OSPF
           routing domain unless explicitly configured to do so.

           A possible criterion for generating default into an IGP is to
           allow the administrator to specify a set of (network route,
           AS_PATH, default route cost, default route type) tuples.  If
           the ASBR learns of the network route for an element of the
           set, with the corresponding AS_PATH, then it generates a
           default route into the OSPF routing domain, with cost
           "default route cost" and type, "default route type".  The
           lowest cost default route will then be injected into the OSPF
           routing domain.

           This is the recommended method for originating default routes
           in the OSPF routing domain.

3.  BGP Identifier and OSPF router ID

   The BGP identifier MUST be the same as the OSPF router id at all
   times that the router is up.

   This characteristic is required for two reasons.

     i    Synchronisation between OSPF and BGP

          Consider the scenario in which 3 ASBRs, RT1, RT2, and RT3,
          belong to the same autonomous system.


                                     +-----+
                                     | RT3 |
                                     +-----+
                                        |

                          Autonomous System running OSPF

                                 /               \
                             +-----+          +-----+
                             | RT1 |          | RT2 |
                             +-----+          +-----+


          Both RT1 and RT2 have routes to an external network X and
          import it into the OSPF routing domain.  RT3 is advertising
          the route to network X to other external BGP speakers.  RT3



Varadhan                                                        [Page 5]

RFC 1403                  BGP OSPF Interaction              January 1993


          must use the OSPF router ID to determine whether it is using
          RT1 or RT2 to forward packets to network X and hence build the
          correct AS_PATH to advertise to other external speakers.

          More precisely, RT3 must determine which ASBR it is using to
          reach network X by matching the OSPF router ID for its route
          to network X with the BGP Identifier of one of the ASBRs, and
          use the corresponding route for further advertisement to
          external BGP peers.

     ii   It will be convenient for the network administrator looking at
          an ASBR to correlate different BGP and OSPF routes based on
          the identifier.

4.  Setting OSPF tags, BGP ORIGIN and AS_PATH attributes

   The OSPF external route tag is a "32-bit field attached to each
   external route . . . It may be used to communicate information
   between AS boundary routers; the precise nature of such information
   is outside the scope of [the] specification." [RFC1247]

   OSPF imports information from various routing protocols at all its
   ASBRs.  In some instances, it is possible to use protocols other than
   EGP or BGP across autonomous systems.  It is important, in BGP, to
   differentiate between routes that are external to the OSPF routing
   domain but must be considered internal to the AS, as opposed to
   routes that are external to the AS.

   Routes that are internal to the AS and that may or may not be
   external to the OSPF routing domain will not come to the various BGP
   speakers from other BGP speakers within the same autonomous system
   via BGP.  Therefore, ASBRs running BGP must have knowledge of this
   class of routes so that they can advertise these routes to the
   various external AS without waiting for BGP updates from other BGP
   speakers within the same autonomous system about these routes.

   Additionally, in the specific instance of an AS intermixing routers
   running EGP and BGP as exterior gateway routing protocols and using
   OSPF as an IGP, then within the autonomous system, it may not be
   necessary to run BGP with every ASBR running EGP and not running BGP,
   if this information can be carried in the OSPF tag field.

   We use the external route tag field in OSPF to intelligently set the
   ORIGIN and AS_PATH attributes in BGP.  Both the ORIGIN and AS_PATH
   attributes are well-known, mandatory attributes in BGP.  The exact
   mechanism for setting the tags is defined below.

   The tag is broken up into sub-fields shown below.  The various sub-



Varadhan                                                        [Page 6]

RFC 1403                  BGP OSPF Interaction              January 1993


   fields specify the characteristics of the route imported into the
   OSPF routing domain.

   The high bit of the OSPF tag is known as the "Automatic" bit.  When
   this bit is set to 1, the following sub-fields apply:

      0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |a|c|p l|     ArbitraryTag      |       AutonomousSystem        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


     a    is 1 bit called the Automatic bit, indicating that the
          Completeness and PathLength bits have been generated
          automatically by a router.  The meaning of this characteristic
          and its setting are defined below.

     c    is 1 bit of Completeness information.  The meaning of this
          characteristic and its settings are defined below.

     pl   are 2 bits of PathLength information.  The meaning of this
          characteristic and its setting are defined below.

     ArbitraryTag
          is 12 bits of tag information, which defaults to 0 but can be
          configured to anything else.

     AutonomousSystem (or ``AS'')
          is 16 bits, indicating the AS number corresponding to the
          route, 0 if the route is to be considered as part of the local
          AS.

          local_AS
               The term `local_AS' refers to the AS number of the local
               OSPF routing domain.

          next_hop_AS
               `next_hop_AS' refers to the AS number of an external BGP
               peer.

     When the Automatic bit is set to 0, the following sub-fields apply:

      0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |a|                          LocalInfo                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Varadhan                                                        [Page 7]

RFC 1403                  BGP OSPF Interaction              January 1993


     a    is 1 bit called the Automatic bit, set to 0.

     LocalInfo
          is 31 bits of an arbitrary value, manually configured by the
          network administrator.

     The format of the tag for various values of the characteristics
     bits is defined below.

   4.1.  Semantics of the characteristics bits

      The Completeness and PathLength characteristics bits define the
      characteristic of the route imported into OSPF from other ASBRs in
      the autonomous system.  This setting is then used to set the
      ORIGIN and NEXT_HOP attributes when re-exporting these routes to
      an external BGP speaker.

      o    The Automatic characteristic bit is set when the Completeness
           and PathLength characteristics bits are automatically set by
           a border router.

           For backward compatibility, the Automatic bit must default to
           0 and the network administrator must have a mechanism to
           enable automatic tag generation.  Nothing must be inferred
           about the characteristics of the OSPF route from the tag
           bits, unless the tag has been automatically generated.

      o    The Completeness characteristic bit is set when the source of
           the incoming route is known precisely, for instance, from an
           IGP within the local autonomous system or EGP at one of the
           autonomous system's boundaries.  It refers to the status of
           the path information carried by the routing protocol.

      o    The PathLength characteristic sub-field is set depending on
           the length of the AS_PATH that the protocol could have
           carried when importing the route into the OSPF routing
           domain.  The length bits will indicate whether the AS_PATH
           attribute for the length is zero, one, or greater than one.

           Routes imported from an IGP will usually have an AS_PATH of
           length of 0, routes imported from an EGP will have an AS_PATH
           of length 1, BGP and routing protocols that support complete
           path information, either as AS_PATHs or routing domain paths,
           will indicate a path greater than 1.

           The OSPF tag is not wide enough to carry path information
           about routes that have an associated PathLength greater than
           one.  Path information about these routes will have to be



Varadhan                                                        [Page 8]

RFC 1403                  BGP OSPF Interaction              January 1993


           carried via BGP to other ASBRs within the same AS.  Such
           routes must not be exported from OSPF into BGP.


   4.2.  Configuration parameters for setting the OSPF tag

      o    There MUST be a mechanism to enable automatic generation of
           the tag characteristic bits.

      o    Configuration of an ASBR running OSPF MUST include the
           capability to associate a tag value, for the ArbitraryTag, or
           LocalInfo sub-field of the OSPF tag, with each instance of a
           routing protocol.

      o    Configuration of an ASBR running OSPF MUST include the
           capability to associate an AS number with each instance of a
           routing protocol.

           Associating an AS number with an instance of an IGP is
           equivalent to flagging those set of routes imported from the
           IGP to be external routes outside the local autonomous
           system.

           Specifically, when the IGP is RIP [RFC1058, RFC1388], it
           SHOULD be possible to associate a tag and/or an AS number
           with every interface running RIP on the ASBR.

























Varadhan                                                        [Page 9]

RFC 1403                  BGP OSPF Interaction              January 1993


   4.3.  Manually configured tags

      0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0|                          LocalInfo                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      This tag setting corresponds to the administrator manually setting
      the  tag bits.  Nothing MUST be inferred about the characteristics
      of the route corresponding to this tag setting.

      For backward compatibility with existing implementations  of  OSPF
      currently  deployed in the field, this MUST be the default setting
      for importing routes into the OSPF routing domain.  There MUST  be
      a  mechanism  to  enable  automatic  tag  generation  for imported
      routes.

      The OSPF tag to BGP attribute mappings for these routes MUST be

      Automatic=0, LocalInfo=Arbitrary_Value =>
                                 ORIGIN=<INCOMPLETE>, AS_PATH=<local_AS>

   4.4.  Automatically generated tags

      4.4.1.  Routes with incomplete path information, PathLength = 0.

       0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|0|     ArbitraryTag      |       AutonomousSystem        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         These are routes imported from routing protocols with
         incomplete path information and cannot or may not carry the
         neighbour AS or AS path as part of the routing information.

         The OSPF tag to BGP attribute mappings for these routes MUST be

         Automatic=1, Completeness=0, PathLength=00, AS=0 =>
                                        ORIGIN=<EGP>, AS_PATH=<local_AS>










Varadhan                                                       [Page 10]

RFC 1403                  BGP OSPF Interaction              January 1993


      4.4.2  Routes with incomplete path information, PathLength = 1.

       0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|0|1|     ArbitraryTag      |       AutonomousSystem        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         These are routes imported from routing protocols with
         incomplete path information.  The neighbour AS is carried in
         the routing information.

         The OSPF tag to BGP attribute mappings for these routes MUST be

         Automatic=1, Completeness=0, PathLength=01, AS=<next_hop_AS>
                        => ORIGIN=<EGP>, AS_PATH=<local_AS, next_hop_AS>

         This setting SHOULD be used for importing EGP routes into the
         OSPF routing domain.  This setting MAY also be used when
         importing BGP routes whose ORIGIN=<EGP> and
         AS_PATH=<next_hop_AS>;  if the BGP learned route has no other
         transitive attributes, then its propagation via BGP to ASBRs
         internal to the AS MAY be suppressed.

      4.4.3.  Routes with incomplete path information, PathLength >= 1.

       0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|1|0|     ArbitraryTag      |       AutonomousSystem        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         These are routes imported from routing protocols with truncated
         path information.

         The OSPF tag to BGP attribute mappings for these routes MUST be

         Automatic=1, Completeness=0, PathLength=10, AS=don't care

         These are imported by a border router, which is running BGP to
         a stub domain, and not running BGP to other ASBRs in the same
         AS.  This causes a truncation of the AS_PATH.  These routes
         MUST not be re-exported into BGP at another ASBR.








Varadhan                                                       [Page 11]

RFC 1403                  BGP OSPF Interaction              January 1993


      4.4.4.  Routes with complete path information, PathLength = 0.

       0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|1|0|0|     ArbitraryTag      |       AutonomousSystem        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         These are routes imported from routing protocols with either
         complete path information or are known to be complete through
         means other than that carried by the routing protocol.

         The OSPF tag to BGP attribute mappings for these routes MUST be

         Automatic=1, Completeness=1, PathLength=00, AS=0
                                     => ORIGIN=<EGP>, AS_PATH=<local_AS>

         This SHOULD be used for importing routes into OSPF from an IGP.

      4.4.5.  Routes with complete path information, PathLength = 1.

       0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|1|0|1|     ArbitraryTag      |       AutonomousSystem        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         These are routes imported from routing protocols with either
         complete path information, or are known to be complete through
         means other than that carried by the routing protocol.  The
         routing protocol also has additional information about the
         neighbour AS of the route.

         The OSPF tag to BGP attribute mappings for these routes MUST be

         Automatic=1, Completeness=1, PathLength=01, AS=next_hop_AS
                        => ORIGIN=<IGP>, AS_PATH=<local_AS, next_hop_AS>

         This setting SHOULD be used when the administrator explicitly
         associates an AS number with an instance of an IGP.  This
         setting MAY also be used when importing BGP routes whose
         ORIGIN=<IGP> and AS_PATH=<next_hop_AS>;  if the BGP learned
         route has no other transitive attributes, then its propagation
         via BGP to other ASBRs internal to the AS MAY be suppressed.







Varadhan                                                       [Page 12]

RFC 1403                  BGP OSPF Interaction              January 1993


      4.4.6.  Routes with complete path information, PathLength >= 1.

       0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|1|1|0|     ArbitraryTag      |       AutonomousSystem        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         These are routes imported from routing protocols with complete
         path information and carry the AS path information as part of
         the routing information.

         The OSPF tag MUST be set to

         Automatic=1, Completeness=1, PathLength=10, AS=don't care

         These routes MUST not be exported into BGP because these routes
         are already imported from BGP into the OSPF RD.  Hence, it is
         assumed that the BGP speaker will convey this information to
         other BGP speakers within the same AS via BGP.  An ASBR
         learning of such a route MUST wait for the BGP update from its
         internal neighbours before advertising this route to external
         BGP peers.

         Note that an implementation MAY import BGP routes with a path
         length of 1 and no other transitive attributes directly into
         OSPF and not send these routes via BGP to ASBRs within the same
         AS.  In this situation, it MUST use tag settings corresponding
         to 4.4.2, or 4.4.5.

   4.5.  Miscellaneous tag settings

      0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1|x|1|1|              Reserved  for  future  use               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The value of PathLength=11 is reserved during automatic tag
      generation.  Routers MUST not generate such a tag when importing
      routes into the OSPF routing domain.  ASBRs MUST ignore tags which
      indicate a PathLength=11.









Varadhan                                                       [Page 13]

RFC 1403                  BGP OSPF Interaction              January 1993


   4.6.  Summary of the tag sub-field setting

      The following table summarises the various combinations of
      automatic tag settings for the Completeness and PathLength sub-
      field of the OSPF tag and the default behaviour permitted for each
      setting.

                  Completeness := 0 | 1
                  PathLength := 00 | 01 | 10 | 11
                  ORIGIN := <INCOMPLETE> | <IGP> | <EGP>
                  AS_PATH := valid AS path settings as defined in BGP

PathLength ==> 00               01                   10            11
Completeness
  ||     +--------------------------------------------------------------
  vv     |
  =  NO  |    <EGP>            <EGP>             never export   reserved
         |  <local_AS>  <local_AS,next_hop_AS>
         |
  = YES  |    <IGP>            <IGP>             out of band    reserved
         |  <local_AS>  <local_AS,next_hop_AS>
         |

      The "out of band" in the table above implies that OSPF will not be
      able to carry everything that BGP needs in its routing
      information.  Therefore, some other means must be found to carry
      this information.  In BGP, this is done by running BGP to other
      ASBRs within the same AS.

5.  Setting OSPF Forwarding Address and BGP NEXT_HOP attribute

   Forwarding addresses are used to avoid extra hops between multiple
   routers that share a common network and that speak different routing
   protocols with each other.

   Both BGP and OSPF have equivalents of forwarding addresses.  In BGP,
   the NEXT_HOP attribute is a well-known, mandatory attribute.  OSPF
   has a Forwarding address field.  We will discuss how these are to be
   filled in various situations.












Varadhan                                                       [Page 14]

RFC 1403                  BGP OSPF Interaction              January 1993



   Consider the 4 router situation below:

   RT1 and RT2 are in one autonomous system, RT3 and RT4 are in another.
   RT1 and RT3 are talking BGP with each other.
   RT3 and RT4 are talking OSPF with each other.

            +-----+                 +-----+
            | RT1 |                 | RT2 |
            +-----+                 +-----+
               |                       |            common network
            ---+-----------------------+--------------------------
                 <BGP> |                       |
                    +-----+     <OSPF>      +-----+
                    | RT3 |                 | RT4 |
                    +-----+                 +-----+


     - Importing network X to OSPF:
          Consider an external network X, learnt via BGP from RT1.

          RT3 MUST always fill the OSPF Forwarding Address with the BGP
          NEXT_HOP attribute for the route to network X.

     - Exporting network Y to BGP:
          Consider a network Y, internal to the OSPF routing domain,
          RT3's route to network Y is via RT4, and network Y is to be
          exported via BGP to RT1.

          If network Y is not a subnetted network, RT3 MUST fill the
          NEXT_HOP attribute for network Y with the address of RT4.
          This is to avoid requiring packets to take an extra hop
          through RT3 when traversing the AS boundary.  This is similar
          to the concept of indirect neighbour support in EGP [RFC888,
          RFC827].

6.  Security Considerations

   Security issues are not discussed in this memo.

7.  Acknowledgements

   I would like to thank Yakov Rekhter, Jeff Honig, John Moy, Tony Li,
   Dennis Ferguson, and Phil Almquist for their help and suggestions in
   writing this document, without which I could not have written this
   document.  I would also like to thank them for giving me the
   opportunity to write this document, and putting up with my
   muddlements through various phases of this document.



Varadhan                                                       [Page 15]

RFC 1403                  BGP OSPF Interaction              January 1993


   I would also like to thank the countless number of people from the
   OSPF and BGP working groups who have offered numerous suggestions and
   comments on the different stages of this document.

   Thanks also to Bob Braden, who went through the document thoroughly,
   and came back with questions and comments, which were very useful.
   These suggestions have also been carried over into the next version
   of this document for dealing with BGP 4 and OSPF.

8.  Bibliography

   [RFC827]  Rosen, E., "Exterior Gateway Protocol (EGP)", RFC 827,
             BBN, October 1982.

   [RFC888]  Seamonson, L., and E. Rosen, "STUB Exterior Gateway
             Protocol", RFC 888, BBN, January 1984.

   [RFC1058]  Hedrick, C., "Routing Information Protocol", STD 34,
              RFC 1058, Rutgers University, June 1988.

   [RFC1388]  Malkin, G., "RIP Version 2 - Carrying Additional
              Information", RFC 1388, Xylogics, Inc., January 1993.

   [RFC1122]  Braden, R., Editor, "Requirements for Internet Hosts -
              Communication Layers, STD 3, RFC 1122,
              USC/Information Sciences Institute, October 1989.

   [RFC1123]  Braden, R., Editor, "Requirements for Internet Hosts -
              Application and Support", STD 3, RFC 1123,
              USC/Information Sciences Institute, October 1989.

   [RFC1267]  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.

   [RFC1268]  Rekhter, Y., and P. Gross, Editors, "Application of the
              Border Gateway Protocol in the Internet", RFC 1268,
              T.J. Watson Research Center, IBM Corp., ANS, October 1991.

   [RFC1247]  Moy, J., "The OSPF Specification - Version 2:", RFC 1247,
              Proteon, January 1991.

   [ROUTE-LEAKING]  Almquist, P., "Ruminations on Route Leaking",
                    Work in Progress.

   [NEXT-HOP]  Almquist, P., "Ruminations on the Next Hop",
               Work in Progress.




Varadhan                                                       [Page 16]

RFC 1403                  BGP OSPF Interaction              January 1993


9.  Author's  Address:

      Kannan Varadhan
      Internet Engineer, OARnet,
      1224, Kinnear Road,
      Columbus, OH 43212-1136.

      Phone: (614) 292-4137

      Email: kannan@oar.net









































Varadhan                                                       [Page 17]