RE: BFD Admin-down

"Nitin Bahadur" <nitinb@juniper.net> Thu, 20 December 2007 21:52 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 1J5TJH-0008Uv-Dy; Thu, 20 Dec 2007 16:52:07 -0500
Received: from rtg-bfd by megatron.ietf.org with local (Exim 4.43) id 1J5TJG-0008OL-MJ for rtg-bfd-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 16:52:06 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5TJG-0008Hj-5K for rtg-bfd@ietf.org; Thu, 20 Dec 2007 16:52:06 -0500
Received: from exprod7og111.obsmtp.com ([64.18.2.175] helo=psmtp.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5TJF-0004Ca-Ib for rtg-bfd@ietf.org; Thu, 20 Dec 2007 16:52:06 -0500
Received: from source ([66.129.224.36]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Thu, 20 Dec 2007 13:51:58 PST
Received: from emailcorp1.jnpr.net ([66.129.254.11]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Dec 2007 13:52:00 -0800
Received: from emailcorp3.jnpr.net ([66.129.254.13]) by emailcorp1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Dec 2007 13:51:58 -0800
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C84351.979CFDCA"
Date: Thu, 20 Dec 2007 13:45:09 -0800
Message-ID: <7FA0C743C38E5340BFC2873488FA1E8E8B2296@emailcorp3.jnpr.net>
In-Reply-To: <e70833f50712201108v284939bqed11a315a0fbda76@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: BFD Admin-down
Thread-Index: AchDPUjPUq3yzcPwRjClq5iNkuNHnwAEwF5w
References: <e70833f50712201108v284939bqed11a315a0fbda76@mail.gmail.com>
From: Nitin Bahadur <nitinb@juniper.net>
To: Jagrati Shringi <shringi@gmail.com>, rtg-bfd@ietf.org
X-OriginalArrivalTime: 20 Dec 2007 21:51:58.0672 (UTC) FILETIME=[8B7DDD00:01C84352]
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba
Cc:
Subject: RE: BFD Admin-down
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

It would be nice if one would transmit packets for at least 1
detection-time period before ceasing 

packet transmission. One detection-time worth of packets would ensure
that the peer either receives

a packet (with correct diag) within that period or the peer times out
(as it would have done normally).

 

Nitin

 

My question is, this seem to be the only case in BFD where we will not
be able to maintain correct diagnostic on remote end, in case the packet
carrying this information is dropped. If the peer does not receive this
packet, it will move to down-state with Diag :Control Detection Time
Expired, instead of Neighbor Signaled Session Down. 
  
Please let me know what is the recommended approach in this case, so
that we maintain right state/diag code on peer, even if we loose some
packets.