Re: a draft about how BFD notifying the state change to applications

Jeffrey Haas <jhaas@nexthop.com> Wed, 24 August 2005 17:45 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zJO-0006UG-2q; Wed, 24 Aug 2005 13:45:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zJM-0006U3-0H for rtg-bfd@megatron.ietf.org; Wed, 24 Aug 2005 13:45:16 -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 NAA07836 for <rtg-bfd@ietf.org>; Wed, 24 Aug 2005 13:45:11 -0400 (EDT)
Received: from gateout01.mbox.net ([165.212.64.21] helo=gwo1.mbox.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7zJb-00015a-Tr for rtg-bfd@ietf.org; Wed, 24 Aug 2005 13:45:35 -0400
Received: from gateout01.mbox.net (gateout01.mbox.net [165.212.64.21]) by gwo1.mbox.net (Postfix) with SMTP id 0B07312DC63 for <rtg-bfd@ietf.org>; Wed, 24 Aug 2005 17:44:29 +0000 (GMT)
Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.17K) with ESMTP id 317JHXRSb0094Mo1; Wed, 24 Aug 2005 17:44:28 GMT
Received: from gateout01.mbox.net [127.0.0.1] by gateout01.mbox.net via mtad (C8.MAIN.3.17K) with ESMTP id 314JHXRSA0094Mo1; Wed, 24 Aug 2005 17:44:26 GMT
X-USANET-Routed: 2 gwsout-vs R:localhost:1825
Received: from gw3.EXCHPROD.USA.NET [165.212.116.254] by gateout01.mbox.net via smtad (C8.MAIN.3.21U); Wed, 24 Aug 2005 17:44:26 GMT
X-USANET-Source: 165.212.116.254 IN jhaas@nexthop.com gw3.EXCHPROD.USA.NET
X-USANET-MsgId: XID002JHXRSA6754Xo1
Received: from localhost ([65.247.36.31]) by gw3.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 Aug 2005 11:44:26 -0600
Date: Wed, 24 Aug 2005 13:44:25 -0400
From: Jeffrey Haas <jhaas@nexthop.com>
To: rtg-bfd@ietf.org
Message-ID: <20050824174425.GP18869@nexthop.com>
References: <B5E87B043D4C514389141E2661D255EC0A835B85@i2km41-ukdy.domain1.systemhost.net> <001901c5a8b3$e7c1d760$6607fea9@qingyuan64202>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <001901c5a8b3$e7c1d760$6607fea9@qingyuan64202>
User-Agent: Mutt/1.4.2.1i
X-OriginalArrivalTime: 24 Aug 2005 17:44:26.0440 (UTC) FILETIME=[78931C80:01C5A8D3]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
Subject: Re: a draft about how BFD notifying the state change to applications
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 Wed, Aug 24, 2005 at 09:57:24PM +0800, Yang Pingan wrote:
> And another purpose of WTR  is that: before BFD notifying forwarding engine,

I think this is one of the key phrases.

BFD need not "notify the forwarding engine".  One's system can be designed
to notify whatever component is appropriate.

The raw "session transitioned up", "session transitioned down" events
can be passed to whatever component you like.  If you wish to damp
behavior of those applications, you could apply your mechanism
and provide an intermediate layer between BFD and your application.

I wonder, based on your example, whether or not a different use of
BFD may be more appropriate.  If you're using BFD in conjuction
with some sort of failover/high availability mechanism, you have
two pieces of information that you are concerned about:

 - If you are verifying connectivity to a given instance of some
   application.
 - You are verifying that forwarding works to this instance.

To give a more concrete example, if you are using BFD for static
routes where the nexthop is a nexthop managed by VRRP, there may
be a forwarding failure to the nexthop.  At some point determined
by VRRP configuration and state, another VRRP host will take over.

If, in this example, you wished to monitor forwarding, BFD to the
VRRP nexthop may be appropriate.  However, the timers probably should
be such that the BFD timeout is higher than the VRRP failover time.

If you wish to monitor a given VRRP host, your BFD session should
be to an address other than the VRRP virtual address.

My apologies if this example misses your point.


-- 
Jeff Haas 
NextHop Technologies