RE: BFD stability follow-up from IETF-91

Gregory Mirsky <gregory.mirsky@ericsson.com> Mon, 08 December 2014 06:35 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 C06211A6F67 for <rtg-bfd@ietfa.amsl.com>; Sun, 7 Dec 2014 22:35:40 -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 1ATD7s9eO-Mp for <rtg-bfd@ietfa.amsl.com>; Sun, 7 Dec 2014 22:35:37 -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 3DAA61A6F64 for <rtg-bfd@ietf.org>; Sun, 7 Dec 2014 22:35:37 -0800 (PST)
X-AuditID: c618062d-f79376d000000ceb-5e-5484f674689a
Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 9B.5B.03307.476F4845; Mon, 8 Dec 2014 01:53:08 +0100 (CET)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 01:35:35 -0500
From: Gregory Mirsky <gregory.mirsky@ericsson.com>
To: Manav Bhatia <manavbhatia@gmail.com>
Subject: RE: BFD stability follow-up from IETF-91
Thread-Topic: BFD stability follow-up from IETF-91
Thread-Index: AQHQEpgbQ6amXjPuFEmbPIOgLl4p2pyFZl2AgAAitQD//66CwIAAVuwA//+setA=
Date: Mon, 08 Dec 2014 06:35:35 +0000
Message-ID: <7347100B5761DC41A166AC17F22DF1121B8AE77E@eusaamb103.ericsson.se>
References: <CO2PR0501MB823C222B7D62779F4DF58CDB3780@CO2PR0501MB823.namprd05.prod.outlook.com> <D0A647C1.28843%mmudigon@cisco.com> <CO2PR0501MB8234A1BDDFD008EE12C847AB3780@CO2PR0501MB823.namprd05.prod.outlook.com> <CECE764681BE964CBE1DFF78F3CDD3943F5AE38D@xmb-aln-x01.cisco.com> <CAG1kdogkUr2YyodeUPWOqea+2jqOkmdYnPywVHCw8j1+=9eM6A@mail.gmail.com> <CECE764681BE964CBE1DFF78F3CDD3943F5AE4AE@xmb-aln-x01.cisco.com> <CAG1kdoh5DwdKrJWK_aSvo4KQ6Xu5ZaTObe_PLhV66YZ4yQozmg@mail.gmail.com> <20141207193610211284.1f098741@sniff.de> <CAG1kdojxdDY0qXPYnZ5K67rizVaD7gHte1MdRA2q==K6SoRVsw@mail.gmail.com> <CO2PR0501MB823962B235ACA590C076236B3640@CO2PR0501MB823.namprd05.prod.outlook.com> <7347100B5761DC41A166AC17F22DF1121B8AE751@eusaamb103.ericsson.se> <CAG1kdogLZs_ih61MZHHDUK6Yp8WgoZnHwXfeTS7dHWf+TZJzwg@mail.gmail.com>
In-Reply-To: <CAG1kdogLZs_ih61MZHHDUK6Yp8WgoZnHwXfeTS7dHWf+TZJzwg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.11]
Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B8AE77Eeusaamb103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplkeLIzCtJLcpLzFFi42KZXLrHW7fkW0uIwaUbihaXJ7WxW8y+8p/Z 4vOfbYwW1+5uZXZg8dg56y67x5IlP5k8rjddZfdoXd3NEsASxWWTkpqTWZZapG+XwJWxf+oM poJPixkrPh7ey97AeGQ+YxcjJ4eEgInEo7+tTBC2mMSFe+vZuhi5OIQEjjBKXL/5jhHCWcYo ce/PJVaQKjYBI4kXG3vYQWwRAQ2J1vcHmLsYOTiYBYolXm1RBwkLCxhKrOpeDFViJHFsxlwo 209iy9LXYMtYBFQkHh25zArSyivgK/F+vQDEqv1sEqd2HAE7jlMgUOLqyd1gNiPQcd9PrQHr ZRYQl7j1ZD7U0QISS/acZ4awRSVePv7HCmErSXz8PZ8doj5fYsP0l2D1vAKCEidnPmGZwCg6 C8moWUjKZiEpmwX2mabE+l36ECWKElO6H7JD2EDPz5nLjiy+gJF9FSNHaXFqWW66kcEmRmD8 HZNg093BuOel5SFGAQ5GJR7eDYtbQoRYE8uKK3MPMUpzsCiJ886qnRcsJJCeWJKanZpakFoU X1Sak1p8iJGJg1OqgTFy6p4/9r8PO8nIBEmcsmzZ6+gsn/SNoezcr63mAT1VgcJ7n/nHlJ52 cj/qkLL4cOnmRKbpczfsnf+GOS/XIKC/4fS2zua791cm17YXLJ750yHu/fP2G16Pr1y9zxzW vdvk4MJn0yx+fJ67t8K8LVz6r7qedubL/wYuG4slqpivGH5iD+H5w6/EUpyRaKjFXFScCACf 1+DooAIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/aih7h9lxLgW_ZFdhDu8KNYKsTTc
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, 08 Dec 2014 06:35:40 -0000

Hi Manav,
I’d propose to take this discussion off-line. Anyone who’s interested in developing solution based on BFD Echo please feel free to contact me directly.

                Regards,
                                Greg

From: Manav Bhatia [mailto:manavbhatia@gmail.com]
Sent: Monday, December 08, 2014 2:27 PM
To: Gregory Mirsky
Cc: Santosh P K; Marc Binderberger; rtg-bfd@ietf.org
Subject: Re: BFD stability follow-up from IETF-91

Hi Greg,

What if i dont have a single-hop session? Do you want the operator to set up one between the sender and its immediate next-hop and another between the receiver and its immediate next-hop?

Cheers, Manav

On Mon, Dec 8, 2014 at 11:52 AM, Gregory Mirsky <gregory.mirsky@ericsson.com<mailto:gregory.mirsky@ericsson.com>> wrote:
Hi Santosh,
do you envision scenario when BFD multi-hop and single-hop sessions that share the same sender behave differently? In my opinion, if multi-hop session is unstable and single-hop is stable, then the problem is likely in the network and thus is real, rather than in the BFD sender and more implementation specific. Thus running BFD Echo even without cooperation of the next hop node (no timestamps there) would give sender information about latencies BFD is subjected to in this node.

                Regards,
                                Greg

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org<mailto:rtg-bfd-bounces@ietf.org>] On Behalf Of Santosh P K
Sent: Monday, December 08, 2014 2:07 PM
To: Manav Bhatia; Marc Binderberger
Cc: rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: RE: BFD stability follow-up from IETF-91

Hello Mac and Manav,
     Are we just talking about singlehop? How about MPLS BFD and multihop where echo does not work?

Thanks
Santosh P K

From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Manav Bhatia
Sent: Monday, December 08, 2014 9:33 AM
To: Marc Binderberger
Cc: rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: Re: BFD stability follow-up from IETF-91

Hi Marc,



* Greg's echo idea is of course do-able - when you think timestamping in
hardware can be done then it can be done in the forwarding path for echos as
well. Depends on your hardware :-) and on an agreed (minimal) format for
echo. As mentioned BFD echo is not defined/used for multiple BFD features,
which limits it's use though.

For the echo mechanism to work, do you agree that you would have to continuously send Echos so that you can detect the issue?

Or are you suggesting that once BFD flaps we will start sending Echoes overloaded with debug information to detect the issue?

I'd like to understand this before the mailing list sees a barrage of emails. Alternatively, we can also take it offline and only report the summary of our discussion to the list.

Cheers, Manav