RE: BFD queries

kalpana.yenishetti@wipro.com Tue, 25 October 2005 06:25 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUIFg-0006hl-5g; Tue, 25 Oct 2005 02:25:40 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUIFe-0006hd-0n for rtg-bfd@megatron.ietf.org; Tue, 25 Oct 2005 02:25:38 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23566 for <rtg-bfd@ietf.org>; Tue, 25 Oct 2005 02:25:24 -0400 (EDT)
From: kalpana.yenishetti@wipro.com
Received: from wip-ec-wd.wipro.com ([203.91.193.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUISL-0007fM-KA for rtg-bfd@ietf.org; Tue, 25 Oct 2005 02:38:58 -0400
Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 57295205EF for <rtg-bfd@ietf.org>; Tue, 25 Oct 2005 11:42:28 +0530 (IST)
Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 372E0205D9 for <rtg-bfd@ietf.org>; Tue, 25 Oct 2005 11:42:28 +0530 (IST)
Received: from hyd-mdp-msg.wipro.com ([10.150.50.99]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Oct 2005 11:54:50 +0530
Received: from HYD-MKD-MBX01.wipro.com ([10.154.50.182]) by hyd-mdp-msg.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 11:53:37 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5D92C.9EA70DC6"
Date: Tue, 25 Oct 2005 11:53:31 +0530
Message-ID: <BD6DEA8C77182E4586B6BE33532EA48D38CC0C@HYD-MKD-MBX01.wipro.com>
Thread-Topic: BFD queries
Thread-Index: AcXZKX8oIcJ7IVf5Qdu7N60KKZkLhgAAWIkQ
To: rtg-bfd@ietf.org
X-OriginalArrivalTime: 25 Oct 2005 06:23:37.0082 (UTC) FILETIME=[A2123DA0:01C5D92C]
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 1e47b908cbd1247f22e7953a41f1c4c6
Subject: RE: BFD queries
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
Sender: rtg-bfd-bounces@ietf.org
Errors-To: rtg-bfd-bounces@ietf.org

 

Thanks Dave

 

Let me frame the question like this 

 

 

1.	When a BFD session is established between two nodes in a
network, and if one of the system sends a BFD control packet with POLL
bit set to change any the Min Tx/Rx intervals and the receives response
to the previous BFD packet. This could lead to situation where sender
assuming his request for configuration change for Min Tx/Rx intervals is
declined.

The intervals cannot be "declined" as they are entirely unilateral in
each direction (which is an important design consideration in the
protocol.)  The packet with Final lets the system know that the other
system has seen the change and, for example, won't time out if the
sender wants to transmit at a slower rate.

 

1.

 

Node A                                     Node B

 

Bfd    -----Session State UP-----   Bfd (session up n running on both
nodes, with mandatory mode, Asynch)

 

Bfd control pkts  <----------> Bfd control pkts (Noraml bfd control pkts
for link connectivity )

 

Now 

 

A has sent normal bfd control pkt to B and immediately it changes its Tx
interval and therefore sends one more bfd control pkt with POLL bit set
n change of Min Tx interval. 

But B before processing the POLL bit received pkt sends its normal bfd
control pkt for link detection.(therefore this packet will not have FIN
set)

Now A may conclude with the recived bfd normal control packet which does
not have FIN bit set as declined parameter 

 

All this is b'coz the after sending the POLL bit set packet , A assumes
the immediate received packet as response to the its POLL request. 

 

 





1.	If the choosen transport protocol for BFD transmission is UDP,
the FIN bit set packet is lost then there will be discrepancy the
configuration between the configured nodes.

This is why the poll is sent repeatedly until a final is heard.

 

Node A                                     Node B

 

Bfd    -----Session State UP-----   Bfd (session up n running on both
nodes, with mandatory mode, Asynch)

 

Bfd control pkts  <----------> Bfd control pkts (Noraml bfd control pkts
for link connectivity )

 

Now 

 

Node A sends the POLL bit set packet chaning its Tx interval, Node B
agrees to the change and sedns its FIN bit set packet, and changes its
Rx interval with the larger of the its Rx and received Tx. But the bfd
packet from B to Node A can lost so , Node A keeps sending the POLL bit
set packet but Node B has already changed its Rx interval, which Node A
is not aware of b'coz of the FIN packet loss.

 

 

--Dave