Re: Echo Function and Asymmetry - Timer negotiation

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

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Zfa-0001Nv-1l; Fri, 12 Aug 2005 09:33:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3ZfX-0001Nn-69 for rtg-bfd@megatron.ietf.org; Fri, 12 Aug 2005 09:33:56 -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 JAA22030 for <rtg-bfd@ietf.org>; Fri, 12 Aug 2005 09:33:52 -0400 (EDT)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3aE3-0000zl-GQ for rtg-bfd@ietf.org; Fri, 12 Aug 2005 10:09:36 -0400
Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 12 Aug 2005 06:33:46 -0700
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7CDXOp6006687; Fri, 12 Aug 2005 06:33:43 -0700 (PDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Aug 2005 09:33:40 -0400
Received: from [192.168.1.102] ([10.86.240.185]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 12 Aug 2005 09:33:39 -0400
Message-ID: <42FCA532.9010807@cisco.com>
Date: Fri, 12 Aug 2005 09:33:38 -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: richard.spencer@bt.com
References: <B5E87B043D4C514389141E2661D255EC0A835B50@i2km41-ukdy.domain1.systemhost.net>
In-Reply-To: <B5E87B043D4C514389141E2661D255EC0A835B50@i2km41-ukdy.domain1.systemhost.net>
Content-Type: multipart/alternative; boundary="------------030001060409020808020103"
X-OriginalArrivalTime: 12 Aug 2005 13:33:40.0079 (UTC) FILETIME=[73499FF0:01C59F42]
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
Cc: rtg-bfd@ietf.org, dkatz@juniper.net
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

Richard,

Thanks for the response, makes sense. So in the example below where only 
A is using echo mode, this means that A will be sending control and echo 
packets at a fast rate and B will be sending control packets at the 
sedate rate? If that's the case all the tx burden will be on A, 
asymmetric echo doesn't seem fair...

Regards,
Reshad.

richard.spencer@bt.com wrote:

>Reshad,
>
>  
>
>>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?
>>    
>>
>
>The problem is that you are assuming the system not running echo mode will always be notified of a failure. Lets say we have a BFD session between two systems A and B, echo mode is active on system A, but system B is just using asynchronous mode. If there is a unidirectional failure in the direction B->A, system A will detect the failure and will send a BFD control packet to B indicating that there is a failure. In this scenario, both system A and system B will be aware of the failure.
>
>However, if there is a unidirectional failure in the direction A->B, system A will detect the failure and will send a BFD control packet to B indicating that there is a failure. This is where the problem lies, system B will not receive the BFD control packet because the failure is in the direction A->B, and therefore B will not detect the failure until it's asynchronous timer has timed out. Similarly, if there is a bi-directional failure, system A will detect the failure and will send a BFD control packet to B indicating that there is a failure, but again system B will not receive the failure notification.
>
>I personally don't like echo mode as an always on fault detection mechanism for a number of reasons:
>
>1. Echo mode does not provide any indication of the direction/location of the failure, it could be in the direction A->B, B->A, or it could be a forwarding plane failure in the remote system.
>2. To support symmetric failure detection times, echo mode requires twice as many packets to be transmitted/received as asynchronous mode does if active on both systems, and 50% more if active on just one system.
>3. The draft does not define exactly how a failure is detected in echo mode, therefore vendors may use different methods/settings for fault detection using echo mode. In a multi-vendor environment, this may require translation between different methods/settings in order to ensure symmetry in detecting failures (if they are actually user configurable), which adds management/operational complexity.
>4. Failure detection times using echo mode are more susceptible to variations due to the packets being looped back, i.e. [downstream propagation delay + far end switching delay + upstream propagation delay] vs. [one way propagation delay].
>
>I would compare BFD asynchronous mode to the use of continuity check (CC) cells and echo mode to the use of loopback cells in ATM. In general, loopback tests are useful as on demand tests for diagnosing faults (e.g. for locating a fault), but are not suitable as always on fault detection mechanisms.
>
>Regards,
>Richard
>  
>