IETF Logo Mail Archive

RE: BFD stability follow-up from IETF-91

"Fan, Peng" <fanpeng@chinamobile.com> Fri, 28 November 2014 12:34 UTC

Return-Path: <fanpeng@chinamobile.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 349851A1B47 for <rtg-bfd@ietfa.amsl.com>; Fri, 28 Nov 2014 04:34:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.312
X-Spam-Level:
X-Spam-Status: No, score=0.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 fT2sMrFItCO8 for <rtg-bfd@ietfa.amsl.com>; Fri, 28 Nov 2014 04:34:49 -0800 (PST)
Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with SMTP id 73E4B1A1AFB for <rtg-bfd@ietf.org>; Fri, 28 Nov 2014 04:34:47 -0800 (PST)
Received: from spf.mail.chinamobile.com (unknown[172.16.121.17]) by rmmx-syy-dmz-app03-12003 (RichMail) with SMTP id 2ee354786bde498-249a5; Fri, 28 Nov 2014 20:34:39 +0800 (CST)
X-RM-TRANSID: 2ee354786bde498-249a5
X-RM-SPAM-FLAG: 00000000
Received: from cmccPC (unknown[223.69.29.130]) by rmsmtp-syy-appsvr09-12009 (RichMail) with SMTP id 2ee954786bdfb77-7acae; Fri, 28 Nov 2014 20:34:39 +0800 (CST)
X-RM-TRANSID: 2ee954786bdfb77-7acae
From: "Fan, Peng" <fanpeng@chinamobile.com>
To: "'MALLIK MUDIGONDA (mmudigon)'" <mmudigon@cisco.com>, rtg-bfd@ietf.org
References: <007701d00af9$28719050$7954b0f0$@chinamobile.com> <D09E5FAC.27C51%mmudigon@cisco.com>
In-Reply-To: <D09E5FAC.27C51%mmudigon@cisco.com>
Subject: RE: BFD stability follow-up from IETF-91
Date: Fri, 28 Nov 2014 20:34:08 +0800
Message-ID: <007e01d00b07$9c02cc10$d4086430$@chinamobile.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_007F_01D00B4A.AA287D10"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQK7LgWhTxiY1ngk8SuipszYBU4dopqfrnhg
Content-Language: zh-cn
Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/YkiMCBfhQ2CBoQn8FjY2N3KcupQ
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:34:53 -0000

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
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>
Date: Friday, 28 November 2014 4:20 pm
To: "rtg-bfd@ietf.org" <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