IETF Logo Mail Archive

Re: BFD stability follow-up from IETF-91

"MALLIK MUDIGONDA (mmudigon)" <mmudigon@cisco.com> Fri, 28 November 2014 12:52 UTC

Return-Path: <mmudigon@cisco.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56FAD1A1AD3 for <rtg-bfd@ietfa.amsl.com>; Fri, 28 Nov 2014 04:52:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9F6_HiBrFD1z for <rtg-bfd@ietfa.amsl.com>; Fri, 28 Nov 2014 04:52:01 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F4AF1A1B49 for <rtg-bfd@ietf.org>; Fri, 28 Nov 2014 04:51:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14902; q=dns/txt; s=iport; t=1417179118; x=1418388718; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=xXO0UYWVqavq4Q9SXGR4jBmNhtjwk+FW/vzQ1XM/QWw=; b=DKi16wkB98Zs4yqC8SY1hQOPSm0zoNMgo4jUzZEIn2d3Xuhm1MXTigJy hrjfoEeGpqMCbg59Or5IPfBsdz+KSmN3ThJirwc9uItsGWIdfSvujbgNN XpSoU8ICfpzXJf3gNTxBxSLkUNenBW22vIjKa5B48kCyci3QFzw3M33YG Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsFADBveFStJA2M/2dsb2JhbABbgkJEUVzFFYh1AoEOFgEBAQEBfYQCAQEBBC1eAQgRAwEBASgmExQJCAIEARKIQNItAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5BXExcBAoRLBZA5giwFjBeXHIN8b4FIgQIBAQE
X-IronPort-AV: E=Sophos;i="5.07,476,1413244800"; d="scan'208,217";a="372872472"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-1.cisco.com with ESMTP; 28 Nov 2014 12:51:57 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id sASCpuwm012347 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Nov 2014 12:51:56 GMT
Received: from xmb-rcd-x05.cisco.com ([169.254.15.81]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Fri, 28 Nov 2014 06:51:56 -0600
From: "MALLIK MUDIGONDA (mmudigon)" <mmudigon@cisco.com>
To: "Fan, Peng" <fanpeng@chinamobile.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: BFD stability follow-up from IETF-91
Thread-Topic: BFD stability follow-up from IETF-91
Thread-Index: AQHQCQ6sKG4KnHULdkO3SoZYWD6QxJxy3ruAgAAfxICAAAeWAIAAjSQAgAD7mQCAAEe3gIABbj+AgABtsgD//68zAIAAYSuA
Date: Fri, 28 Nov 2014 12:51:56 +0000
Message-ID: <D09E6DA9.27C62%mmudigon@cisco.com>
In-Reply-To: <007e01d00b07$9c02cc10$d4086430$@chinamobile.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.50.65]
Content-Type: multipart/alternative; boundary="_000_D09E6DA927C62mmudigonciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/0U9KMMquBsLwzUSdeu35ILlXXCM
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Nov 2014 12:52:03 -0000

Thanks Peng.

Regards
Mallik

From: <Fan>, Peng <fanpeng@chinamobile.com<mailto:fanpeng@chinamobile.com>>
Date: Friday, 28 November 2014 6:04 pm
To: Cisco Employee <mmudigon@cisco.com<mailto:mmudigon@cisco.com>>, "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>
Subject: RE: BFD stability follow-up from IETF-91

Hi Mallik,

Exactly. Packets may be experiencing slight loss, but the link can hardly be regarded as connected. More importantly, the experience of upper-level applications can be degraded severely (e.g. TCP traffic is not able to go fast in face of even small continuous loss). But what if one BFD frame is lost every three frames? Then the loss rate is 30% on average, which is already a very severe value.

Best regards,
Peng

From: MALLIK MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com]
Sent: Friday, November 28, 2014 7:53 PM
To: Fan, Peng; rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: Re: BFD stability follow-up from IETF-91

Hi Peng,

If the BFD packets are lost, doesn’t the BFD session go DOWN? Are you saying that packet loss is not big enough to make BFD session go DOWN?

Thanks

Regards
Mallik

From: <Fan>, Peng <fanpeng@chinamobile.com<mailto:fanpeng@chinamobile.com>>
Date: Friday, 28 November 2014 4:20 pm
To: "rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>" <rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>>
Subject: RE: BFD stability follow-up from IETF-91

Hi Jeff, all,

I have been following this stability extension from the beginning, and as an
operator I would like to express that this draft enables the "advanced
feature" we desire for BFD to provide additional useful information that
helps operators understand network issues. A relevant use case is detecting
lossy or "quasi-disconnected" links or member LAG links. An example of such
situation we experienced was a loosely connected fiber link resulting in
continuous, small amount of packet loss. BFD could get the information of
lost BFD frames on such unstable link, and probably report when a target
level is reached, say a certain number of frames are lost over a period or
among a total number of frames.

Best regards,
Peng

v2.23.0 | Report a Bug | By Email