RE: BFD stability follow-up from IETF-91

Gregory Mirsky <gregory.mirsky@ericsson.com> Mon, 08 December 2014 06:47 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 3501F1A6F81 for <rtg-bfd@ietfa.amsl.com>; Sun, 7 Dec 2014 22:47:23 -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 n1Lb6zi6JobA for <rtg-bfd@ietfa.amsl.com>; Sun, 7 Dec 2014 22:47:18 -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 459B81A6F6E for <rtg-bfd@ietf.org>; Sun, 7 Dec 2014 22:47:18 -0800 (PST)
X-AuditID: c618062d-f79376d000000ceb-c6-5484f931abba
Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 71.8B.03307.139F4845; Mon, 8 Dec 2014 02:04:49 +0100 (CET)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 01:47:16 -0500
From: Gregory Mirsky <gregory.mirsky@ericsson.com>
To: "MALLIK MUDIGONDA (mmudigon)" <mmudigon@cisco.com>, Santosh P K <santoshpk@juniper.net>, Manav Bhatia <manavbhatia@gmail.com>, Marc Binderberger <marc@sniff.de>
Subject: RE: BFD stability follow-up from IETF-91
Thread-Topic: BFD stability follow-up from IETF-91
Thread-Index: AQHQEpgbQ6amXjPuFEmbPIOgLl4p2pyFZl2AgAAitQD//66CwIAAV0WA//+sX/CAAFbYgP//rHTw
Date: Mon, 08 Dec 2014 06:47:15 +0000
Message-ID: <7347100B5761DC41A166AC17F22DF1121B8AE7C4@eusaamb103.ericsson.se>
References: <7347100B5761DC41A166AC17F22DF1121B8AE76E@eusaamb103.ericsson.se> <D0AB44A3.28B0A%mmudigon@cisco.com>
In-Reply-To: <D0AB44A3.28B0A%mmudigon@cisco.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_7347100B5761DC41A166AC17F22DF1121B8AE7C4eusaamb103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyuXRPuK7hz5YQg7mzRSwuT2pjt5h95T+z xZFXx5gtPv/Zxmhx7e5WZgdWjym/N7J67Jx1l91jyZKfTB7Xm66ye7Su7mYJYI3isklJzcks Sy3St0vgyvjUu5Sp4PVdxorHb2sbGHceYexi5OSQEDCR6Dr9hAnCFpO4cG89WxcjF4eQwBFG iTerDzJCOMsYJWa/WckGUsUmYCTxYmMPO0hCRGAVo8SC/V/B2pkFNCWaTnxmB7GFBQwlVnUv BrNFgBqOzZgLZUdJXNk7jxXEZhFQkdhyazqYzSvgK7Hx4G0WEFtIoFji+br5zCA2p4CBxNLb S8B6GYHO+35qDdQucYlbT+ZDnS0gsWTPeWYIW1Ti5eN/rBC2ksTH3/PZIerzJc5tvMECsUtQ 4uTMJywTGEVnIRk1C0nZLCRlEHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRUjR2lxallu upHBJkZgXB6TYNPdwbjnpeUhRgEORiUe3g2LW0KEWBPLiitzDzFKc7AoifPOqp0XLCSQnliS mp2aWpBaFF9UmpNafIiRiYNTqoFRZJVDi2J0ZXZPk1ycdG3JloPPndnDDtRp7qrPXv3ylup1 Xb26TbVJh8V3C0TwzDSaKvFx4smpQhJx/+Ljes/OS/911+NHiUzSrvuWqmtjM3SDWF+zxS47 dHCBk0/QYqGmqDtf9sxKNWqIjbNJsz7SbL1HeI7fYZX0U9t/rm7U3FcbwJhkslWJpTgj0VCL uag4EQBJIt91rAIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/6CJpSzu0eEw315l5R0OXZlmorUc
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:47:23 -0000

Hi Mallik,
I think I was not clear in explaining the possible use of BFD Echo. It is not to measure packet loss in the network. That, I'm certain, is real network problem that can e properly quantified only with use of performance measurement methods, active or passive.
The subject of the proposal being discussed, as I understand, detecting superficial outages of BFD caused by scaling and/or implementation issues, not by the network environment. I agree with Mark that ensuring consistent and thus informative timestamping is the challenge by itself and better be left internal. But if there's some interest in developing something that may be used for this purpose and, at the same time, would not affect the most used BFD Async mode, then BFD Echo may be, may be the right vechicle.

                Regards,
                                Greg

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

Hi Greg,

I understand your point. I am not suggesting that we use a particular mechanism for this purpose.  The original issue that was raised to support the sequence numbers in BFD packets was that there may be loss of packets but not large enough to cause BFD session flap. So though the session stays up, there may be some packets lost. Adding sequence numbers to BFD is one of the suggestion on this thread. You suggested using echo for this purpose. My question was echo is not supported over multi hop sessions and so is there a generic way to take this forward?

Thanks

Regards
Mallik

From: Gregory Mirsky <gregory.mirsky@ericsson.com<mailto:gregory.mirsky@ericsson.com>>
Date: Monday, 8 December 2014 12:04 pm
To: Cisco Employee <mmudigon@cisco.com<mailto:mmudigon@cisco.com>>, Santosh P K <santoshpk@juniper.net<mailto:santoshpk@juniper.net>>, Manav Bhatia <manavbhatia@gmail.com<mailto:manavbhatia@gmail.com>>, Marc Binderberger <marc@sniff.de<mailto:marc@sniff.de>>
Cc: "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,
the packet loss in the network, in my opinion, is the demonstration of the real network problem that BFD is intended to detect. The BFD Echo may, I assume, help to rule out potential issues with the particular BFD implementation. Troubleshooting the real network problem, e.g. packet loss, is not in scope of BFD, in my opinion, and can be done with help of other OAM instruments.

                Regards,
                                Greg

From: MALLIK MUDIGONDA (mmudigon) [mailto:mmudigon@cisco.com]
Sent: Monday, December 08, 2014 2:28 PM
To: Gregory Mirsky; Santosh P K; Manav Bhatia; Marc Binderberger
Cc: rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>
Subject: Re: BFD stability follow-up from IETF-91

Hi Greg,

Are we assuming that there is a single node in-between the sender and receiver for the multi hop case? The actual problem of packet loss may be happening after the next hop node. Since we don't have a way to run echo for multi hop sessions, how do we identify packet losses in such a case if we use echo?

Thanks

Regards
Mallik

From: Gregory Mirsky <gregory.mirsky@ericsson.com<mailto:gregory.mirsky@ericsson.com>>
Date: Monday, 8 December 2014 11:52 am
To: Santosh P K <santoshpk@juniper.net<mailto:santoshpk@juniper.net>>, Manav Bhatia <manavbhatia@gmail.com<mailto:manavbhatia@gmail.com>>, Marc Binderberger <marc@sniff.de<mailto:marc@sniff.de>>
Cc: "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 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] 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