Subject: [Idr] Issue 11 - section 8.1.5 - Issue 11b

From: "Susan Hares" <[email-masked]>
Date: Mon, 7 Jul 2003 13:33:15 -0400

Alex and idr group: 

It is my understanding that following two text sections 
below indicates some governing of policy: 

   Upon receipt of an OPEN message, the local system MUST examine all of
   its connections that are in the OpenConfirm state. A BGP speaker MAY
   also examine connections in an OpenSent state if it knows the BGP
   Identifier of the peer by means outside of the protocol.

   Unless allowed via configuration, a connection collision with an
   existing BGP connection that is in Established state causes closing
   of the newly created connection.

Due to this reason, section 8.1.5 has the text "implementation specific logic".

Comments on this section are welcomed to resolve the AD-review comments
on section 8.1.5.

Sue

==========================================================
6.8 BGP connection collision detection.

   If a pair of BGP speakers try simultaneously to establish a BGP con-
   nection to each other, then two parallel connections between this
   pair of speakers might well be formed. If the source IP address used
   by one of these connections is the same as the destination IP address
   used by the other, and the destination IP address used by the first
   connection is the same as the source IP address used by the other, we
   refer to this situation as connection collision.  Clearly in the
   presence of connection collision, one of these connections MUST be
   closed.

   Based on the value of the BGP Identifier a convention is established
   for detecting which BGP connection is to be preserved when a colli-
   sion does occur. The convention is to compare the BGP Identifiers of
   the peers involved in the collision and to retain only the connection
   initiated by the BGP speaker with the higher-valued BGP Identifier.

   Upon receipt of an OPEN message, the local system MUST examine all of
   its connections that are in the OpenConfirm state. A BGP speaker MAY
   also examine connections in an OpenSent state if it knows the BGP
   Identifier of the peer by means outside of the protocol. If among
   these connections there is a connection to a remote BGP speaker whose
   BGP Identifier equals the one in the OPEN message, and this connec-
   tion collides with the connection over which the OPEN message is
   received then the local system performs the following collision reso-
   lution procedure:

      1. The BGP Identifier of the local system is compared to the BGP
      Identifier of the remote system (as specified in the OPEN mes-
      sage).  Comparing BGP Identifiers is done by converting them to
      host byte order and treating them as (4-octet long) unsigned inte-
      gers.

      2. If the value of the local BGP Identifier is less than the
      remote one, the local system closes the BGP connection that
      already exists (the one that is already in the OpenConfirm state),
      and accepts the BGP connection initiated by the remote system.

      3. Otherwise, the local system closes newly created BGP connection
      (the one associated with the newly received OPEN message), and
      continues to use the existing one (the one that is already in the
      OpenConfirm state).

Expiration Date September 2003                                 [Page 35]

RFC DRAFT                                                     March 2003

   Unless allowed via configuration, a connection collision with an
   existing BGP connection that is in Established state causes closing
   of the newly created connection.

   Note that a connection collision can not be detected with connections
   that are in Idle, or Connect, or Active states.

   Closing the BGP connection (that results from the collision resolu-
   tion procedure) is accomplished by sending the NOTIFICATION message
   with the Error Code Cease.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr