summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1655.txt
blob: fc2577682ea1a6a18c78e5badda908b001813e91 (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
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
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
Network Working Group                                         Y. Rekhter
Request for Comments: 1655        T.J. Watson Research Center, IBM Corp.
Obsoletes: 1268                                                 P. Gross
Category: Standards Track                                            MCI
                                                                 Editors
                                                               July 1994


       Application of the Border Gateway Protocol in the Internet

Status of this Memo

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

Abstract

   This document, together with its companion document, "A Border
   Gateway Protocol 4 (BGP-4)", define an inter-autonomous system
   routing protocol for the Internet.  "A Border Gateway Protocol 4
   (BGP-4)" defines the BGP protocol specification, and this document
   describes the usage of the BGP in the Internet.

   Information about the progress of BGP can be monitored and/or
   reported on the BGP mailing list (bgp@ans.net).

Acknowledgements

   This document was originally published as RFC 1164 in June 1990,
   jointly authored by Jeffrey C. Honig (Cornell University), Dave Katz
   (MERIT), Matt Mathis (PSC), Yakov Rekhter (IBM), and Jessica Yu
   (MERIT).

   The following also made key contributions to RFC 1164 -- Guy Almes
   (ANS, then at Rice University), Kirk Lougheed (cisco Systems), Hans-
   Werner Braun (SDSC, then at MERIT), and Sue Hares (MERIT).

   We like to explicitly thank Bob Braden (ISI) for the review of the
   previous version of this document.

   This updated version of the document is the product of the IETF BGP
   Working Group with Phill Gross (MCI) and Yakov Rekhter (IBM) as
   editors.





Rekhter & Gross                                                 [Page 1]
^L
RFC 1655                   BGP-4 Application                   July 1994


   John Moy (Proteon) contributed Section 7 "Required set of supported
   routing policies".

   Scott Brim (Cornell University) contributed the basis for Section 8
   "Interaction with other exterior routing protocols".

   Most of the text in Section 9 was contributed by Gerry Meyer
   (Spider).

   Parts of the Introduction were taken almost verbatim from [3].

   We would like to acknowledge Dan Long (NEARNET) and Tony Li (cisco
   Systems) for their review and comments on the current version of the
   document.

1. Introduction

   This memo describes the use of the Border Gateway Protocol (BGP) [1]
   in the Internet environment. BGP is an inter-Autonomous System
   routing protocol. The network reachability information exchanged via
   BGP provides sufficient information to detect routing loops and
   enforce routing decisions based on performance preference and policy
   constraints as outlined in RFC 1104 [2]. In particular, BGP exchanges
   routing information containing full AS paths and enforces routing
   policies based on configuration information.

   As the Internet has evolved and grown over in recent years, it has
   become painfully evident that it is soon to face several serious
   scaling problems. These include:

       - Exhaustion of the class-B network address space. One
         fundamental cause of this problem is the lack of a network
         class of a size which is appropriate for mid-sized
         organization; class-C, with a maximum of 254 host addresses, is
         too small while class-B, which allows up to 65534 addresses, is
         too large to be densely populated.

       - Growth of routing tables in Internet routers are beyond the
         ability of current software (and people) to effectively manage.

       - Eventual exhaustion of the 32-bit IP address space.

   It has become clear that the first two of these problems are likely
   to become critical within the next one to three years.  Classless
   inter-domain routing (CIDR) attempts to deal with these problems by
   proposing a mechanism to slow the growth of the routing table and the
   need for allocating new IP network numbers. It does not attempt to
   solve the third problem, which is of a more long-term nature, but



Rekhter & Gross                                                 [Page 2]
^L
RFC 1655                   BGP-4 Application                   July 1994


   instead endeavors to ease enough of the short to mid-term
   difficulties to allow the Internet to continue to function
   efficiently while progress is made on a longer- term solution.

   BGP-4 is an extension of BGP-3 that provides support for routing
   information aggregation and reduction based on the Classless inter-
   domain routing architecture (CIDR) [3].  This memo describes the
   usage of BGP-4 in the Internet.

   All of the discussions in this paper are based on the assumption that
   the Internet is a collection of arbitrarily connected Autonomous
   Systems. That is, the Internet will be modeled as a general graph
   whose nodes are AS's and whose edges are connections between pairs of
   AS's.

   The classic definition of an Autonomous System is a set of routers
   under a single technical administration, using an interior gateway
   protocol and common metrics to route packets within the AS and using
   an exterior gateway protocol to route packets to other AS's. Since
   this classic definition was developed, it has become common for a
   single AS to use several interior gateway protocols and sometimes
   several sets of metrics within an AS. 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 AS's
   to have a single coherent interior routing plan and presents a
   consistent picture of which networks are reachable through it.

   AS's are assumed to be administered by a single administrative
   entity, at least for the purposes of representation of routing
   information to systems outside of the AS.

2. BGP Topological Model

   When we say that a connection exists between two AS's, we mean two
   things:

      Physical connection:  There is a shared network between the two
      AS's, and on this shared network each AS has at least one border
      gateway belonging to that AS. Thus the border gateway of each AS
      can forward packets to the border gateway of the other AS without
      resorting to Inter-AS or Intra-AS routing.

      BGP connection:  There is a BGP session between BGP speakers in
      each of the AS's, and this session communicates those routes that
      can be used for specific networks via the advertising AS.
      Throughout this document we place an additional restriction on the
      BGP speakers that form the BGP connection: they must themselves
      share the same network that their border gateways share. Thus, a



Rekhter & Gross                                                 [Page 3]
^L
RFC 1655                   BGP-4 Application                   July 1994


      BGP session between adjacent AS's requires no support from either
      Inter-AS or Intra-AS routing. Cases that do not conform to this
      restriction fall outside the scope of this document.

   Thus, at each connection, each AS has one or more BGP speakers and
   one or more border gateways, and these BGP speakers and border
   gateways are all located on a shared network. Note that BGP speakers
   do not need to be a border gateway, and vice versa. Paths announced
   by a BGP speaker of one AS on a given connection are taken to be
   feasible for each of the border gateways of the other AS on the same
   shared network, i.e. indirect neighbors are allowed.

   Much of the traffic carried within an AS either originates or
   terminates at that AS (i.e., either the source IP address or the
   destination IP address of the IP packet identifies a host on a
   network internal to that AS).  Traffic that fits this description is
   called "local traffic". Traffic that does not fit this description is
   called "transit traffic". A major goal of BGP usage is to control the
   flow of transit traffic.

   Based on how a particular AS deals with transit traffic, the AS may
   now be placed into one of the following categories:

      stub AS: an AS that has only a single connection to one other AS.
      Naturally, a stub AS only carries local traffic.

      multihomed AS: an AS that has connections to more than one other
      AS, but refuses to carry transit traffic.

      transit AS: an AS that has connections to more than one other AS,
      and is designed (under certain policy restrictions) to carry both
      transit and local traffic.

   Since a full AS path provides an efficient and straightforward way of
   suppressing routing loops and eliminates the "count-to-infinity"
   problem associated with some distance vector algorithms, BGP imposes
   no topological restrictions on the interconnection of AS's.

3. BGP in the Internet

3.1 Topology Considerations

   The overall Internet topology may be viewed as an arbitrary
   interconnection of transit, multihomed, and stub AS's.  In order to
   minimize the impact on the current Internet infrastructure, stub and
   multihomed AS's need not use BGP.  These AS's may run other protocols
   (e.g., EGP) to exchange reachability information with transit AS's.
   Transit AS's using BGP will tag this information as having been



Rekhter & Gross                                                 [Page 4]
^L
RFC 1655                   BGP-4 Application                   July 1994


   learned by some method other than BGP. The fact that BGP need not run
   on stub or multihomed AS's has no negative impact on the overall
   quality of inter-AS routing for traffic that either destined to or
   originated from the stub or multihomed AS's in question.

   However, it is recommended that BGP be used for stub and multihomed
   AS's as well. In these situations, BGP will provide an advantage in
   bandwidth and performance over some of the currently used protocols
   (such as EGP).  In addition, this would reduce the need for the use
   of default routes and in better choices of Inter-AS routes for
   multihomed AS's.

3.2 Global Nature of BGP

   At a global level, BGP is used to distribute routing information
   among multiple Autonomous Systems. The information flows can be
   represented as follows:


                    +-------+         +-------+
              BGP   |  BGP  |   BGP   |  BGP  |   BGP
           ---------+       +---------+       +---------
                    |  IGP  |         |  IGP  |
                    +-------+         +-------+

                    <-AS A-->         <--AS B->

   This diagram points out that, while BGP alone carries information
   between AS's, both BGP and an IGP may carry information across an AS.
   Ensuring consistency of routing information between BGP and an IGP
   within an AS is a significant issue and is discussed at length later
   in Appendix A.

3.3 BGP Neighbor Relationships

   The Internet is viewed as a set of arbitrarily connected AS's. BGP
   speakers in each AS communicate with each other to exchange network
   reachability information based on a set of policies established
   within each AS. Routers that communicate directly with each other via
   BGP are known as BGP neighbors. BGP neighbors can be located within
   the same AS or in different AS's. For the sake of discussion, BGP
   communications with neighbors in different AS's will be referred to
   as External BGP, and with neighbors in the same AS as Internal BGP.

   There can be as many BGP speakers as deemed necessary within an AS.
   Usually, if an AS has multiple connections to other AS's, multiple
   BGP speakers are needed. All BGP speakers representing the same AS
   must give a consistent image of the AS to the outside. This requires



Rekhter & Gross                                                 [Page 5]
^L
RFC 1655                   BGP-4 Application                   July 1994


   that the BGP speakers have consistent routing information among them.
   These gateways can communicate with each other via BGP or by other
   means. The policy constraints applied to all BGP speakers within an
   AS must be consistent. Techniques such as using a tagged IGP (see
   A.2.2) may be employed to detect possible inconsistencies.

   In the case of External BGP, the BGP neighbors must belong to
   different AS's, but share a common network. This common network
   should be used to carry the BGP messages between them. The use of BGP
   across an intervening AS invalidates the AS path information. An
   Autonomous System number must be used with BGP to specify which
   Autonomous System the BGP speaker belongs to.

4. Requirements for Route Aggregation

   A conformant BGP-4 implementation is required to have the ability to
   specify when an aggregated route may be generated out of partial
   routing information. For example, a BGP speaker at the border of an
   autonomous system (or group of autonomous systems) must be able to
   generate an aggregated route for a whole set of destination IP
   addresses (in BGP-4 terminology such a set is called the Network
   Layer Reachability Information or NLRI) over which it has
   administrative control (including those addresses it has delegated),
   even when not all of them are reachable at the same time.

   A conformant implementation may provide the capability to specify
   when an aggregated NLRI may be generated.

   A conformant implementation is required to have the ability to
   specify how NLRI may be de-aggregated.

   A conformant implementation is required to support the following
   options when dealing with overlapping routes:

       - Install both the less and the more specific routes

       - Install the more specific route only

       - Install the less specific route only

       - Install neither route

   By default a BGP speaker should aggregate NLRI representing subnets
   to the corresponding network.

   Injecting NLRI representing arbitrary subnets into BGP without
   aggregation to the corresponding network shall be controlled via
   configuration parameters.



Rekhter & Gross                                                 [Page 6]
^L
RFC 1655                   BGP-4 Application                   July 1994


   Certain routing policies may depend on the NLRI (e.g., "research"
   versus "commercial"). Therefore, a BGP speaker that performs route
   aggregation should be cognizant, if possible, of potential
   implications on routing policies when aggregating NLRI.

5. Policy Making with BGP

   BGP provides the capability for enforcing policies based on various
   routing preferences and constraints. Policies are not directly
   encoded in the protocol. Rather, policies are provided to BGP in the
   form of configuration information.

   BGP enforces policies by affecting the selection of paths from
   multiple alternatives and by controlling the redistribution of
   routing information.  Policies are determined by the AS
   administration.

   Routing policies are related to political, security, or economic
   considerations. For example, if an AS is unwilling to carry traffic
   to another AS, it can enforce a policy prohibiting this. The
   following are examples of routing policies that can be enforced with
   the use of BGP:

     1.  A multihomed AS can refuse to act as a transit AS for other
         AS's.  (It does so by only advertising routes to networks
         internal to the AS.)

     2.  A multihomed AS can become a transit AS for a restricted set of
         adjacent AS's, i.e., some, but not all, AS's can use the
         multihomed AS as a transit AS. (It does so by advertising its
         routing information to this set of AS's.)

     3.  An AS can favor or disfavor the use of certain AS's for
         carrying transit traffic from itself.

   A number of performance-related criteria can be controlled with the
   use of BGP:

     1.  An AS can minimize the number of transit AS's. (Shorter AS
         paths can be preferred over longer ones.)

     2.  The quality of transit AS's. If an AS determines that two or
         more AS paths can be used to reach a given destination, that AS
         can use a variety of means to decide which of the candidate AS
         paths it will use. The quality of an AS can be measured by such
         things as diameter, link speed, capacity, tendency to become
         congested, and quality of operation. Information about these
         qualities might be determined by means other than BGP.



