RE: BFD stability follow-up from IETF-91

Gregory Mirsky <gregory.mirsky@ericsson.com> Fri, 28 November 2014 19:36 UTC

Return-Path: <gregory.mirsky@ericsson.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 7DCBF1A0149 for <rtg-bfd@ietfa.amsl.com>; Fri, 28 Nov 2014 11:36:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.2
X-Spam-Level:
X-Spam-Status: No, score=-104.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 qDBR-Z43fbzC for <rtg-bfd@ietfa.amsl.com>; Fri, 28 Nov 2014 11:36:51 -0800 (PST)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADC5D1A0126 for <rtg-bfd@ietf.org>; Fri, 28 Nov 2014 11:36:50 -0800 (PST)
X-AuditID: c6180641-f79916d00000623a-f1-547872d5d508
Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 85.0B.25146.5D278745; Fri, 28 Nov 2014 14:04:21 +0100 (CET)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0195.001; Fri, 28 Nov 2014 14:36:31 -0500
From: Gregory Mirsky <gregory.mirsky@ericsson.com>
To: "Fan, Peng" <fanpeng@chinamobile.com>, "'MALLIK MUDIGONDA (mmudigon)'" <mmudigon@cisco.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: AQHQCQ6qQ6amXjPuFEmbPIOgLl4p2pxyzfeAgAAfxYCAAAeVAIAAjSUAgAD7mQCAAEe3gIABbj6AgAARfwCAAAtmAIAAF9Pg
Date: Fri, 28 Nov 2014 19:36:30 +0000
Message-ID: <7347100B5761DC41A166AC17F22DF1121B8998E7@eusaamb103.ericsson.se>
References: <007701d00af9$28719050$7954b0f0$@chinamobile.com> <D09E5FAC.27C51%mmudigon@cisco.com> <007e01d00b07$9c02cc10$d4086430$@chinamobile.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: [147.117.188.12]
Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B8998E7eusaamb103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyuXRPoO7VoooQg5bTOhbrG16wWxx5dYzZ 4vOfbYwOzB7zLixk85jyeyOrx5IlP5kCmKO4bFJSczLLUov07RK4Mi5eu8lS8KuXseL5BtUG xp31XYycHBICJhLfXn5ghrDFJC7cW8/WxcjFISRwhFHixtpFUM5yRolt9+eyg1SxCRhJvNjY ww6SEBHoYJRY+nIpWLuwgKHEqu7FYEUiQEXHZsyFsvMk1uz4zwJiswioSvTtmAtkc3DwCvhK HDhQCrFgOqNEy5U2sBpOATuJJ12zmUBsRqCTvp9aA2YzC4hL3HoynwniVAGJJXvOQ50tKvHy 8T9WCFtJYs7ra8wQ9fkSp+dOAovzCghKnJz5hGUCo8gsJKNmISmbhaQMIq4jsWD3JzYIW1ti 2cLXzDD2mQOPmZDFFzCyr2LkKC1OLctNNzLcxAiMqmMSbI47GBd8sjzEKMDBqMTD+2FNeYgQ a2JZcWXuIUZpDhYlcV7N6nnBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgl7FJK6qVusim3 pR6NuHS8OSR77e2naQe99t2uFPpzSuzzhqzwxyxT5mgFP85/Gdede/l38bs/+xa+X/rp4fQj DdFPfB9dc24V/H5fziitYqXW3EfrNn09W1r2pOX0y+jVGYJcwlkqcnw+nNMt3m1X9XCd62Nj GxNxp+ngRckns6ZpbIjfIZmixFKckWioxVxUnAgA5OrXeosCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/u0--Llp4WHZsJls2lUA9VWR4WW8
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 19:37:00 -0000

Hi Peng,
this is very interesting scenario. I think that if BFD experiences ~30% packet loss, then highly likely so are affected other applications. Then it is not just BFD issue but condition that should be detected  by performance measurement method, whether active or passive packet loss measurement.
I'm convinced that overloading BFD with performance measurement provisions is counter-productive and is inappropriate.

                Regards,
                                Greg

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Fan, Peng
Sent: Friday, November 28, 2014 4:34 AM
To: 'MALLIK MUDIGONDA (mmudigon)'; 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