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

"Nitin Bahadur" <nitinb@juniper.net> Tue, 03 April 2007 22:41 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 1HYrhL-0004IF-IV; Tue, 03 Apr 2007 18:41:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYrhJ-0004Gr-Ux for rtg-bfd@ietf.org; Tue, 03 Apr 2007 18:41:53 -0400
Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYrhI-0000k8-Mg for rtg-bfd@ietf.org; Tue, 03 Apr 2007 18:41:53 -0400
Received: from unknown (HELO emailsmtp55.jnpr.net) ([172.24.18.132]) by borg.juniper.net with ESMTP; 03 Apr 2007 15:41:53 -0700
X-IronPort-AV: i="4.14,366,1170662400"; d="scan'208"; a="701937732:sNHT30851900"
Received: from electron.jnpr.net ([172.24.15.21]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 15:41:52 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 03 Apr 2007 15:41:51 -0700
Message-ID: <5EB31780BD297F46812C8F495FA08F620B9E952D@electron.jnpr.net>
In-Reply-To: <460DA338.4020505@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: I-D ACTION:draft-shen-bfd-intf-p2p-nbr-00.txt
Thread-Index: AcdzJtORCHReh25UQ9Cofjd/BWDyegDGU12A
From: Nitin Bahadur <nitinb@juniper.net>
To: Naiming Shen <naiming@cisco.com>
X-OriginalArrivalTime: 03 Apr 2007 22:41:52.0403 (UTC) FILETIME=[46143630:01C77641]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
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


> > 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.

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

Thanks
Nitin