Rekhter & Gross                                                 [Page 7]
^L
RFC 1655                   BGP-4 Application                   July 1994


     3.  Preference of internal routes over external routes.

   For consistency within an AS, equal cost paths, resulting from
   combinations of policies and/or normal route selection procedures,
   must be resolved in a consistent fashion.

   Fundamental to BGP is the rule that an AS advertises to its
   neighboring AS's only those routes that it uses. This rule reflects
   the "hop-by-hop" routing paradigm generally used by the current
   Internet.

6. Path Selection with BGP

   One of the major tasks of a BGP speaker is to evaluate different
   paths to a destination network from its border gateways at that
   network, select the best one, apply appropriate policy constraints,
   and then advertise it to all of its BGP neighbors. The key issue is
   how different paths are evaluated and compared.  In traditional
   distance vector protocols (e.g., RIP) there is only one metric (e.g.,
   hop count) associated with a path. As such, comparison of different
   paths is reduced to simply comparing two numbers. A complication in
   Inter-AS routing arises from the lack of a universally agreed-upon
   metric among AS's that can be used to evaluate external paths.
   Rather, each AS may have its own set of criteria for path evaluation.

   A BGP speaker builds a routing database consisting of the set of all
   feasible paths and the list of networks reachable through each path.
   For purposes of precise discussion, it's useful to consider the set
   of feasible paths for a given destination network. In most cases, we
   would expect to find only one feasible path. However, when this is
   not the case, all feasible paths should be maintained, and their
   maintenance speeds adaptation to the loss of the primary path. Only
   the primary path at any given time will ever be advertised.

   The path selection process can be formalized by defining a complete
   order over the set of all feasible paths to a given destination
   network. One way to define this complete order is to define a
   function that maps each full AS path to a non-negative integer that
   denotes the path's degree of preference. Path selection is then
   reduced to applying this function to all feasible paths and choosing
   the one with the highest degree of preference.

   In actual BGP implementations, the criteria for assigning degree of
   preferences to a path are specified as configuration information.

   The process of assigning a degree of preference to a path can be
   based on several sources of information:




