Internet DRAFT - draft-chen-bgp-avoid-collision
draft-chen-bgp-avoid-collision
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]
