Difference between revisions of "RFC1266"
imported>Admin (Created page with " Network Working Group Y. Rekhter, Editor Request for Comments: 1266 T.J. Watson Research Center, IBM Corp. ...") |
|||
Line 1: | Line 1: | ||
− | |||
Line 8: | Line 7: | ||
Request for Comments: 1266 T.J. Watson Research Center, IBM Corp. | Request for Comments: 1266 T.J. Watson Research Center, IBM Corp. | ||
October 1991 | October 1991 | ||
− | |||
Experience with the BGP Protocol | Experience with the BGP Protocol | ||
− | |||
== Status of this Memo. == | == Status of this Memo. == | ||
− | |||
This memo provides information for the Internet community. It does | This memo provides information for the Internet community. It does | ||
not specify an Internet standard. Distribution of this memo is | not specify an Internet standard. Distribution of this memo is | ||
unlimited. | unlimited. | ||
− | |||
== Introduction. == | == Introduction. == | ||
− | |||
The purpose of this memo is to document how the requirements for | The purpose of this memo is to document how the requirements for | ||
advancing a routing protocol to Draft Standard have been satisfied by | advancing a routing protocol to Draft Standard have been satisfied by | ||
Line 27: | Line 21: | ||
Engineering Steering Group (IESG), the first report will present a | Engineering Steering Group (IESG), the first report will present a | ||
performance analysis of the BGP protocol. | performance analysis of the BGP protocol. | ||
− | |||
The remaining sections of this memo document how BGP satisfies | The remaining sections of this memo document how BGP satisfies | ||
General Requirements specified in Section 3.0, as well as | General Requirements specified in Section 3.0, as well as | ||
Requirements for Draft Standard specified in Section 5.0 of the | Requirements for Draft Standard specified in Section 5.0 of the | ||
"Internet Routing Protocol Standardization Criteria" document [1]. | "Internet Routing Protocol Standardization Criteria" document [1]. | ||
− | |||
This report is based on the work of Dennis Ferguson (University of | This report is based on the work of Dennis Ferguson (University of | ||
Toronto), Susan Hares (MERIT/NSFNET), and Jessica Yu (MERIT/NSFNET). | Toronto), Susan Hares (MERIT/NSFNET), and Jessica Yu (MERIT/NSFNET). | ||
Line 38: | Line 30: | ||
(March 11-15, 1991, St. Louis) and are available from the IETF | (March 11-15, 1991, St. Louis) and are available from the IETF | ||
Proceedings. | Proceedings. | ||
− | |||
Please send comments to [email protected]. | Please send comments to [email protected]. | ||
− | |||
== Acknowledgements. == | == Acknowledgements. == | ||
− | |||
The BGP protocol has been developed by the IWG/BGP Working Group of | The BGP protocol has been developed by the IWG/BGP Working Group of | ||
the Internet Engineering Task Force. We would like to express our | the Internet Engineering Task Force. We would like to express our | ||
Line 49: | Line 38: | ||
Bob Hinden (BBN) for the review of this document as well as his | Bob Hinden (BBN) for the review of this document as well as his | ||
constructive and valuable comments. | constructive and valuable comments. | ||
+ | |||
+ | |||
Line 59: | Line 50: | ||
== Documentation. == | == Documentation. == | ||
− | |||
BGP is an inter-autonomous system routing protocol designed for the | BGP is an inter-autonomous system routing protocol designed for the | ||
TCP/IP internets. Version 1 of the BGP protocol was published in RFC | TCP/IP internets. Version 1 of the BGP protocol was published in RFC | ||
1105. Since then BGP Versions 2 and 3 have been developed. Version 2 | 1105. Since then BGP Versions 2 and 3 have been developed. Version 2 | ||
− | was documented in | + | was documented in RFC 1163. Version 3 is documented in [3]. The |
changes between versions 1, 2 and 3 are explained in Appendix 3 of | changes between versions 1, 2 and 3 are explained in Appendix 3 of | ||
[3]. Most of the functionality that was present in the Version 1 is | [3]. Most of the functionality that was present in the Version 1 is | ||
Line 69: | Line 59: | ||
Version 2 affect mostly the format of the BGP messages. Changes | Version 2 affect mostly the format of the BGP messages. Changes | ||
between Version 2 and Version 3 are quite minor. | between Version 2 and Version 3 are quite minor. | ||
− | |||
BGP Version 2 removed from the protocol the concept of "up", "down", | BGP Version 2 removed from the protocol the concept of "up", "down", | ||
and "horizontal" relations between autonomous systems that were | and "horizontal" relations between autonomous systems that were | ||
Line 80: | Line 69: | ||
within an autonomous system. Possible applications of BGP in the | within an autonomous system. Possible applications of BGP in the | ||
Internet are documented in [2]. | Internet are documented in [2]. | ||
− | |||
The BGP protocol was developed by the IWG/BGP Working Group of the | The BGP protocol was developed by the IWG/BGP Working Group of the | ||
Internet Engineering Task Force. This Working Group has a mailing | Internet Engineering Task Force. This Working Group has a mailing | ||
Line 87: | Line 75: | ||
the quarterly Internet Engineering Task Force conferences. Reports of | the quarterly Internet Engineering Task Force conferences. Reports of | ||
these meetings are published in the IETF's Proceedings. | these meetings are published in the IETF's Proceedings. | ||
− | |||
== MIB == | == MIB == | ||
− | |||
A BGP Management Information Base has been published [4]. The MIB | A BGP Management Information Base has been published [4]. The MIB | ||
was written by Steve Willis ([email protected]) and John Burruss | was written by Steve Willis ([email protected]) and John Burruss | ||
− | |||
Apart from a few system variables, the BGP MIB is broken into two | Apart from a few system variables, the BGP MIB is broken into two | ||
tables: the BGP Peer Table and the BGP Received Path Attribute Table. | tables: the BGP Peer Table and the BGP Received Path Attribute Table. | ||
Line 101: | Line 86: | ||
routing policy has been applied. The actual attributes used in | routing policy has been applied. The actual attributes used in | ||
determining a route are a subset of the received attribute table. | determining a route are a subset of the received attribute table. | ||
+ | The BGP MIB is quite small. It contains total of 27 objects. | ||
+ | |||
− | |||
Line 112: | Line 98: | ||
== Security architecture. == | == Security architecture. == | ||
− | |||
BGP provides flexible and extendible mechanism for authentication and | BGP provides flexible and extendible mechanism for authentication and | ||
security. The mechanism allows to support schemes with various degree | security. The mechanism allows to support schemes with various degree | ||
Line 122: | Line 107: | ||
failures result in sending the NOTIFICATION messages and immediate | failures result in sending the NOTIFICATION messages and immediate | ||
termination of the BGP connection. | termination of the BGP connection. | ||
− | |||
Since BGP runs over TCP and IP, BGP's authentication scheme may be | Since BGP runs over TCP and IP, BGP's authentication scheme may be | ||
augmented by any authentication or security mechanism provided by | augmented by any authentication or security mechanism provided by | ||
either TCP or IP. | either TCP or IP. | ||
− | |||
== Implementations. == | == Implementations. == | ||
− | |||
There are multiple interoperable implementations of BGP currently | There are multiple interoperable implementations of BGP currently | ||
available. This section gives a brief overview of the three | available. This section gives a brief overview of the three | ||
completely independent implementations that are currently used in the | completely independent implementations that are currently used in the | ||
operational Internet. They are: | operational Internet. They are: | ||
− | |||
- cisco. This implementation was wholly developed by cisco. | - cisco. This implementation was wholly developed by cisco. | ||
It runs on the proprietary operating system used by the | It runs on the proprietary operating system used by the | ||
cisco routers. Consult Kirk Lougheed ([email protected]) | cisco routers. Consult Kirk Lougheed ([email protected]) | ||
for more details. | for more details. | ||
− | |||
- "gated". This implementation was developed wholly by Jeff | - "gated". This implementation was developed wholly by Jeff | ||
Honig ([email protected]) and Dennis Ferguson | Honig ([email protected]) and Dennis Ferguson | ||
Line 145: | Line 125: | ||
code for BGP. Consult Jeff Honig or Dennis Ferguson for more | code for BGP. Consult Jeff Honig or Dennis Ferguson for more | ||
details. | details. | ||
− | |||
- NSFNET. This implementation was developed wholly by Yakov | - NSFNET. This implementation was developed wholly by Yakov | ||
Rekhter ([email protected]). It runs on the T1 NSFNET | Rekhter ([email protected]). It runs on the T1 NSFNET | ||
Backbone and T3 NSFNET Backbone. Consult Yakov Rekhter for | Backbone and T3 NSFNET Backbone. Consult Yakov Rekhter for | ||
more details. | more details. | ||
− | |||
To facilitate efficient BGP implementations, and avoid commonly made | To facilitate efficient BGP implementations, and avoid commonly made | ||
mistakes, the implementation experience with BGP in "gated" was | mistakes, the implementation experience with BGP in "gated" was | ||
− | documented as part of | + | documented as part of RFC 1164. Implementors are strongly encouraged |
to follow the implementation suggestions outlined in that document. | to follow the implementation suggestions outlined in that document. | ||
− | |||
Experience with implementing BGP showed that the protocol is | Experience with implementing BGP showed that the protocol is | ||
relatively simple to implement. On the average BGP implementation | relatively simple to implement. On the average BGP implementation | ||
takes about 1 man/month effort. | takes about 1 man/month effort. | ||
+ | |||
+ | |||
Line 167: | Line 146: | ||
there are multiple interoperable completely independent | there are multiple interoperable completely independent | ||
implementations, namely those from cisco, "gated", and IBM. | implementations, namely those from cisco, "gated", and IBM. | ||
− | |||
== Operational experience. == | == Operational experience. == | ||
− | |||
This section discusses operational experience with BGP. | This section discusses operational experience with BGP. | ||
− | |||
BGP has been used in the production environment since 1989. This use | BGP has been used in the production environment since 1989. This use | ||
involves all three implementations listed above. Production use of | involves all three implementations listed above. Production use of | ||
Line 184: | Line 160: | ||
topologies it varies from a very sparse (spanning tree or a ring of | topologies it varies from a very sparse (spanning tree or a ring of | ||
CA*Net) to a quite dense (T1 or T3 NSFNET Backbones). | CA*Net) to a quite dense (T1 or T3 NSFNET Backbones). | ||
− | |||
At the time of this writing BGP is used as an inter-autonomous system | At the time of this writing BGP is used as an inter-autonomous system | ||
routing protocol between the following autonomous systems: CA*Net, T1 | routing protocol between the following autonomous systems: CA*Net, T1 | ||
Line 199: | Line 174: | ||
border routers that span 6 autonomous systems are part of the | border routers that span 6 autonomous systems are part of the | ||
operational Internet. | operational Internet. | ||
− | |||
BGP is used both for the exchange of routing information between a | BGP is used both for the exchange of routing information between a | ||
transit and a stub autonomous system, and for the exchange of routing | transit and a stub autonomous system, and for the exchange of routing | ||
Line 205: | Line 179: | ||
both the Backbones (CA*Net, T1 NSFNET Backbone, T3 NSFNET Backbone), | both the Backbones (CA*Net, T1 NSFNET Backbone, T3 NSFNET Backbone), | ||
and the Regional Networks (PSC, MERIT). | and the Regional Networks (PSC, MERIT). | ||
− | |||
Within CA*Net, T3 NSFNET Backbone, and T3 NSFNET Test Network BGP is | Within CA*Net, T3 NSFNET Backbone, and T3 NSFNET Test Network BGP is | ||
used as the exclusive carrier of the exterior routing information | used as the exclusive carrier of the exterior routing information | ||
Line 212: | Line 185: | ||
of this writing within the T1 NSFNET Backbone BGP is used together | of this writing within the T1 NSFNET Backbone BGP is used together | ||
with the NSFNET Backbone Interior Routing Protocol to carry the | with the NSFNET Backbone Interior Routing Protocol to carry the | ||
+ | |||
+ | |||
Line 221: | Line 196: | ||
by BGP. The full set of exterior routes that is carried by BGP is | by BGP. The full set of exterior routes that is carried by BGP is | ||
well over 2,000 networks. | well over 2,000 networks. | ||
− | |||
Operational experience described above involved multi-vendor | Operational experience described above involved multi-vendor | ||
deployment (cisco, "gated", and NSFNET). | deployment (cisco, "gated", and NSFNET). | ||
− | |||
Specific details of the operational experience with BGP in the NSFNET | Specific details of the operational experience with BGP in the NSFNET | ||
were presented at the Twentieth IETF meeting (March 11-15, 1991, St. | were presented at the Twentieth IETF meeting (March 11-15, 1991, St. | ||
Line 232: | Line 205: | ||
Ferguson (University of Toronto). Both of these presentations are | Ferguson (University of Toronto). Both of these presentations are | ||
available in the IETF Proceedings. | available in the IETF Proceedings. | ||
− | |||
Operational experience with BGP exercised all basic features of the | Operational experience with BGP exercised all basic features of the | ||
protocol, including the authentication and routing loop suppression. | protocol, including the authentication and routing loop suppression. | ||
− | |||
Bandwidth consumed by BGP has been measured at the interconnection | Bandwidth consumed by BGP has been measured at the interconnection | ||
points between CA*Net and T1 NSFNET Backbone. The results of these | points between CA*Net and T1 NSFNET Backbone. The results of these | ||
Line 245: | Line 216: | ||
confirmed clear superiority of BGP as compared with EGP in the area | confirmed clear superiority of BGP as compared with EGP in the area | ||
of CPU requirements. | of CPU requirements. | ||
− | |||
== Using TCP as a transport for BGP. == | == Using TCP as a transport for BGP. == | ||
− | + | 9.1. Introduction. | |
− | |||
− | |||
On multiple occasions some members of IETF expressed concern about | On multiple occasions some members of IETF expressed concern about | ||
using TCP as a transport protocol for BGP. In this section we examine | using TCP as a transport protocol for BGP. In this section we examine | ||
the use of TCP for BGP in terms of: | the use of TCP for BGP in terms of: | ||
− | |||
- real versus perceived problems | - real versus perceived problems | ||
- offer potential solutions to real problems | - offer potential solutions to real problems | ||
- perspective on the convergence problem | - perspective on the convergence problem | ||
- conclusions | - conclusions | ||
− | |||
BGP is based on the incremental updates. This is done intentionally | BGP is based on the incremental updates. This is done intentionally | ||
to conserve the CPU and bandwidth requirements. Extensive operational | to conserve the CPU and bandwidth requirements. Extensive operational | ||
Line 265: | Line 231: | ||
CPU utilization and bandwidth consumption. However, to operate | CPU utilization and bandwidth consumption. However, to operate | ||
correctly the incremental updates must be exchanged over a reliable | correctly the incremental updates must be exchanged over a reliable | ||
+ | |||
+ | |||
Line 272: | Line 240: | ||
transport. BGP uses TCP as such transport. It had been suggested | transport. BGP uses TCP as such transport. It had been suggested | ||
that another transport protocol would be more suitable for BGP. | that another transport protocol would be more suitable for BGP. | ||
− | + | 9.2. Examination of Problems - Real and "perceived". | |
− | |||
− | |||
Extensive operational experience with BGP in the Internet showed that | Extensive operational experience with BGP in the Internet showed that | ||
the only real problem that was attributed to BGP in general, and the | the only real problem that was attributed to BGP in general, and the | ||
Line 289: | Line 255: | ||
problems: congestion, packet drops, and the resulting slow | problems: congestion, packet drops, and the resulting slow | ||
convergence of routing under congestion and packet drops. | convergence of routing under congestion and packet drops. | ||
− | |||
Observe, that any transport protocol used by BGP would have | Observe, that any transport protocol used by BGP would have | ||
difficulty preventing packets from being dropped under congestion, | difficulty preventing packets from being dropped under congestion, | ||
Line 302: | Line 267: | ||
outside of BGP in general, and the transport protocol used by BGP in | outside of BGP in general, and the transport protocol used by BGP in | ||
particular, are taken. | particular, are taken. | ||
− | |||
If packets carrying routing information are lost, any distributed | If packets carrying routing information are lost, any distributed | ||
routing protocol will exhibit slow convergence. If quick convergence | routing protocol will exhibit slow convergence. If quick convergence | ||
Line 309: | Line 273: | ||
information must be taken. The next section suggests some possible | information must be taken. The next section suggests some possible | ||
methods. | methods. | ||
− | + | 9.3. Solutions to the problem. | |
− | |||
− | |||
Two possible measures could be taken to reduce the drop of BGP | Two possible measures could be taken to reduce the drop of BGP | ||
packets which slows convergence of routing: | packets which slows convergence of routing: | ||
+ | 1) alleviate the congestion | ||
+ | 2) reduce the percentage of BGP packets that are dropped due | ||
− | |||
− | |||
Line 325: | Line 287: | ||
to congestion by marking BGP packets and setting policies to | to congestion by marking BGP packets and setting policies to | ||
routers to try not to drop BGP packets | routers to try not to drop BGP packets | ||
− | |||
Alleviating the network congestion is a subject outside the control | Alleviating the network congestion is a subject outside the control | ||
of BGP, and will not be discussed in this paper. | of BGP, and will not be discussed in this paper. | ||
− | |||
Operational experience with BGP in CA*Net shows that reducing the | Operational experience with BGP in CA*Net shows that reducing the | ||
percentage of BGP packets dropped due to congestion by marking them, | percentage of BGP packets dropped due to congestion by marking them, | ||
Line 334: | Line 294: | ||
completely solves the problem of slow convergence in presence of | completely solves the problem of slow convergence in presence of | ||
congestion. | congestion. | ||
− | |||
The BGP packets can be marked (explicitly or implicitly) by the | The BGP packets can be marked (explicitly or implicitly) by the | ||
following three methods: | following three methods: | ||
− | |||
a) by means of IP precedence (Internetwork Control) | a) by means of IP precedence (Internetwork Control) | ||
− | |||
b) by using a well-known TCP port number | b) by using a well-known TCP port number | ||
− | |||
c) by identifying packets by just source or destination IP | c) by identifying packets by just source or destination IP | ||
address. | address. | ||
− | + | Appendix 4 of the BGP protocol specification, RFC 1163, recommends | |
− | Appendix 4 of the BGP protocol specification, | ||
the use of IP precedence (Internetwork Control) because the | the use of IP precedence (Internetwork Control) because the | ||
precedence provides a well-defined mechanism to mark BGP packets. | precedence provides a well-defined mechanism to mark BGP packets. | ||
Line 355: | Line 310: | ||
receive a priority if either the source or the destination IP address | receive a priority if either the source or the destination IP address | ||
belongs to CA*Net. | belongs to CA*Net. | ||
− | |||
If packets that carry the routing information are being dropped | If packets that carry the routing information are being dropped | ||
(because of congestion), one also may ask about how does a particular | (because of congestion), one also may ask about how does a particular | ||
Line 369: | Line 323: | ||
network, and not in how frequently the lost packets are | network, and not in how frequently the lost packets are | ||
retransmitted. | retransmitted. | ||
+ | It should also be pointed out that the local system can control the | ||
+ | |||
− | |||
Line 379: | Line 334: | ||
losses) by adjusting the TCP Window size. That allows to control the | losses) by adjusting the TCP Window size. That allows to control the | ||
amount of potentially obsolete data that has to be retransmitted. | amount of potentially obsolete data that has to be retransmitted. | ||
− | + | 9.4. Perspective on the Convergence Problem. | |
− | |||
− | |||
To put the convergence problem in a proper perspective, we'd like to | To put the convergence problem in a proper perspective, we'd like to | ||
point out that much of the Internet now uses EGP at AS borders, | point out that much of the Internet now uses EGP at AS borders, | ||
Line 391: | Line 344: | ||
case behavior of BGP is about the same as the steady case behavior of | case behavior of BGP is about the same as the steady case behavior of | ||
EGP. | EGP. | ||
− | |||
Within an AS the speed of convergence of the AS's IGP in the face of | Within an AS the speed of convergence of the AS's IGP in the face of | ||
congestion is of far greater concern than the propagation speed of | congestion is of far greater concern than the propagation speed of | ||
Line 397: | Line 349: | ||
aggressive transport is similarly of much greater importance for an | aggressive transport is similarly of much greater importance for an | ||
IGP than for BGP. | IGP than for BGP. | ||
− | |||
The issue of BGP convergence is of exaggerated importance to CA*Net | The issue of BGP convergence is of exaggerated importance to CA*Net | ||
since CA*Net carries no information about external routes in its IGP. | since CA*Net carries no information about external routes in its IGP. | ||
Line 409: | Line 360: | ||
configuration, where information about external routes will be | configuration, where information about external routes will be | ||
carried by an IGP. | carried by an IGP. | ||
− | + | 9.5. Conclusion. | |
− | |||
− | |||
The extensive operational experience with BGP showed that the only | The extensive operational experience with BGP showed that the only | ||
problem attributed to BGP was the slow convergence problem in | problem attributed to BGP was the slow convergence problem in | ||
Line 424: | Line 373: | ||
protocol (whether it is intra-autonomous system or inter-autonomous | protocol (whether it is intra-autonomous system or inter-autonomous | ||
system) should clearly specify how its behavior is affected by the | system) should clearly specify how its behavior is affected by the | ||
+ | |||
+ | |||
Line 431: | Line 382: | ||
congestion in the networks, and what are the possible mechanisms to | congestion in the networks, and what are the possible mechanisms to | ||
avoid the negative effect of congestion (if any). | avoid the negative effect of congestion (if any). | ||
− | + | 10. Bibliography. | |
− | |||
− | |||
[1] Hinden, B., "Internet Routing Protocol Standardization Criteria", | [1] Hinden, B., "Internet Routing Protocol Standardization Criteria", | ||
− | + | RFC 1264, BBN, October 1991. | |
− | |||
[2] Rekhter, Y., and P. Gross, "Application of the Border Gateway | [2] Rekhter, Y., and P. Gross, "Application of the Border Gateway | ||
− | Protocol in the Internet", | + | Protocol in the Internet", RFC 1268, T.J. Watson Research Center, |
IBM Corp., ANS, October 1991. | IBM Corp., ANS, October 1991. | ||
− | |||
[3] Lougheed, K., and Y. Rekhter, "A Border Gateway Protocol 3 (BGP- | [3] Lougheed, K., and Y. Rekhter, "A Border Gateway Protocol 3 (BGP- | ||
− | 3)", | + | 3)", RFC 1267, cisco Systems, T.J. Watson Research Center, IBM |
Corp., October 1991. | Corp., October 1991. | ||
− | |||
[4] Willis, S., and J. Burruss, "Definitions of Managed Objects for | [4] Willis, S., and J. Burruss, "Definitions of Managed Objects for | ||
− | the Border Gateway Protocol (Version 3)", | + | the Border Gateway Protocol (Version 3)", RFC 1269, Wellfleet |
Communications Inc., October 1991. | Communications Inc., October 1991. | ||
− | |||
Security Considerations | Security Considerations | ||
− | |||
Security issues are discussed in section 6. | Security issues are discussed in section 6. | ||
− | |||
Author's Address | Author's Address | ||
− | |||
Yakov Rekhter | Yakov Rekhter | ||
T.J. Watson Research Center IBM Corporation | T.J. Watson Research Center IBM Corporation | ||
P.O. Box 218 | P.O. Box 218 | ||
Yorktown Heights, NY 10598 | Yorktown Heights, NY 10598 | ||
− | |||
Phone: (914) 945-3896 | Phone: (914) 945-3896 | ||
EMail: [email protected] | EMail: [email protected] | ||
− | |||
IETF BGP WG mailing list: [email protected] | IETF BGP WG mailing list: [email protected] | ||
To be added: [email protected] | To be added: [email protected] |
Revision as of 00:51, 23 September 2020
Network Working Group Y. Rekhter, Editor Request for Comments: 1266 T.J. Watson Research Center, IBM Corp.
October 1991
Experience with the BGP Protocol
Contents
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.
Introduction.
The purpose of this memo is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by Border Gateway Protocol (BGP). This report documents experience with BGP. This is the second of two reports on the BGP protocol. As required by the Internet Activities Board (IAB) and the Internet Engineering Steering Group (IESG), the first report will present a performance analysis of the BGP protocol. The remaining sections of this memo document how BGP satisfies General Requirements specified in Section 3.0, as well as Requirements for Draft Standard specified in Section 5.0 of the "Internet Routing Protocol Standardization Criteria" document [1]. This report is based on the work of Dennis Ferguson (University of Toronto), Susan Hares (MERIT/NSFNET), and Jessica Yu (MERIT/NSFNET). Details of their work were presented at the Twentieth IETF meeting (March 11-15, 1991, St. Louis) and are available from the IETF Proceedings. Please send comments to [email protected].
Acknowledgements.
The BGP protocol has been developed by the IWG/BGP Working Group of the Internet Engineering Task Force. We would like to express our deepest thanks to Guy Almes (Rice University) who was the previous chairman of the IWG Working Group. We also like to explicitly thank Bob Hinden (BBN) for the review of this document as well as his constructive and valuable comments.
Documentation.
BGP is an inter-autonomous system routing protocol designed for the TCP/IP internets. Version 1 of the BGP protocol was published in RFC 1105. Since then BGP Versions 2 and 3 have been developed. Version 2 was documented in RFC 1163. Version 3 is documented in [3]. The changes between versions 1, 2 and 3 are explained in Appendix 3 of [3]. Most of the functionality that was present in the Version 1 is present in the Version 2 and 3. Changes between Version 1 and Version 2 affect mostly the format of the BGP messages. Changes between Version 2 and Version 3 are quite minor. BGP Version 2 removed from the protocol the concept of "up", "down", and "horizontal" relations between autonomous systems that were present in the Version 1. BGP Version 2 introduced the concept of path attributes. In addition, BGP Version 2 clarified parts of the protocol that were "underspecified". BGP Version 3 lifted some of the restrictions on the use of the NEXT_HOP path attribute, and added the BGP Identifier field to the BGP OPEN message. It also clarifies the procedure for distributing BGP routes between the BGP speakers within an autonomous system. Possible applications of BGP in the Internet are documented in [2]. The BGP protocol was developed by the IWG/BGP Working Group of the Internet Engineering Task Force. This Working Group has a mailing list, [email protected], where discussions of protocol features and operation are held. The IWG/BGP Working Group meets regularly during the quarterly Internet Engineering Task Force conferences. Reports of these meetings are published in the IETF's Proceedings.
MIB
A BGP Management Information Base has been published [4]. The MIB was written by Steve Willis ([email protected]) and John Burruss ([email protected]). Apart from a few system variables, the BGP MIB is broken into two tables: the BGP Peer Table and the BGP Received Path Attribute Table. The Peer Table reflects information about BGP peer connections, such as their state and current activity. The Received Path Attribute Table contains all attributes received from all peers before local routing policy has been applied. The actual attributes used in determining a route are a subset of the received attribute table. The BGP MIB is quite small. It contains total of 27 objects.
Security architecture.
BGP provides flexible and extendible mechanism for authentication and security. The mechanism allows to support schemes with various degree of complexity. All BGP sessions are authenticated based on the BGP Identifier of a peer. In addition, all BGP sessions are authenticated based on the autonomous system number advertised by a peer. As part of the BGP authentication mechanism, the protocol allows to carry encrypted digital signature in every BGP message. All authentication failures result in sending the NOTIFICATION messages and immediate termination of the BGP connection. Since BGP runs over TCP and IP, BGP's authentication scheme may be augmented by any authentication or security mechanism provided by either TCP or IP.
Implementations.
There are multiple interoperable implementations of BGP currently available. This section gives a brief overview of the three completely independent implementations that are currently used in the operational Internet. They are:
- cisco. This implementation was wholly developed by cisco. It runs on the proprietary operating system used by the cisco routers. Consult Kirk Lougheed ([email protected]) for more details. - "gated". This implementation was developed wholly by Jeff Honig ([email protected]) and Dennis Ferguson ([email protected]). It runs on a variety of operating systems (4.3 BSD, AIX, etc...). It is the only available public domain code for BGP. Consult Jeff Honig or Dennis Ferguson for more details. - NSFNET. This implementation was developed wholly by Yakov Rekhter ([email protected]). It runs on the T1 NSFNET Backbone and T3 NSFNET Backbone. Consult Yakov Rekhter for more details.
To facilitate efficient BGP implementations, and avoid commonly made mistakes, the implementation experience with BGP in "gated" was documented as part of RFC 1164. Implementors are strongly encouraged to follow the implementation suggestions outlined in that document. Experience with implementing BGP showed that the protocol is relatively simple to implement. On the average BGP implementation takes about 1 man/month effort.
Note that, as required by the IAB/IESG for Draft Standard status, there are multiple interoperable completely independent implementations, namely those from cisco, "gated", and IBM.
Operational experience.
This section discusses operational experience with BGP. BGP has been used in the production environment since 1989. This use involves all three implementations listed above. Production use of BGP includes utilization of all significant features of the protocol. The present production environment, where BGP is used as the inter- autonomous system routing protocol, is highly heterogeneous. In terms of the link bandwidth it varies from 56 Kbits/sec to 45 Mbits/sec. In terms of the actual routes that run BGP it ranges from a relatively slow performance PC/RT to a very high performance RS/6000, and includes both the special purpose routers (cisco) and the general purpose workstations running UNIX. In terms of the actual topologies it varies from a very sparse (spanning tree or a ring of CA*Net) to a quite dense (T1 or T3 NSFNET Backbones). At the time of this writing BGP is used as an inter-autonomous system routing protocol between the following autonomous systems: CA*Net, T1 NSFNET Backbone, T3 NSFNET Backbone, T3 NSFNET Test Network, CICNET, MERIT, and PSC. Within CA*Net there are 10 border routers participating in BGP. Within T1 NSFNET Backbone there are 20 border routers participating in BGP. Within T3 NSFNET Backbone there are 15 border routers participating in BGP. Within T3 NSFNET Test Network there are 7 border routers participating in BGP. Within CICNET there are 2 border routers participating in BGP. Within MERIT there is 1 border router participating in BGP. Within PSC there is 1 router participating in BGP. All together there are 56 border routers spanning 7 autonomous systems that are running BGP. Out of these, 49 border routers that span 6 autonomous systems are part of the operational Internet. BGP is used both for the exchange of routing information between a transit and a stub autonomous system, and for the exchange of routing information between multiple transit autonomous systems. It covers both the Backbones (CA*Net, T1 NSFNET Backbone, T3 NSFNET Backbone), and the Regional Networks (PSC, MERIT). Within CA*Net, T3 NSFNET Backbone, and T3 NSFNET Test Network BGP is used as the exclusive carrier of the exterior routing information both between the autonomous systems that correspond to the above networks, and with the autonomous system of each network. At the time of this writing within the T1 NSFNET Backbone BGP is used together with the NSFNET Backbone Interior Routing Protocol to carry the
exterior routing information. T1 NSFNET Backbone is in the process of moving toward carrying the exterior routing information exclusively by BGP. The full set of exterior routes that is carried by BGP is well over 2,000 networks. Operational experience described above involved multi-vendor deployment (cisco, "gated", and NSFNET). Specific details of the operational experience with BGP in the NSFNET were presented at the Twentieth IETF meeting (March 11-15, 1991, St. Louis) by Susan Hares (MERIT/NSFNET). Specific details of the operational experience with BGP in the CA*Net were presented at the Twentieth IETF meeting (March 11-15, 1991, St. Louis) by Dennis Ferguson (University of Toronto). Both of these presentations are available in the IETF Proceedings. Operational experience with BGP exercised all basic features of the protocol, including the authentication and routing loop suppression. Bandwidth consumed by BGP has been measured at the interconnection points between CA*Net and T1 NSFNET Backbone. The results of these measurements were presented by Dennis Ferguson during the last IETF, and are available from the IETF Proceedings. These results showed clear superiority of BGP as compared with EGP in the area of bandwidth consumed by the protocol. Observations on the CA*Net by Dennis Ferguson, and on the T1 NSFNET Backbone by Susan Hares confirmed clear superiority of BGP as compared with EGP in the area of CPU requirements.
Using TCP as a transport for BGP.
9.1. Introduction. On multiple occasions some members of IETF expressed concern about using TCP as a transport protocol for BGP. In this section we examine the use of TCP for BGP in terms of:
- real versus perceived problems - offer potential solutions to real problems - perspective on the convergence problem - conclusions
BGP is based on the incremental updates. This is done intentionally to conserve the CPU and bandwidth requirements. Extensive operational experience with BGP in the Internet showed that indeed the use of the incremental updates allows significant saving both in terms of the CPU utilization and bandwidth consumption. However, to operate correctly the incremental updates must be exchanged over a reliable
transport. BGP uses TCP as such transport. It had been suggested that another transport protocol would be more suitable for BGP. 9.2. Examination of Problems - Real and "perceived". Extensive operational experience with BGP in the Internet showed that the only real problem that was attributed to BGP in general, and the use of TCP as the transport for BGP in particular, was its slow convergence in presence of congestion. This problem was experienced in CA*Net. As we mentioned before, CA*Net is composed of 10 routers that form a ring. The routers are connected by 56 Kbits/sec links. All links are heavily utilized and are often congested. Experience with BGP in CA*Net showed that unless special measures are taken, the protocol may exhibit slow convergence when BGP information is passed over the slow speed (56 Kbits/sec) congested links. This is because a large percentage of packets carrying BGP information are being dropped due to congestion. Therefore, there are three inter-related problems: congestion, packet drops, and the resulting slow convergence of routing under congestion and packet drops. Observe, that any transport protocol used by BGP would have difficulty preventing packets from being dropped under congestion, since it has no direct control over the routers that drop the packets, and the congestion has nothing to do with the BGP traffic. Therefore, since BGP is not the cause of congestion, and cannot directly influence dropping at the routers, replacing TCP (as the BGP transport) with another transport protocol would have no effect on packets being dropped due to congestion. We think that once a network is congested, packets will be dropped (regardless of whether these packets carry BGP or any other information), unless special measures outside of BGP in general, and the transport protocol used by BGP in particular, are taken. If packets carrying routing information are lost, any distributed routing protocol will exhibit slow convergence. If quick convergence is viewed as important for a routing within a network, special measures to minimize the loss of packets that carry routing information must be taken. The next section suggests some possible methods. 9.3. Solutions to the problem. Two possible measures could be taken to reduce the drop of BGP packets which slows convergence of routing:
1) alleviate the congestion 2) reduce the percentage of BGP packets that are dropped due
to congestion by marking BGP packets and setting policies to routers to try not to drop BGP packets
Alleviating the network congestion is a subject outside the control of BGP, and will not be discussed in this paper. Operational experience with BGP in CA*Net shows that reducing the percentage of BGP packets dropped due to congestion by marking them, and setting policies to routers to try not to drop BGP packets completely solves the problem of slow convergence in presence of congestion. The BGP packets can be marked (explicitly or implicitly) by the following three methods:
a) by means of IP precedence (Internetwork Control) b) by using a well-known TCP port number c) by identifying packets by just source or destination IP address.
Appendix 4 of the BGP protocol specification, RFC 1163, recommends the use of IP precedence (Internetwork Control) because the precedence provides a well-defined mechanism to mark BGP packets. The method of a well-known TCP port number to identify packets is similar to the one that was used by Dave Mills in the NSFNET Phase I. Dave Mills identified Telnet traffic by a well known TCP port number, and gave it priority over the rest of the traffic. CA*Net identified BGP traffic based on it's source and destination IP address. Packets receive a priority if either the source or the destination IP address belongs to CA*Net. If packets that carry the routing information are being dropped (because of congestion), one also may ask about how does a particular routing protocol react to such an event. In the case of BGP the packets are retransmitted using the TCP retransmission mechanism. It seems plausible that being more aggressive in terms of the retransmission should have positive effect on the convergence. This can be done completely within TCP by adjusting the TCP retransmission timers. However, we would like to point out that the change in the retransmission strategy should not be viewed as a cure for the problem, since the root of the problem lies in the way how packets that carry the BGP information are handled within a congested network, and not in how frequently the lost packets are retransmitted. It should also be pointed out that the local system can control the
amount of data to be retransmitted (in case of a congestion or losses) by adjusting the TCP Window size. That allows to control the amount of potentially obsolete data that has to be retransmitted. 9.4. Perspective on the Convergence Problem. To put the convergence problem in a proper perspective, we'd like to point out that much of the Internet now uses EGP at AS borders, ensuring that routing changes cannot be guaranteed to propagate between ASes in less than a few minutes. It would take huge amount of congestion to slow BGP to this pace. Additionally, the problems of EGP in the face of packet loss are well known and far exceed any imaginable problem BGP/TCP might ever suffer. Therefore, the worst case behavior of BGP is about the same as the steady case behavior of EGP. Within an AS the speed of convergence of the AS's IGP in the face of congestion is of far greater concern than the propagation speed of BGP, and indeed avoiding loss of packets carrying IGP, and a more aggressive transport is similarly of much greater importance for an IGP than for BGP. The issue of BGP convergence is of exaggerated importance to CA*Net since CA*Net carries no information about external routes in its IGP. CA*Net uses BGP to transfer external routes for use in computing internal routes through the CA*Net network. The reason CA*Net does this has nothing to do with BGP. Under more ordinary circumstances an IGP carries external routing information for use in computing internal routes. CA*Net shows that BGP can work under extreme stress. However, it's results should not be taken as the norm since most networks will use BGP in a different (and less stressful) configuration, where information about external routes will be carried by an IGP. 9.5. Conclusion. The extensive operational experience with BGP showed that the only problem attributed to BGP was the slow convergence problem in presence of congestion. We demonstrated that this problem has nothing to do with BGP in general, or with TCP as the BGP transport in particular, but is directly related to the way how packets that carry routing information are handled within a congested network. The document suggests possible ways of solving the problem. We would like to point out that the issue of convergence in presence of congested network is important to all distributed routing protocol, and not just to BGP. Therefore, we recommend that every routing protocol (whether it is intra-autonomous system or inter-autonomous system) should clearly specify how its behavior is affected by the
congestion in the networks, and what are the possible mechanisms to avoid the negative effect of congestion (if any). 10. Bibliography. [1] Hinden, B., "Internet Routing Protocol Standardization Criteria",
RFC 1264, BBN, October 1991.
[2] Rekhter, Y., and P. Gross, "Application of the Border Gateway
Protocol in the Internet", RFC 1268, T.J. Watson Research Center, IBM Corp., ANS, October 1991.
[3] 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.
[4] Willis, S., and J. Burruss, "Definitions of Managed Objects for
the Border Gateway Protocol (Version 3)", RFC 1269, Wellfleet Communications Inc., October 1991.
Security Considerations Security issues are discussed in section 6. Author's Address Yakov Rekhter T.J. Watson Research Center IBM Corporation P.O. Box 218 Yorktown Heights, NY 10598 Phone: (914) 945-3896 EMail: [email protected] IETF BGP WG mailing list: [email protected] To be added: [email protected]