Re: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-00.txt

Naiming Shen <naiming@cisco.com> Thu, 05 April 2007 08:28 UTC

Return-path: <rtg-bfd-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZNKl-0004U6-9z; Thu, 05 Apr 2007 04:28:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZNKk-0004Ty-UV for rtg-bfd@ietf.org; Thu, 05 Apr 2007 04:28:42 -0400
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 1HZNKj-0001hW-KW for rtg-bfd@ietf.org; Thu, 05 Apr 2007 04:28:42 -0400
Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 05 Apr 2007 01:28:42 -0700
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l358Sebw007343; Thu, 5 Apr 2007 01:28:40 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l358SeMF018082; Thu, 5 Apr 2007 08:28:40 GMT
Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 01:28:40 -0700
Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Apr 2007 01:28:40 -0700
In-Reply-To: <5EB31780BD297F46812C8F495FA08F620B9E952D@electron.jnpr.net>
References: <5EB31780BD297F46812C8F495FA08F620B9E952D@electron.jnpr.net>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <B55F0243-EF9D-4E97-9299-921AF3FADB08@cisco.com>
Content-Transfer-Encoding: 7bit
From: Naiming Shen <naiming@cisco.com>
Date: Thu, 05 Apr 2007 01:28:37 -0700
To: Nitin Bahadur <nitinb@juniper.net>
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 05 Apr 2007 08:28:40.0475 (UTC) FILETIME=[6A2366B0:01C7775C]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1188; t=1175761721; x=1176625721; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=naiming@cisco.com; z=From:=20Naiming=20Shen=20<naiming@cisco.com> |Subject:=20Re=3A=20I-D=20ACTION=3Adraft-shen-bfd-intf-p2p-nbr-00.txt |Sender:=20; bh=/fWQIXnkPQ5xwQSkHvX4FlojH8MGxPZqt6VqZY2lgrI=; b=GFMcntDJX2J6G1+WxDXF3lPF0ZQJ35i8mOZploEyaCopyGk0BOdMsr8KVguyU7QKhqE+MByb pYSc6S8r3oLiITHYc5hkTbBNGR8AYd12GYNRvjRcAUJTfYFvEGc6N0Ee;
Authentication-Results: sj-dkim-2; header.From=naiming@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: rtg-bfd@ietf.org
Subject: Re: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-00.txt
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>
Errors-To: rtg-bfd-bounces@ietf.org

On Apr 3, 2007, at 3:41 PM, Nitin Bahadur wrote:

>
>
>>> Also, with the draft you are tying in the concept of a link failure
> to a
>>> bfd session failure...which might not necessarily be true. BFD
> sessions
>>> might fail due to firewall filters, IP packet handling errors. You
> would
>>> need more tools to tell the customer/operator that the link is
> *actually
>>> not down* and it's BFD that has marked the link as down.
>>
>> to be honest, generate an meaningful error message saying 'intf-p2p
> bfd
>> brought down intf' will probably do for most of the customers.
>
> I would be happy if you can note in the draft that the bfd session
> failure does not necessarily mean that the physical link/ 
> connectivity is
> down and bfd should not be used in place of link-layer OAM mechanisms.

For the first one, I can add that it does not mean the physical link  
has to
be down; the second one, this draft does not claim to replace the OAM
functionality. this draft is only trying to be the BFD with a simple  
scheme.

thanks.
- Naiming

>
> Comments by Dave Katz & Tom Nadeau seem to have addressed all other
> issues.
>
> Thanks
> Nitin