IETF Logo Mail Archive

Re: Mirja Kühlewind's Discuss on draft-ietf-bfd-multipoint-18: (with DISCUSS)

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Thu, 05 July 2018 20:27 UTC

Return-Path: <ietf@kuehlewind.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 8E455130F7B for <rtg-bfd@ietfa.amsl.com>; Thu, 5 Jul 2018 13:27:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.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 zN7h5NuynxIB for <rtg-bfd@ietfa.amsl.com>; Thu, 5 Jul 2018 13:27:13 -0700 (PDT)
Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAE15130F78 for <rtg-bfd@ietf.org>; Thu, 5 Jul 2018 13:27:12 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=fFmyiPnkmAq01IpYQzftoGUmjuWkVUkhqFBNDEENMUsIeKU4kVNdQlCgYI3+G7/6wklmQlSJ5L5Q6jZZNv9zkbA6quD4YpBtv5Sd2rh9/1Pb3Gv5lhvKCPjhY+KLB4+Nv9c7UGMyy3lBkgO5qeMFB7XvWN0XpO6+4x0piBjbNPs=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost;
Received: (qmail 950 invoked from network); 5 Jul 2018 22:26:10 +0200
Received: from i577bced6.versanet.de (HELO ?192.168.178.24?) (87.123.206.214) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 5 Jul 2018 22:26:10 +0200
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Subject: Re: Mirja Kühlewind's Discuss on draft-ietf-bfd-multipoint-18: (with DISCUSS)
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <CA+RyBmX0vYfWG=y3idNPw9=58LOwm7V0LqkzJvXgSk2sdFJb+w@mail.gmail.com>
Date: Thu, 05 Jul 2018 22:26:09 +0200
Cc: Reshad Rahman <rrahman@cisco.com>, draft-ietf-bfd-multipoint@ietf.org, rtg-bfd@ietf.org, The IESG <iesg@ietf.org>, bfd-chairs@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0AAFC485-F80F-4362-B876-4F3AB371810A@kuehlewind.net>
References: <153064270085.5078.5189673902650964259.idtracker@ietfa.amsl.com> <CA+RyBmX0vYfWG=y3idNPw9=58LOwm7V0LqkzJvXgSk2sdFJb+w@mail.gmail.com>
To: Greg Mirsky <gregimirsky@gmail.com>
X-Mailer: Apple Mail (2.3445.8.2)
X-PPP-Message-ID: <20180705202610.941.74013@lvps83-169-45-111.dedicated.hosteurope.de>
X-PPP-Vhost: kuehlewind.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/rmSRtmxYNiGRz-M3jkWXX129sAU>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.26
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: Thu, 05 Jul 2018 20:27:15 -0000

Hi Greg,

just one thing quickly

> Am 05.07.2018 um 21:27 schrieb Greg Mirsky <gregimirsky@gmail.com>:
> 
> 2) See sec 7 of RFC 8085
> "When BFD is used across multiple hops, a congestion control mechanism
>    MUST be implemented, and when congestion is detected, the BFD
>    implementation MUST reduce the amount of traffic it generates. "
> GIM>> I couldn't find this in RFC 8085 and had to broaden my search. I believe that thsi quote is from RFC 7880 Seamless BFD. I'm puzzled why this specification, when talking about challenges S-BFD may face, switches to requirement for BFD. Doesn't look right. And more, increasing transmission interval to avoid packet drop defeats the purpose of using proactive defect detection mechanism. The purpose of the fault management is to detect failures, not to avoid the detection. If active OAM generates excess of traffic, then other OAM mechanisms can be considered and used. But loosening OAM is not, in my view, proper way to address network problem as it rather hides them, not detets and reports as it intended to do. 
This quote is from RFC5880. The BFD base spec. Sorry that was copy and past error!

v2.23.0 | Report a Bug | By Email