IETF Logo Mail Archive

RE: TWAMP analysis for assisting BFD debuggin (was Re: BFD stability follow-up from IETF-91)

Gregory Mirsky <gregory.mirsky@ericsson.com> Mon, 22 December 2014 06:46 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 7DC211A89BB for <rtg-bfd@ietfa.amsl.com>; Sun, 21 Dec 2014 22:46:36 -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 MZg1WGx12H-0 for <rtg-bfd@ietfa.amsl.com>; Sun, 21 Dec 2014 22:46:34 -0800 (PST)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C3FC1A89B8 for <rtg-bfd@ietf.org>; Sun, 21 Dec 2014 22:46:34 -0800 (PST)
X-AuditID: c618062d-f79376d000000ceb-ee-54976d4792db
Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 1F.D1.03307.74D67945; Mon, 22 Dec 2014 02:00:55 +0100 (CET)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0195.001; Mon, 22 Dec 2014 01:46:27 -0500
From: Gregory Mirsky <gregory.mirsky@ericsson.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Subject: RE: TWAMP analysis for assisting BFD debuggin (was Re: BFD stability follow-up from IETF-91)
Thread-Topic: TWAMP analysis for assisting BFD debuggin (was Re: BFD stability follow-up from IETF-91)
Thread-Index: AQHQG88XebvdVz4lWEyU7mFsO07GX5yXbPxAgAPrgID//9G68A==
Date: Mon, 22 Dec 2014 06:46:26 +0000
Message-ID: <7347100B5761DC41A166AC17F22DF1121B8C6959@eusaamb103.ericsson.se>
References: <00a001d00d64$7735ce50$65a16af0$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8A87E6@eusaamb103.ericsson.se> <730769BB-D021-4E22-878A-2C289822A156@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AA754@eusaamb103.ericsson.se> <09CD6B2F-4DCC-429F-848B-223C72A0F171@gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AAA24@eusaamb103.ericsson.se> <CO2PR0501MB8231A4913DEB31323847CA8B3780@CO2PR0501MB823.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B8AAC0D@eusaamb103.ericsson.se> <CAG1kdoiquWYaAz5ti14VrmiqXmph-SpjgYs=m8AuQGdKGo2xXQ@mail.gmail.com> <7347100B5761DC41A166AC17F22DF1121B8AACDB@eusaamb103.ericsson.se> <20141219210222.GJ16279@pfrc> <7347100B5761DC41A166AC17F22DF1121B8C5EA0@eusaamb103.ericsson.se> <F81ED3EF-5818-45D8-9F5F-7CE8910B6B43@gmail.com>
In-Reply-To: <F81ED3EF-5818-45D8-9F5F-7CE8910B6B43@gmail.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_7347100B5761DC41A166AC17F22DF1121B8C6959eusaamb103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZXLonRNc9d3qIwd8FWhb7D75ltTj9Zh2b xec/2xgdmD12zrrL7rFkyU8mj8u9W1kDmKO4bFJSczLLUov07RK4Mqbfes9W0BZRcar5A1sD 44XQLkYODgkBE4mvH+y6GDmBTDGJC/fWs3UxcnEICRxhlJh4fB8jhLOcUWL2/HtMIFVsAkYS Lzb2sIPYIgKGEqcOvACLMwt4SPRt3c0GYgsLpEvMeHmCDaImQ2JPx3lWCNtJYvrq14wgNouA qsSJWRfBangFfCWureplgVi2ik3iybcbYAlOAVuJa/Ongy1gBDrv+6k1UMvEJW49mc8EcbaA xJI955khbFGJl4//sULYShJzXl9jhqjPlzg/C6KeV0BQ4uTMJywTGEVnIRk1C0nZLCRls4CB xCygKbF+lz5EiaLElO6H7BC2hkTrnLnsyOILGNlXMXKUFqeW5aYbGWxiBEbaMQk23R2Me15a HmIU4GBU4uHdIDE9RIg1say4MvcQozQHi5I476zaecFCAumJJanZqakFqUXxRaU5qcWHGJk4 OKUaGDNC39+Q+Kj0MElGLe37p4ii44efqH/vOrvfLVZdNbZi9pxmrmDZfcaS/dsOmP5KWdla ea+pw2/Ozw9rvi/8prHqol7dtB1KbOuLf6r37zshkPuU51+8yLG2o0KSDhGchlevBCkcK9Pc vHBlwdbi8qcJcT/3icUkBXdu2cpzwn3F8nSpjffla5RYijMSDbWYi4oTAYaz+lKVAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/OeRQEs9I0J9lREpB75siiAj2IP8
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
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: Mon, 22 Dec 2014 06:46:36 -0000

Hi Mahesh,
if you assume that BFD flap is more likely because of implementation or overloading system rather than because of network condition, then I’d like to understand how intermittent congestion in a source end-node can be differentiated from intermittent congestion in the network without PM. I’m not questioning value of improved debugability of an implementation, BFD in this case, but I’d prefer it not to have adverse impact on the protocol, on its ability to perform its main task most efficiently. Debugging, I believe, been and still is, proprietary, implementation specific. Problems you’ve described, I believe, unlikely to be experienced in HW based BFD implementation. Thus, what benefit, changes you propose, would bring for such implementations?

                Regards,
                                Greg

From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com]
Sent: Sunday, December 21, 2014 8:17 PM
To: Gregory Mirsky
Cc: Jeffrey Haas; rtg-bfd@ietf.org
Subject: Re: TWAMP analysis for assisting BFD debuggin (was Re: BFD stability follow-up from IETF-91)

Greg,

I do not think the issue we are trying to debug is of whether a BFD flap is a real defect or a false negative, but rather why did BFD flap. And that is the information that is not available by running other PM tools.

If you go back to my email from a few weeks ago, when I gave a customer scenario, you would remember I was talking about a BFD flap causing tunnel to switch over. This draft is attempting to explain to the customer why the tunnel switched over when it did. How would you explain to the customer the reason for a failover?

Mahesh Jethanandani
mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>

On Dec 19, 2014, at 2:52 PM, Gregory Mirsky <gregory.mirsky@ericsson.com<mailto:gregory.mirsky@ericsson.com>> wrote:
Whether Down state is indication of the real defect or false negative, that is the question to be answered through analysis of available information and follow-up with debugging and troubleshooting the BFD itself rather than the network if there are concerns that it was not a real defect.

v2.23.0 | Report a Bug | By Email