RE: BFD stability follow-up from IETF-91
Santosh P K <santoshpk@juniper.net> Thu, 04 December 2014 15:02 UTC
Return-Path: <santoshpk@juniper.net>
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 5E7F11AD40D for <rtg-bfd@ietfa.amsl.com>; Thu, 4 Dec 2014 07:02:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 KQUzxRmq_R0A for <rtg-bfd@ietfa.amsl.com>; Thu, 4 Dec 2014 07:01:56 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:761]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 009831AD400 for <rtg-bfd@ietf.org>; Thu, 4 Dec 2014 07:01:55 -0800 (PST)
Received: from CO2PR0501MB823.namprd05.prod.outlook.com (10.141.244.145) by CO2PR0501MB824.namprd05.prod.outlook.com (10.141.244.146) with Microsoft SMTP Server (TLS) id 15.1.26.15; Thu, 4 Dec 2014 15:01:32 +0000
Received: from CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) by CO2PR0501MB823.namprd05.prod.outlook.com ([10.141.244.145]) with mapi id 15.01.0026.003; Thu, 4 Dec 2014 15:01:32 +0000
From: Santosh P K <santoshpk@juniper.net>
To: Gregory Mirsky <gregory.mirsky@ericsson.com>, Mahesh Jethanandani <mjethanandani@gmail.com>
Subject: RE: BFD stability follow-up from IETF-91
Thread-Topic: BFD stability follow-up from IETF-91
Thread-Index: AQHQCQ6qzE1oSJ0IQ0C/g/DAGkzw7JxyeiWAgAAfxYCAAAeWAIAAjSQAgAD7mQCAAEe3gIABbj6AgAARfwCAAAtmAIAAdgIAgARDtICAAFI2AIACTQCAgAE4tICAAHSogIAABUQAgACJ5+A=
Date: Thu, 04 Dec 2014 15:01:32 +0000
Message-ID: <CO2PR0501MB8231A4913DEB31323847CA8B3780@CO2PR0501MB823.namprd05.prod.outlook.com>
References: <007701d00af9$28719050$7954b0f0$@chinamobile.com> <D09E5FAC.27C51%mmudigon@cisco.com> <007e01d00b07$9c02cc10$d4086430$@chinamobile.com> <7347100B5761DC41A166AC17F22DF1121B8998E7@eusaamb103.ericsson.se> <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>
In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8AAA24@eusaamb103.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [116.197.184.19]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB824;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR0501MB824;
x-forefront-prvs: 041517DFAB
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(377454003)(189002)(24454002)(51444003)(20776003)(2656002)(92726001)(99396003)(54606007)(40100003)(92566001)(46102003)(19609705001)(50986999)(64706001)(86362001)(54206007)(19580395003)(15202345003)(76176999)(15975445006)(19580405001)(54356999)(66066001)(93886004)(561944003)(21056001)(120916001)(122556002)(68736005)(31966008)(33656002)(87936001)(101416001)(97736003)(19625215002)(77096005)(62966003)(77156002)(19300405004)(107046002)(74316001)(76576001)(16236675004)(99286002)(95666004)(105586002)(106356001)(4396001)(106116001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB824; H:CO2PR0501MB823.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: multipart/alternative; boundary="_000_CO2PR0501MB8231A4913DEB31323847CA8B3780CO2PR0501MB823na_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/bPIrTmfMuWzofeCk_RsFY-LtbRs
X-Mailman-Approved-At: Thu, 04 Dec 2014 07:20:28 -0800
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: Thu, 04 Dec 2014 15:02:01 -0000
Hello Greg, Debugging BFD is one of the use case. I also want to bring up one of the use case that Jeff suggested in his earlier mail. Operator might NOT want to run OAM which does loss and delay measurement all the time due to its overhead. With the extension to BFD (sequence number) we can detect if there is any loss but BFD still stays up. This loss detection can be used as a trigger for loss and delay measurement. Echo can be used only in case of singlehop and in one direction only. Thanks Santosh P K From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Thursday, December 04, 2014 12:12 PM To: Mahesh Jethanandani Cc: rtg-bfd@ietf.org Subject: RE: BFD stability follow-up from IETF-91 Hi Mahesh, indeed, LSP Ping is part of MPLS OAM tool set as BFD itself that intended to monitor operational state of the network, path continuity between two nodes. And LSP Ping, as primarily on-demand troubleshooting tool, helps localize and, to certain degree, diagnose the problem. But the ultimate debugging is proprietary. This proposal, in my view, helps not monitor behavior of the network but BFD itself, quality of BFD implementation. I’m not saying that it is not useful for implementers and operators, one can find that too many BFD sessions or at too short intervals being ran. I don’t agree to loading this as extension of the widely used standard. Perhaps we can look into using BFD Echo as self-debugging instrument. Regards, Greg From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com] Sent: Wednesday, December 03, 2014 10:23 PM To: Gregory Mirsky Cc: Fan, Peng; MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org> Subject: Re: BFD stability follow-up from IETF-91 Greg, I believe we have a disagreement here. I do not believe that issue of debug ability are outside the scope of a standardized protocol. Look at MPLS ping and traceroute (RFC 4379) . They are ultimately debug tools used to establish viability of a path and they are very much part of the standardized protocol. On Dec 3, 2014, at 3:25 PM, Gregory Mirsky <gregory.mirsky@ericsson.com<mailto:gregory.mirsky@ericsson.com>> wrote: Hi Mahesh, I consider issues of debugability, not of just BFD but any other standardized protocol, to be outside of Standard track, at most to be suitable for Informational or Experimental track. If we agree on that, then we can discuss scenarios that present problem and investigate whether anything in the protocol requires clarification to help vendors in building well-performing, scalable and interoperable implementations and provide operational guidelines for operators. Regards, Greg From: Mahesh Jethanandani [mailto:mjethanandani@gmail.com] Sent: Tuesday, December 02, 2014 8:46 PM To: Gregory Mirsky Cc: Fan, Peng; MALLIK MUDIGONDA (mmudigon); rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org> Subject: Re: BFD stability follow-up from IETF-91 Greg, What is Peng referring to is a way to figure out why a particular BFD session flapped, particularly if the packet(s) for that session arrive late. I do not see how that can be performance measurement. It is basic BFD debug ability. Running a separate DM does tell you why a particular BFD session flapped. Now we can debate what methods can be employed to measure that delay and I am open to ways to doing it, including local loopback to measure transmit delays or time stamping of packets in hardware. But in cases, where there is no support for either of the capabilities, one of the suggested solutions is to use the time stamps carried in the BFD payload. Cheers. On Dec 1, 2014, at 9:38 AM, Gregory Mirsky <gregory.mirsky@ericsson.com<mailto:gregory.mirsky@ericsson.com>> wrote: Hi Peng, and still, you’re looking for a tool to measure BFD performance. Then you’ll be looking for a tool to verify the BFD performance measurement, and on, and on. Operators do need complete set of FCAPS tools, including performance measurement. Note that passive performance measurement through marking method that Mach Chen referred to can monitor BFD flow(s) and be used to do Loss and/or Delay Measurement. And active Synthetic Loss Measurement may simulate flow of small packets as well as relatively large packets. And the same goes for active measurement method of Delay Measurement. I like Swiss Army knives but let us not turn BFD into one. Regards, Greg From: Fan, Peng [mailto:fanpeng@chinamobile.com] Sent: Monday, December 01, 2014 4:44 AM To: Gregory Mirsky; 'MALLIK MUDIGONDA (mmudigon)'; rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org> Subject: RE: BFD stability follow-up from IETF-91 Hi Gregory, I was just giving an example :) Application traffic usually cannot stand small packet loss, not to say 30% loss. I am actually asking for a debug function that could give us some useful hints of poor connection with small protocol change, besides the basic connectivity information. If it measures something, it measures packets of BFD itself. So I don’t expect it to be considered as a performance measurement tool. Best regards, Peng From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Saturday, November 29, 2014 3:37 AM To: Fan, Peng; 'MALLIK MUDIGONDA (mmudigon)'; rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org> Subject: RE: BFD stability follow-up from IETF-91 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<mailto: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 Mahesh Jethanandani Co-chair, NETCONF WG mjethanandani@gmail.com<mailto:mjethanandani@gmail.com> Mahesh Jethanandani Co-chair, NETCONF WG mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>
- BFD stability follow-up from IETF-91 Jeffrey Haas
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- Re: BFD stability follow-up from IETF-91 Marc Binderberger
- RE: BFD stability follow-up from IETF-91 Mach Chen
- RE: BFD stability follow-up from IETF-91 Marc Binderberger
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- RE: BFD stability follow-up from IETF-91 Mach Chen
- RE: BFD stability follow-up from IETF-91 Vengada Prasad Govindan (venggovi)
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- RE: BFD stability follow-up from IETF-91 Santosh P K
- RE: BFD stability follow-up from IETF-91 Santosh P K
- RE: BFD stability follow-up from IETF-91 Santosh P K
- RE: BFD stability follow-up from IETF-91 Santosh P K
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- RE: BFD stability follow-up from IETF-91 Santosh P K
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- Re: BFD stability follow-up from IETF-91 Abhishek Verma
- RE: BFD stability follow-up from IETF-91 Fan, Peng
- Re: BFD stability follow-up from IETF-91 MALLIK MUDIGONDA (mmudigon)
- RE: BFD stability follow-up from IETF-91 Fan, Peng
- Re: BFD stability follow-up from IETF-91 MALLIK MUDIGONDA (mmudigon)
- RE: BFD stability follow-up from IETF-91 Santosh P K
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- Re: BFD stability follow-up from IETF-91 Jeffrey Haas
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- Re: BFD stability follow-up from IETF-91 Marc Binderberger
- Re: BFD stability follow-up from IETF-91 Marc Binderberger
- RE: BFD stability follow-up from IETF-91 Marc Binderberger
- RE: BFD stability follow-up from IETF-91 Fan, Peng
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- Re: BFD stability follow-up from IETF-91 Mahesh Jethanandani
- RE: BFD stability follow-up from IETF-91 Santosh P K
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- RE: BFD stability follow-up from IETF-91 Santosh P K
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- RE: BFD stability follow-up from IETF-91 Vengada Prasad Govindan (venggovi)
- RE: BFD stability follow-up from IETF-91 Santosh P K
- RE: BFD stability follow-up from IETF-91 Santosh P K
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- Re: BFD stability follow-up from IETF-91 Mahesh Jethanandani
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- Re: BFD stability follow-up from IETF-91 MALLIK MUDIGONDA (mmudigon)
- Re: BFD stability follow-up from IETF-91 MALLIK MUDIGONDA (mmudigon)
- RE: BFD stability follow-up from IETF-91 Santosh P K
- RE: BFD stability follow-up from IETF-91 Nobo Akiya (nobo)
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- RE: BFD stability follow-up from IETF-91 Nobo Akiya (nobo)
- Re: BFD stability follow-up from IETF-91 Jeffrey Haas
- RE: BFD stability follow-up from IETF-91 Santosh P K
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- Re: BFD stability follow-up from IETF-91 Sam K. Aldrin
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- Re: BFD stability follow-up from IETF-91 Sam K. Aldrin
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- Re: BFD stability follow-up from IETF-91 Sam K. Aldrin
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- Re: BFD stability follow-up from IETF-91 Mahesh Jethanandani
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- Re: BFD stability follow-up from IETF-91 MALLIK MUDIGONDA (mmudigon)
- Re: BFD stability follow-up from IETF-91 Marc Binderberger
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- Re: BFD stability follow-up from IETF-91 Marc Binderberger
- Re: BFD stability follow-up from IETF-91 Marc Binderberger
- Re: BFD stability follow-up from IETF-91 Marc Binderberger
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- RE: BFD stability follow-up from IETF-91 Santosh P K
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- Re: BFD stability follow-up from IETF-91 MALLIK MUDIGONDA (mmudigon)
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- Re: BFD stability follow-up from IETF-91 Sam Aldrin
- RE: BFD stability follow-up from IETF-91 Gregory Mirsky
- Re: BFD stability follow-up from IETF-91 Mahesh Jethanandani
- Re: BFD stability follow-up from IETF-91 Marc Binderberger
- Re: BFD stability follow-up from IETF-91 MALLIK MUDIGONDA (mmudigon)
- Re: BFD stability follow-up from IETF-91 Manav Bhatia
- Re: BFD stability follow-up from IETF-91 Marc Binderberger
- TWAMP analysis for assisting BFD debuggin (was Re… Jeffrey Haas
- RE: TWAMP analysis for assisting BFD debuggin (wa… Gregory Mirsky
- Re: TWAMP analysis for assisting BFD debuggin (wa… Mahesh Jethanandani
- RE: TWAMP analysis for assisting BFD debuggin (wa… Gregory Mirsky
- Re: TWAMP analysis for assisting BFD debuggin (wa… Jeffrey Haas
- Re: TWAMP analysis for assisting BFD debuggin (wa… Jeffrey Haas