Rekhter & Gross                                                 [Page 8]
^L
RFC 1655                   BGP-4 Application                   July 1994


     1.  Information explicitly present in the full AS path.

     2.  A combination of information that can be derived from the full
         AS path and information outside the scope of BGP (e.g., policy
         routing constraints provided as configuration information).

   Possible criteria for assigning a degree of preference to a path are:

       - AS count. Paths with a smaller AS count are generally better.

       - Policy considerations. BGP supports policy-based routing based
         on the controlled distribution of routing information.  A BGP
         speaker may be aware of some policy constraints (both within
         and outside of its own AS) and do appropriate path selection.
         Paths that do not comply with policy requirements are not
         considered further.

       - Presence or absence of a certain AS or AS's in the path. By
         means of information outside the scope of BGP, an AS may know
         some performance characteristics (e.g., bandwidth, MTU, intra-
         AS diameter) of certain AS's and may try to avoid or prefer
         them.

       - Path origin. A path learned entirely from BGP (i.e., whose
         endpoint is internal to the last AS on the path) is generally
         better than one for which part of the path was learned via EGP
         or some other means.

       - AS path subsets. An AS path that is a subset of a longer AS
         path to the same destination should be preferred over the
         longer path.  Any problem in the shorter path (such as an
         outage) will also be a problem in the longer path.

       - Link dynamics. Stable paths should be preferred over unstable
         ones. Note that this criterion must be used in a very careful
         way to avoid causing unnecessary route fluctuation. Generally,
         any criteria that depend on dynamic information might cause
         routing instability and should be treated very carefully.

7. Required set of supported routing policies

   Policies are provided to BGP in the form of configuration
   information.  This information is not directly encoded in the
   protocol. Therefore, BGP can provide support for very complex routing
   policies. However, it is not required that all BGP implementations
   support such policies.





Rekhter & Gross                                                 [Page 9]
^L
RFC 1655                   BGP-4 Application                   July 1994


   We are not attempting to standardize the routing policies that must
   be supported in every BGP implementation; we strongly encourage all
   implementors to support the following set of routing policies:

     1.  BGP implementations should allow an AS to control announcements
         of BGP-learned routes to adjacent AS's.  Implementations should
         also support such control with at least 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).
         Care must be taken when a BGP speaker selects a new route that
         can't be announced to a particular external peer, while the
         previously selected route was announced to that peer.
         Specifically, the local system must explicitly indicate to the
         peer that the previous route is now infeasible.

     2.  BGP implementations should allow an AS to prefer a particular
         path to a destination (when more than one path is available).
         At the minimum an implementation shall support this
         functionality by allowing to administratively assign a degree
         of preference to a route based solely on the IP address of the
         neighbor the route is received from. The allowed range of the
         assigned degree of preference shall be between 0 and 2^(31) -
         1.

     3.  BGP implementations should allow an AS to ignore routes with
         certain AS's in the AS_PATH path attribute.  Such function can
         be implemented by using the technique outlined in [2], and by
         assigning "infinity" as "weights" for such AS's. The route
         selection process must ignore routes that have "weight" equal
         to "infinity".

8. Interaction with other exterior routing protocols

   The guidelines suggested in this section are consistent with the
   guidelines presented in [3].

   An AS should advertise a minimal aggregate for its internal networks
   with respect to the amount of address space that it is actually
   using.  This can be used by administrators of non-BGP 4 AS's to
   determine how many routes to explode from a single aggregate.

   A route that carries the ATOMIC_AGGREGATE path attribute shall not be
   exported into either BGP-3 or EGP2, unless such an exportation can be
   accomplished without exploding the NLRI of the route.




Rekhter & Gross                                                [Page 10]
^L
RFC 1655                   BGP-4 Application                   July 1994


8.1 Exchanging information with EGP2

   This document suggests the following guidelines for exchanging
   routing information between BGP-4 and EGP2.

   To provide for graceful migration, a BGP speaker may participate in
   EGP2, as well as in BGP-4. Thus, a BGP speaker may receive IP
   reachability information by means of EGP2 as well as by means of
   BGP-4.  The information received by EGP2 can be injected into BGP-4
   with the ORIGIN path attribute set to 1.  Likewise,  the information
   received via BGP-4 can be injected into EGP2 as well. In the latter
   case, however, one needs to be aware of the potential information
   explosion when a given IP prefix received from BGP-4 denotes a set of
   consecutive A/B/C class networks.  Injection of BGP-4 received NLRI
   that denotes IP subnets requires the BGP speaker to inject the
   corresponding network into EGP2.  The local system shall provide
   mechanisms to control the exchange of reachability information
   between EGP2 and BGP-4.  Specifically, a conformant implementation is
   required to support all of the following options when injecting BGP-4
   received reachability information into EGP2:

       - inject default only (0.0.0.0); no export of any other NLRI

       - allow controlled deaggregation, but only of specific routes;
         allow export of non-aggregated NLRI

       - allow export of only non-aggregated NLRI

   The exchange of routing information via EGP2 between a BGP speaker
   participating in BGP-4 and a pure EGP2 speaker may occur  only at the
   domain (autonomous system) boundaries.

8.2 Exchanging information with BGP-3

   This document suggests the following guidelines for exchanging
   routing information between BGP-4 and BGP-3.

   To provide for graceful migration, a BGP speaker may participate in
   BGP-3, as well as in BGP-4. Thus, a BGP speaker may receive IP
   reachability information by means of BGP-3, as well as by means of
   BGP-4.

   A BGP speaker may inject the information received by BGP-4 into BGP-3
   as follows.

   If an AS_PATH attribute of a BGP-4 route carries AS_SET path
   segments, then the AS_PATH attribute of the BGP-3 route shall be
   constructed by treating the AS_SET segments as AS_SEQUENCE segments,



