Re: BFD stability follow-up from IETF-91

Mahesh Jethanandani <mjethanandani@gmail.com> Wed, 03 December 2014 04:46 UTC

Return-Path: <mjethanandani@gmail.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 D3D2A1A007D for <rtg-bfd@ietfa.amsl.com>; Tue, 2 Dec 2014 20:46:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 nDZTlFUr3nFw for <rtg-bfd@ietfa.amsl.com>; Tue, 2 Dec 2014 20:46:18 -0800 (PST)
Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 010061A007E for <rtg-bfd@ietf.org>; Tue, 2 Dec 2014 20:46:17 -0800 (PST)
Received: by mail-qg0-f51.google.com with SMTP id l89so10213971qgf.38 for <rtg-bfd@ietf.org>; Tue, 02 Dec 2014 20:46:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=dOA1EYqDv/hMve5NUt286SJZTZEmxadCBefJ7HYRkP8=; b=hZaTLaAuMbCc3yfIHmEtlkRxpEWebKl05CeyecT9MNqy2UR37xciMZ4ylgMgFCfWuq GhT3CFx0bW9eMxhG/KUxCLA6gq1yY+OYT5HufQllvIMG5kx+FbLIzVqNc6NXN5KFCsZJ w5Df2Lwwl0ahz36elCBoiwB+XCZdNd93sHb5ymfF9+FhLVqoa8CN1P1nkDJJSRxWsl5P b+QPiWR7pNLDE6qeR5umGqo2BfSCYGX2ll7zHFBgMDkDFlm9UI+jbQNRC4syRbH1BSxL iv2Uh9DByS2qIrvpNLBUqNz8Aa8hHE5wEPvz+/wz8KT1b0ent7SvBg6/Uqcl9IiIjYRj tQXA==
X-Received: by 10.224.34.73 with SMTP id k9mr4638554qad.33.1417581977153; Tue, 02 Dec 2014 20:46:17 -0800 (PST)
Received: from [192.168.1.133] (108-247-127-76.lightspeed.sntcca.sbcglobal.net. [108.247.127.76]) by mx.google.com with ESMTPSA id b17sm22451424qah.35.2014.12.02.20.46.15 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Dec 2014 20:46:16 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D81CB5EE-037D-4F42-B3F6-2025FE282E8A"
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Subject: Re: BFD stability follow-up from IETF-91
From: Mahesh Jethanandani <mjethanandani@gmail.com>
In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B8A87E6@eusaamb103.ericsson.se>
Date: Tue, 02 Dec 2014 20:46:13 -0800
Message-Id: <730769BB-D021-4E22-878A-2C289822A156@gmail.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>
To: Gregory Mirsky <gregory.mirsky@ericsson.com>
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtg-bfd/lOQm2WPfDD-cRRITLLBEi_npaPk
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: Wed, 03 Dec 2014 04:46:21 -0000

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> 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
> 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 <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 <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 <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