Re:Rtg-bfd Digest, Vol 178, Issue 5

"Albert Fu (BLOOMBERG/ 120 PARK)" <afu14@bloomberg.net> Sun, 31 January 2021 19:06 UTC

Return-Path: <afu14@bloomberg.net>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6033A11C4 for <rtg-bfd@ietfa.amsl.com>; Sun, 31 Jan 2021 11:06:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.369
X-Spam-Level:
X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bloomberg.net
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 s7GJsPRMaDxa for <rtg-bfd@ietfa.amsl.com>; Sun, 31 Jan 2021 11:06:04 -0800 (PST)
Received: from mgnj16.bloomberg.net (mgnj16.bloomberg.net [69.191.244.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED9203A11C3 for <rtg-bfd@ietf.org>; Sun, 31 Jan 2021 11:06:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bloomberg.net; l=3316; q=dns/txt; s=20200929; t=1612119964; x=1612206364; h=date:from:reply-to:to:mime-version:message-id:subject: content-id; bh=Sch71q0+qLFqUg0pfZhnSYMzuFZVfEuY+YfUi6Qu5Fs=; b=hDwzr1E3or/D3gWvUrtM1+GVLqY6eKU42pKRR9gs1ohjI2aDo5wNapsx IZvoNV+UisrbDPihymtg8Dt/HkH7N3Zn2LZaSI02xrkrZXaf6IwHVa7Vh hmP6tuw+U1dCZyYhNtuSf3PZRJDJz9qZVrJY/2QYd1zWetBJM1Oq2QFFT 1qaZa5oHAiL8RucKgTTOnwsD1TfioapcEbmBxkzp5J8mfDzjg5BbtTiH9 rionGeMGa66sMsktXZGMc/X0lO0rF5Mw01D7VKMtnAiw9D1aF7H5zC19z SQEcjJr2HqsvswwKgbcD/fH/lzbV2kuzHt4FnBU1P7UVQ4kS6dtggett6 g==;
X-BB-Reception-Complete: 31 Jan 2021 14:06:02 -0500
X-IP-Listener: Outgoing Mail
X-IP-MID: 242703734
Received: from msllnjpmsgsv06.bloomberg.com (HELO msllnjpmsgsv06) ([10.126.134.166]) by mgnj16.bloomberg.net with SMTP; 31 Jan 2021 14:06:01 -0500
X-BLP-INETSVC: version=BLP_APP_S_INETSVC_1.0.1; host=mgnj16:25; conid=608
Date: Sun, 31 Jan 2021 19:06:01 -0000
From: "Albert Fu (BLOOMBERG/ 120 PARK)" <afu14@bloomberg.net>
Reply-To: "Albert Fu" <afu14@bloomberg.net>
To: rtg-bfd@ietf.org
MIME-Version: 1.0
Message-ID: <6016FF99010E05DC00390001_0_4903@msllnjpmsgsv06>
X-BLP-GUID: 6016FF99010E05DC003900010000
Subject: =?UTF-8?B?UmU6UnRnLWJmZCBEaWdlc3QsIFZvbCAxNzgsIElzc3VlIDU=?=
Content-Type: multipart/alternative; boundary="BOUNDARY_6016FF99010E05DC00390001_0_7268_msllnjpmsgsv06"
Content-ID: <ID_6016FF99010E05DC00390001_0_4853@msllnjpmsgsv06>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/sn0KKPAd6BhCwCgm4UOGKLX3NOI>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 31 Jan 2021 19:06:05 -0000

Hi,


   1. Re: New Version Notification for
      draft-ietf-bfd-stability-07.txt (Reshad Rahman)

This feature  is good to have. As a matter of fact, we have been trying to get vendors to expose BFD counters as we know links from carriers do drop packets without any indication of errors, and the basic send/receive counters are not reliable indicators, since the timers are randomized up to 25% lower.


The draft talks about geneation of diagnostic info but no details. I would think syslog is not practical for large network. What do you think about mentioning keeping counters of missing seq numbers, and have these counters exposed to telemetry/snmp? This would be very useful to us.


Thanks


Albert