Rekhter & Gross                                                [Page 11]
^L
RFC 1655                   BGP-4 Application                   July 1994


   with the resulting AS_PATH being a single AS_SEQUENCE. While this
   procedure loses set/sequence information, it doesn't affect
   protection for routing loops suppression, but may affect policies, if
   the policies are based on the content or ordering of the AS_PATH
   attribute.

   While injecting BGP-4 derived NLRI into BGP-3, one needs to be aware
   of the potential information explosion when a given IP prefix denotes
   a set of consecutive A/B/C class networks. Injection of BGP-4 derived
   NLRI that denotes IP subnets requires the BGP speaker to inject the
   corresponding network into BGP-3. The local system shall provide
   mechanisms to control the exchange of routing information between
   BGP-3 and BGP-4.  Specifically, a conformant implementation is
   required to support all of the following options when injecting BGP-4
   received routing information into BGP-3:

       - inject default only (0.0.0.0), no export of any other NLRI

       - allow controlled deaggregation, but only of specific routes;
         allow export of non-aggregated NLRI

       - allow export of only non-aggregated NLRI

   The exchange of routing information via BGP-3 between a BGP speaker
   participating in BGP-4 and a pure BGP-3 speaker may occur  only at
   the autonomous system boundaries. Within a single autonomous system
   BGP conversations between all the BGP speakers of that autonomous
   system have to be either BGP-3 or BGP-4, but not a mixture.

9. Operations over Switched Virtual Circuits

   When using BGP over Switched Virtual Circuit (SVC) subnetworks it may
   be desirable to minimize traffic generated by BGP. Specifically, it
   may be desirable to eliminate traffic associated with periodic
   KEEPALIVE messages.  BGP includes a mechanism for operation over
   switched virtual circuit (SVC) services which avoids keeping SVCs
   permanently open and allows it to eliminates periodic sending of
   KEEPALIVE messages.

   This section describes how to operate without periodic KEEPALIVE
   messages to minimise SVC usage when using an intelligent SVC circuit
   manager.  The proposed scheme may also be used on "permanent"
   circuits, which support a feature like link quality monitoring or
   echo request to determine the status of link connectivity.

   The mechanism described in this section is suitable only between the
   BGP speakers that are directly connected over a common virtual
   circuit.



Rekhter & Gross                                                [Page 12]
^L
RFC 1655                   BGP-4 Application                   July 1994


9.1 Establishing a BGP Connection

   The feature is selected by specifying zero Hold Time in the OPEN
   message.

9.2 Circuit Manager Properties

   The circuit manager must have sufficient functionality to be able to
   compensate for the lack of periodic KEEPALIVE messages:

       - It must be able to determine link layer unreachability in a
         predictable finite period of a failure occurring.

       - On determining unreachability it should:

                - start a configurable dead timer (comparable to a
                  typical Hold timer value).

                - attempt to re-establish the Link Layer connection.

       - If the dead timer expires it should:

                - send an internal circuit DEAD indication to TCP.

       - If the connection is re-established it should:

                - cancel the dead timer.

                - send an internal circuit UP indication to TCP.

9.3 TCP Properties

   A small modification must be made to TCP to process internal
   notifications from the circuit manager:

       - DEAD: Flush transmit queue and abort TCP connection.

       - UP: Transmit any queued data or allow an outgoing TCP call to
         proceed.

9.4 Combined Properties

   Some implementations may not be able to guarantee that the BGP
   process and the circuit manager will operate as a single entity; i.e.
   they can have a separate existence when the other has been stopped or
   has crashed.





Rekhter & Gross                                                [Page 13]
^L
RFC 1655                   BGP-4 Application                   July 1994


   If this is the case, a periodic two-way poll between the BGP process
   and the circuit manager should be implemented.  If the BGP process
   discovers the circuit manager has gone away it should close all
   relevant TCP connections.  If the circuit manager discovers the BGP
   process has gone away it should close all its connections associated
   with the BGP process and reject any further incoming connections.

10. Conclusion

   The BGP protocol provides a high degree of control and flexibility
   for doing interdomain routing while enforcing policy and performance
   constraints and avoiding routing loops. The guidelines presented here
   will provide a starting point for using BGP to provide more
   sophisticated and manageable routing in the Internet as it grows.

Appendix A. The Interaction of BGP and an IGP

   This section outlines methods by which BGP can exchange routing
   information with an IGP. The methods outlined here are not proposed
   as part of the standard BGP usage at this time.  These methods are
   outlined for information purposes only.  Implementors may want to
   consider these methods when importing IGP information.

   This is general information that applies to any generic IGP.

   Interaction between BGP and any specific IGP is outside the scope of
   this section.  Methods for specific IGP's should be proposed in
   separate documents.  Methods for specific IGP's could be proposed for
   standard usage in the future.

