[Idr] Clarification requested for RFC 4271 Section 6.8 'Connection Collision Detection'

"Rohan Sen" <senrohan@gmail.com> Sun, 09 December 2007 18:00 UTC

Return-path: <idr-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1QSN-0000XC-LN; Sun, 09 Dec 2007 13:00:47 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1QSM-0000Tu-0z for idr@ietf.org; Sun, 09 Dec 2007 13:00:46 -0500
Received: from py-out-1112.google.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1QSL-0004Kj-NQ for idr@ietf.org; Sun, 09 Dec 2007 13:00:46 -0500
Received: by py-out-1112.google.com with SMTP id d32so5881905pye for <idr@ietf.org>; Sun, 09 Dec 2007 10:00:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=mGYYFmTIBbutZv/gIVoviSTeyjiINvjvJUBVek7+Rt4=; b=COk7emPC7Z3GmO6WZUFLTYHfLBPxtBJkfvwZlyJVy04vN95ozr07bE5t7G0rnLLb8crsgQgmm1AXbC7OyZomSMHosGJTFRG2IfSxBBd7hGk5oIHrR2ENm0S2np6CTJoHZgB+5ukCcGjs6S+4Ef2X+UBg1jtrolyjINgP8/Gd2U8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=SKv/l6gBVg++kb5s1ZAkxTyH1jk0ahFEsQ/wBNzrNfEfcO+vFSjEcVwTIwR8WQDpSMEPXgN/7NTaZ90MDs0k157Vbcv0NVcUF+GWb0db/mQ0AXJIPy7UcFlSZio5COIlxycja9DBGDFxM7KlaR5RS8aur4Eu1e0ON7cruWjO/Xo=
Received: by 10.142.156.2 with SMTP id d2mr21895wfe.1197223243143; Sun, 09 Dec 2007 10:00:43 -0800 (PST)
Received: by 10.142.47.6 with HTTP; Sun, 9 Dec 2007 10:00:43 -0800 (PST)
Message-ID: <8320074d0712091000i77a26727s6969d9e20e467d1@mail.gmail.com>
Date: Sun, 09 Dec 2007 23:30:43 +0530
From: Rohan Sen <senrohan@gmail.com>
To: idr@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Subject: [Idr] Clarification requested for RFC 4271 Section 6.8 'Connection Collision Detection'
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
Errors-To: idr-bounces@ietf.org

Hello,


 I am implementing a BGP state machine on Linux and am facing a doubt
related to connection collision which seem to rise from a possibly
contradicting statement in RFC 4271.

 Let me try to explain my understanding with 2 routers L (local BGP)
and R (remote BGP).

 if (routerId(L) < routerId(R)) {
  1. the local system closes the BGP connection that
         already exists (the one that is already in the OpenConfirm
         state)  <--------- What if this is the connection initiated
by the remote peer then this connection cannot be closed and accepted
at the same time
  2. accepts the BGP connection initiated by the remote  system.
 } else {
  3. the local system closes the newly created BGP
         connection (the one associated with the newly received OPEN
         message) <-------- What if this is the connection initiated
by L then we are closing the connection opened by us even if we have
higher router id
  4. continues to use the existing one (the one that is already in the
OpenConfirm state)
 }

Also elsewhere in this RFC (Page 35) it states that:
"Based on the value of the BGP Identifier, a convention is established
 for detecting which BGP connection is to be preserved when a
 collision occurs. 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."


This statement is again contradicting the other cases viz. case (1)
and case (3).

I am really confused in this regard and would really appreciate any
help to understand this scenario better/correctly.

-- 
thanks,
Rohan Sen

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr