[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
- [Idr] Clarification requested for RFC 4271 Sectio… Rohan Sen
- RE: [Idr] Clarification requested for RFC 4271 Se… Jan Novak (janovak)