Network Working Group Enke Chen Internet Draft Jenny Yuan Expiration Date: March 2004 Redback Networks BGP Connection Collision Avoidance draft-chen-bgp-avoid-collision-00.txt 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract To simplify the BGP session bringup logic, in this document we propose a revision that allows a BGP speaker to play only the active or the passive role in establishing a BGP connection with another BGP speaker. A BGP speaker determines whether it will play the active or passive role based on the AS numbers and/or the peering addresses involved. Chen & Yuan [Page 1] Internet Draft draft-chen-bgp-avoid-collision-00.txt September 2003 3. Introduction As described in [1], BGP connection collisions may occur as a BGP speaker currently plays both the active and the passive roles in establishing a BGP connection with another BGP speaker. To resolve the connection collision, one TCP connection must be terminated. Clearly BGP connection collision consumes more system resource. More importantly, it introduces significant complications to the BGP state machine and therefore to the implementation of the BGP session bringup logic. To simplify the BGP session bringup logic, in this document we propose a revision that allows a BGP speaker to play only the active or the passive role in establishing a BGP connection with another BGP speaker. A BGP speaker determines whether it will play the active or passive role based on the AS numbers and/or the peering addresses involved. 4. Protocol Revision This revision assumes that the AS numbers and peering addresses are known (e.g., via configuration) before a BGP connection is attempted. A BGP speaker plays either an active or passive role in establishing a BGP connection with another speaker. If a BGP speaker is active, it attempts to establish the BGP TCP connection by connecting to the well-known BGP port at the address of the other speaker. If a BGP speaker is passive, it waits for the other speaker to establish the BGP TCP connection to its well-known BGP port. A BGP speaker (S1) determines whether it will play the active or passive role by first comparing its AS number (AS1) with the AS number (AS2) of the other speaker (S2): If AS1 > AS2, S1 plays the active role. If AS1 < AS2, S1 plays the passive role. If AS1 == AS2, then the peering addresses (A1 for S1, and A2 for S2) are compared as unsigned integers. If A1 > A2, S1 plays the active role; otherwise it plays the passive role. The procedure for comparing A1 and A2 as unsigned integers is as follows: If A1 and A2 are not in the same address family, they are Chen & Yuan [Page 2] Internet Draft draft-chen-bgp-avoid-collision-00.txt September 2003 incomparable, and no session can be established. Let U1 be the abstract unsigned integer obtained by treating A1 as a sequence of bytes, where the byte which appears earliest is the most significant byte of the integer and the byte which appears latest is the least significant byte of the integer. Let U2 be the abstract unsigned integer obtained from A2 in a similar manner. Compare U1 with U2. If U1 > U2, then A1 > A2; if U1 < U2, then A1 < A2. 5. Remarks Clearly a BGP speaker (whether active or passive) following the proposed revision would be able to bring up a BGP session with another BGP speaker that plays both active and passive roles in establishing a BGP connection as described in [1]. In certain implementations a BGP speaker would not play the active role using a default route to reach the remote peering address. Nevertheless a BGP connection could still be formed when the remote speaker plays both the active and passive roles in such cases. With the proposed revision, though, the BGP connection would not be formed when the remote speaker plays only the passive role. Such cases are rare, and in particular do not occur with one-hop EBGP sessions. They can be easily identified and corrected by simple re-configuration. We belive that the benefits of the proposed revision outweight the effort involved in identifying and reconfiguring such peers during deployment. 6. Security Considerations This revision to BGP does not change the underlying security issues. Chen & Yuan [Page 3] Internet Draft draft-chen-bgp-avoid-collision-00.txt September 2003 7. Acknowledgments TBD 8. References [1] Y. Rekhter, T. Li and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", draft-ietf-idr-bgp4-20.txt, April 2003. 9. Author Information Enke Chen Redback Networks, Inc. 300 Holger Way San Jose, CA 95134 e-mail: enke@redback.com Jenny Yuan Redback Networks, Inc. 300 Holger Way San Jose, CA 95134 e-mail: enke@redback.com Chen & Yuan [Page 4]