Re:Rtg-bfd Digest, Vol 163, Issue 9
"Albert Fu (BLOOMBERG/ 120 PARK)" <afu14@bloomberg.net> Tue, 17 September 2019 19:15 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 F14DA120127 for <rtg-bfd@ietfa.amsl.com>; Tue, 17 Sep 2019 12:15:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 wwnLB_lza7xi for <rtg-bfd@ietfa.amsl.com>; Tue, 17 Sep 2019 12:15:20 -0700 (PDT)
Received: from mgnj2.bloomberg.net (mgnj2.bloomberg.net [69.191.244.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8C69120A44 for <rtg-bfd@ietf.org>; Tue, 17 Sep 2019 12:15:18 -0700 (PDT)
X-BB-Reception-Complete: 17 Sep 2019 15:15:17 -0400
X-IP-Listener: Outgoing Mail
X-IP-MID: 1254308339
Received: from msllnjpmsgsv06.bloomberg.com (HELO msllnjpmsgsv06) ([10.126.134.166]) by mgnj2.bloomberg.net with SMTP; 17 Sep 2019 15:15:17 -0400
X-BLP-INETSVC: version=BLP_APP_S_INETSVC_1.0.1; host=mgnj2:25; conid=348
Date: Tue, 17 Sep 2019 19:15:17 -0000
From: "Albert Fu (BLOOMBERG/ 120 PARK)" <afu14@bloomberg.net>
Reply-To: Albert Fu <afu14@bloomberg.net>
To: cpignata@cisco.com, rtg-bfd@ietf.org
MIME-Version: 1.0
Message-ID: <5D8130C5015300A600390835_0_79005@msllnjpmsgsv06>
X-BLP-GUID: 5D8130C5015300A6003908350000
Subject: Re:Rtg-bfd Digest, Vol 163, Issue 9
Content-Type: multipart/alternative; boundary="BOUNDARY_5D8130C5015300A600390835_0_112624_msllnjpmsgsv06"
Content-ID: <ID_5D8130C5015300A600390835_0_78990@msllnjpmsgsv06>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/v6adJv4Szsu1Dymn0E2834FCCL4>
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: Tue, 17 Sep 2019 19:15:26 -0000
Hi Carlos, > Instead of (or in addition to) a lower transmission interval, why not add > flexibility to not *have* to send large packets every packet, and instead send > every n paks or so? One of the things I learned since becoming involved with the BFD working group is a strong desire within the WG to keep BFD simple, and avoid complex/unnecessary changes. Our proposal maintains the current BFD "structure" and behavior (padded bytes at the IP layer). If scaling is an issue, it would be simpler to reduce the transmit interval rather than trying to keep track of counters for large/small packets. Most users will do scaling test in the lab to quantify suitable values for production deployment. Thanks Albert
- Re:Rtg-bfd Digest, Vol 163, Issue 9 Albert Fu (BLOOMBERG/ 120 PARK)