Re: BFD queries

Dave Katz <dkatz@juniper.net> Tue, 25 October 2005 08:11 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUJuQ-0004D7-9R; Tue, 25 Oct 2005 04:11:50 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUJuO-0004D2-8N for rtg-bfd@megatron.ietf.org; Tue, 25 Oct 2005 04:11:48 -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 EAA28928 for <rtg-bfd@ietf.org>; Tue, 25 Oct 2005 04:11:33 -0400 (EDT)
Received: from www8.cruzio.com ([63.249.95.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUK7J-0002CP-1n for rtg-bfd@ietf.org; Tue, 25 Oct 2005 04:25:09 -0400
Received: from [172.16.12.139] (pcp08543197pcs.sntafe01.nm.comcast.net [68.35.73.229]) by www8.cruzio.com with ESMTP id j9P8BjbV079543; Tue, 25 Oct 2005 01:11:45 -0700 (PDT)
In-Reply-To: <BD6DEA8C77182E4586B6BE33532EA48D38CC0C@HYD-MKD-MBX01.wipro.com>
References: <BD6DEA8C77182E4586B6BE33532EA48D38CC0C@HYD-MKD-MBX01.wipro.com>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: multipart/alternative; boundary=Apple-Mail-2--550640380
Message-Id: <C22051C0-A873-4884-99AD-EF84C2835DA7@juniper.net>
From: Dave Katz <dkatz@juniper.net>
Date: Tue, 25 Oct 2005 02:11:38 -0600
To: kalpana.yenishetti@wipro.com
X-Mailer: Apple Mail (2.734)
X-Spam-Score: 0.6 (/)
X-Scan-Signature: a0534e6179a1e260079328e8b03c7901
Cc: rtg-bfd@ietf.org
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

On Oct 25, 2005, at 12:23 AM, kalpana.yenishetti@wipro.com wrote:

>
> 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

I'm not sure what you mean by "declined parameter," there is no such  
thing.  Parameters in BFD are not "negotiated" in the normal way;   
rather, each side announces its timing parameters and the other side  
MUST obey them (and choose the largest value of each pair, e.g. my TX  
and your RX.)
>
>
> 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.

There is no such thing as a "response" in BFD, except for a packet  
with Final in response to a Poll.  If A sends a Poll and B sends a  
Final in response and there were other packets in the pipeline, that  
are received before the Final, it makes no difference.  A will  
process them as normal and wait to implement its parameter changes  
until it sees the Final.
>
> 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.

There is no "agreeing" in BFD.  All parameters changes are mandatory  
and unilateral.  This gives each system full control over both the  
transmit and receive load (of BFD packets.)

In this case, assuming A is increasing its TX interval, B will  
increase the detection time in response to the change, but A will  
continue to transmit at the earlier, more rapid rate, and will  
continue to send packets with Poll.  Eventually one of the Finals  
will get through and A will slow down its transmission rate.  The  
procedures are designed to avoid accidentally having a session  
failure because one side slowed down its transmission rate before the  
other increased the detection time.  There is no harm in sending  
packets too often (within the offered RX limit, of course.)

--Dave