BFD echo mode interoperability

richard.spencer@bt.com Wed, 22 June 2005 13:44 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl5XH-0006bI-IL; Wed, 22 Jun 2005 09:44:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl5XF-0006YG-Kk for rtg-bfd@megatron.ietf.org; Wed, 22 Jun 2005 09:44:57 -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 JAA10594 for <rtg-bfd@ietf.org>; Wed, 22 Jun 2005 09:44:54 -0400 (EDT)
From: richard.spencer@bt.com
Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl5vM-00008v-Gl for rtg-bfd@ietf.org; Wed, 22 Jun 2005 10:09:53 -0400
Received: from i2km98-ukbr.domain1.systemhost.net ([193.113.197.85]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Jun 2005 14:43:42 +0100
Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km98-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 22 Jun 2005 14:43:37 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 22 Jun 2005 14:42:45 +0100
Message-ID: <B5E87B043D4C514389141E2661D255EC0A835A5F@i2km41-ukdy.domain1.systemhost.net>
Thread-Topic: BFD echo mode interoperability
Thread-Index: AcV3L9Wb+5UEN0LhTg2AcwFAkbJV3Q==
To: rtg-bfd@ietf.org
X-OriginalArrivalTime: 22 Jun 2005 13:43:37.0746 (UTC) FILETIME=[64751F20:01C57730]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Content-Transfer-Encoding: quoted-printable
Subject: BFD echo mode interoperability
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

Colleagues,

I've been looking at the BFD base draft and am struggling to understand how interoperable BFD solutions can be developed using echo mode.

The draft states "The means by which the Echo function failures are detected is outside of the scope of this specification. Any means which will detect a communication failure is acceptable." The draft also states "A means of detecting missing Echo packets must be implemented, which most likely involves processing of the Echo packets that are received. The processing of received Echo packets is otherwise outside the scope of this specification."

This is in contrast to the asynchronous mode which uses the detect multiplier to define how many consecutive packets must be missed in order to declare a session down. I have seen an implementation that uses the detect multiplier for echo packets as well as control packets, but this behaviour is not specified in the draft.

If two vendors decide to use different methods/settings for fault detection using echo mode, this will be a real pain to configure/manage, and will also require translation between different methods in order to ensure symmetry in detecting failures in order to avoid black holing traffic.

Unless I've missed something, using echo mode in a multivendor environment does not look like an attractive solution.

Regards,
Richard