[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/