Overview

   By definition, all transit AS's must be able to carry traffic which
   originates from and/or is destined to locations outside of that AS.
   This requires a certain degree of interaction and coordination
   between BGP and the Interior Gateway Protocol (IGP) used by that
   particular AS. In general, traffic originating outside of a given AS
   is going to pass through both interior gateways (gateways that
   support the IGP only) and border gateways (gateways that support both
   the IGP and BGP). All interior gateways receive information about
   external routes from one or more of the border gateways of the AS via
   the IGP.

   Depending on the mechanism used to propagate BGP information within a
   given AS, special care must be taken to ensure consistency between
   BGP and the IGP, since changes in state are likely to propagate at
   different rates across the AS. There may be a time window between the
   moment when some border gateway (A) receives new BGP routing



Rekhter & Gross                                                [Page 14]
^L
RFC 1655                   BGP-4 Application                   July 1994


   information which was originated from another border gateway (B)
   within the same AS, and the moment the IGP within this AS is capable
   of routing transit traffic to that border gateway (B). During that
   time window, either incorrect routing or "black holes" can occur.

   In order to minimize such routing problems, border gateway (A) should
   not advertise a route to some exterior network X via border gateway
   (B) to all of its BGP neighbors in other AS's until all the interior
   gateways within the AS are ready to route traffic destined to X via
   the correct exit border gateway (B). In other words, interior routing
   should converge on the proper exit gateway before/advertising routes
   via that exit gateway to other AS's.

A.2 Methods for Achieving Stable Interactions

   The following discussion outlines several techniques capable of
   achieving stable interactions between BGP and the IGP within an
   Autonomous System.

A.2.1 Propagation of BGP Information via the IGP

   While BGP can provide its own mechanism for carrying BGP information
   within an AS, one can also use an IGP to transport this information,
   as long as the IGP supports complete flooding of routing information
   (providing the mechanism to distribute the BGP information) and one
   pass convergence (making the mechanism effectively atomic). If an IGP
   is used to carry BGP information, then the period of
   desynchronization described earlier does not occur at all, since BGP
   information propagates within the AS synchronously with the IGP, and
   the IGP converges more or less simultaneously with the arrival of the
   new routing information. Note that the IGP only carries BGP
   information and should not interpret or process this information.

A.2.2  Tagged Interior Gateway Protocol

   Certain IGPs can tag routes exterior to an AS with the identity of
   their exit points while propagating them within the AS. Each border
   gateway should use identical tags for announcing exterior routing
   information (received via BGP) both into the IGP and into Internal
   BGP when propagating this information to other border gateways within
   the same AS. Tags generated by a border gateway must uniquely
   identify that particular border gateway--different border gateways
   must use different tags.

   All Border Gateways within a single AS must observe the following two
   rules:





Rekhter & Gross                                                [Page 15]
^L
RFC 1655                   BGP-4 Application                   July 1994


     1.  Information received via Internal BGP by a border gateway A
         declaring a network to be unreachable must immediately be
         propagated to all of the External BGP neighbors of A.

     2.  Information received via Internal BGP by a border gateway A
         about a reachable network X cannot be propagated to any of the
         External BGP neighbors of A unless/until A has an IGP route to
         X and both the IGP and the BGP routing information have
         identical tags.

   These rules guarantee that no routing information is announced
   externally unless the IGP is capable of correctly supporting it. It
   also avoids some causes of "black holes".

   One possible method for tagging BGP and IGP routes within an AS is to
   use the IP address of the exit border gateway announcing the exterior
   route into the AS. In this case the "gateway" field in the BGP UPDATE
   message is used as the tag.

   An alternate method for tagging BGP and IGP routes is to have BGP and
   the IGP agree on a router ID.  In this case, the router ID is
   available to all BGP (version 3 or higher) speakers.  Since this ID
   is already unique it can be used directly as the tag in the IGP.

