Re: Echo Function and Asymmetry - Timer negotiation

Reshad Rahman <rrahman@cisco.com> Fri, 12 August 2005 00:50 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Nkx-0001cg-Av; Thu, 11 Aug 2005 20:50:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Nkw-0001cb-FT for rtg-bfd@megatron.ietf.org; Thu, 11 Aug 2005 20:50:42 -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 UAA09355 for <rtg-bfd@ietf.org>; Thu, 11 Aug 2005 20:50:41 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3OJJ-0006xC-VJ for rtg-bfd@ietf.org; Thu, 11 Aug 2005 21:26:16 -0400
Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 11 Aug 2005 17:50:30 -0700
X-IronPort-AV: i="3.96,101,1122879600"; d="scan'208"; a="331506186:sNHT30529336"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7C0oM0L002937; Thu, 11 Aug 2005 17:50:26 -0700 (PDT)
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Aug 2005 20:50:25 -0400
Received: from [192.168.1.102] ([10.86.240.185]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Aug 2005 20:50:24 -0400
Message-ID: <42FBF24F.3070909@cisco.com>
Date: Thu, 11 Aug 2005 20:50:23 -0400
From: Reshad Rahman <rrahman@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dave Katz <dkatz@juniper.net>
References: <B6D0BC3B6B7DEA43ADAB00368CF984FA84BCC4@xmb-sjc-213.amer.cisco.com> <5C78DA20-7FFA-41BB-BBC7-54B165751EDD@juniper.net>
In-Reply-To: <5C78DA20-7FFA-41BB-BBC7-54B165751EDD@juniper.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 Aug 2005 00:50:24.0818 (UTC) FILETIME=[D32F5920:01C59ED7]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Content-Transfer-Encoding: 7bit
Cc: rtg-bfd@ietf.org
Subject: Re: Echo Function and Asymmetry - Timer negotiation
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

Dave Katz wrote:

>
> On Aug 11, 2005, at 1:58 PM, Tanya Shastri ((tanyas)) wrote:
>
>>  
>> For an Asynchronous BFD session that has Asymmetric Echo function the 
>> following statements in the spec seem to be misleading, unless I am 
>> missing something.
>>  
>> Section 6.4 says: "When a system is using the Echo function, it is 
>> advantageous to choose a sedate transmission rate for Control packets 
>> since liveness detection is being handled by the Echo packets."
>> Shouldn't it be the receive rate - or the transmission rate of 
>> Control packets of the remote system - that should be sedate? Also 
>> the end that does not have echo mode active relies on Control packets 
>> for liveness detection and may still want to receive Control packets 
>> at a faster rate.
>
>
> Yes, the language is a little slippery.  It dates from a time in BFD 
> prehistory when echo mode had to be symmetric, and the use of 
> "transmission rate" was meant to be generic, that is, the packet 
> rate.  As you note, in the asymmetric case, the guy not running echo 
> mode may like to be receiving control packets at a faster rate.
>
It's not clear to me what's the benefit of doing this if the asymmetric 
echo is being run at fast rate. Failure in any direction will be 
detected by the asymmetric echo and the other end (which isn't running 
echo) will be notified on echo failure. So it's not clear to me what's 
the benefit of the the guy not running echo to be receiving control 
packets at a faster rate. It would seem that with asymmetric echo we can 
still run control packets at a sedate rate in both directions. Or am I 
missing something?

Regards,
Reshad.

>>  
>> Section 6.7.3 says: " When the Echo function is active, a system 
>> SHOULD set bfd.DesiredMinTxInterval to a value of not less than one 
>> second"
>> From the description in 6.7.4 this will force the remote end to have 
>> a Detect Timer no faster than 1 second, since the Detect Timer is 
>> based on the transmit rate of the remote system. Also this will not 
>> reduce the rate at which it sends control packets to the end that has 
>> echo mode active.
>>  
>> Wouldn't it be better to suggest that "RequiredMinRxInterval" in BFD 
>> control packets should be set to a minimum of 1 second by the end 
>> that has echo function active?
>
>
> Same issue, but you're right.  I'll fix it in the next round.
>
> --Dave
>