A.2.3 Encapsulation

   Encapsulation provides the simplest (in terms of the interaction
   between the IGP and BGP) mechanism for carrying transit traffic
   across the AS. In this approach, transit traffic is encapsulated
   within an IP datagram addressed to the exit gateway. The only
   requirement imposed on the IGP by this approach is that it should be
   capable of supporting routing between border gateways within the same
   AS.

   The address of the exit gateway A for some exterior network X is
   specified in the BGP identifier field of the BGP OPEN message
   received from gateway A via Internal BGP by all other border gateways
   within the same AS. In order to route traffic to network X, each
   border gateway within the AS encapsulates it in datagrams addressed
   to gateway A. Gateway A then performs decapsulation and forwards the
   original packet to the proper gateway in another AS.

   Since encapsulation does not rely on the IGP to carry exterior
   routing information, no synchronization between BGP and the IGP is
   required.






Rekhter & Gross                                                [Page 16]
^L
RFC 1655                   BGP-4 Application                   July 1994


   Some means of identifying datagrams containing encapsulated IP, such
   as an IP protocol type code, must be defined if this method is to be
   used.

   Note that, if a packet to be encapsulated has length that is very
   close to the MTU, that packet would be fragmented at the gateway that
   performs encapsulation.

A.2.4  Pervasive BGP

   If all routers in an AS are BGP speakers, then there is no need to
   have any interaction between BGP and an IGP.  In such cases, all
   routers in the AS already have full information of all BGP routes.
   The IGP is then only used for routing within the AS, and no BGP
   routes are imported into the IGP.

   For routers to operate in this fashion, they must be able to perform
   a recursive lookup in their routing table.  The first lookup will use
   a BGP route to establish the exit router, while the second lookup
   will determine the IGP path to the exit router.

   Since the IGP carries no external information in this scenario, all
   routers in the AS will have converged as soon as all BGP speakers
   have new information about this route.  Since there is no need to
   delay for the IGP to converge, an implementation may advertise these
   routes without further delay due to the IGP.

A.2.5  Other Cases

   There may be AS's with IGPs which can neither carry BGP information
   nor tag exterior routes (e.g., RIP). In addition, encapsulation may
   be either infeasible or undesirable. In such situations, the
   following two rules must be observed:

     1.  Information received via Internal BGP by a border gateway A
         declaring a network to be unreachable must immediately be
         propagated to all of the External BGP neighbors of A.

     2.  Information received via Internal BGP by a border gateway A
         about a reachable network X cannot be propagated to any of the
         External BGP neighbors of A unless A has an IGP route to X and
         sufficient time has passed for the IGP routes to have
         converged.

   The above rules present necessary (but not sufficient) conditions for
   propagating BGP routing information to other AS's. In contrast to
   tagged IGPs, these rules cannot ensure that interior routes to the
   proper exit gateways are in place before propagating the routes to



Rekhter & Gross                                                [Page 17]
^L
RFC 1655                   BGP-4 Application                   July 1994


   other AS's.

   If the convergence time of an IGP is less than some small value X,
   then the time window during which the IGP and BGP are unsynchronized
   is less than X as well, and the whole issue can be ignored at the
   cost of transient periods (of less than length X) of routing
   instability. A reasonable value for X is a matter for further study,
   but X should probably be less than one second.

   If the convergence time of an IGP cannot be ignored, a different
   approach is needed. Mechanisms and techniques which might be
   appropriate in this situation are subjects for further study.

References

   [1] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4), RFC
       1654, cisco Systems, T.J. Watson Research Center, IBM Corp., July
       1994.

   [2] Braun, H-W., "Models of Policy Based Routing", RFC 1104,
       Merit/NSFNET, July 1989.

   [3] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting:  an
       Address Assignment and Aggregation Strategy", RFC 1519, BARRNet,
       cisco, MERIT, OARnet, September 1993.


























Rekhter & Gross                                                [Page 18]
^L
RFC 1655                   BGP-4 Application                   July 1994


Security Considerations

   Security issues are not discussed in this memo.

Authors' Addresses

   Yakov Rekhter
   T.J. Watson Research Center IBM Corporation
   P.O. Box 218
   Yorktown Heights, NY 10598

   Phone:  (914) 945-3896
   EMail: yakov@watson.ibm.com


   Phill Gross
   Director of Broadband Engineering
   MCI Data Services Division
   2100 Reston Parkway, Room 6001
   Reston, VA 22091

   Phone: +1 703 715 7432
   Fax: +1 703 715 7436
   EMail: 0006423401@mcimail.com

   IETF BGP WG mailing list: bgp@ans.net
   To be added: bgp-request@ans.net
























Rekhter & Gross                                                [Page 19]
^L