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

Greg Mirsky <> Thu, 05 July 2018 19:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9ACC3130F67; Thu, 5 Jul 2018 12:27:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KYqotFn7uwd9; Thu, 5 Jul 2018 12:27:52 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5B30612F1A2; Thu, 5 Jul 2018 12:27:52 -0700 (PDT)
Received: by with SMTP id y17-v6so2671236ljy.8; Thu, 05 Jul 2018 12:27:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+V3ErynGLUDLjh4ZprzmyqXHykSR20qJY4r+C6siatU=; b=lX08Pj5Y3ZYqwoTpM9WR2OZ0e5h3nRCJWb0D66iF1U9NLCRzqr8PpVCBR0BVW2HgFW t8y9PhwatbA3lXjRnXNNYa0BNIum6tTn/UebXfQtd1+ksMSo+TdHJeWFhPqoHpgOGhrq qytptoUZs1ceYDRidzDFaLhmTBVpsx/95dvRzB/tlX2YW/tWSCLKL46+1AiZazKWgfLn yFYTOMT1zwvn2kR/xRlbxO41rjlOQRYN0/qg0oASGMKdkIotbSRd8GWXPHhyRLr04JmZ FQzCS4vdVIiCAIl5CmccUnVvEB/Ggi7whL2fwwAK0KTA28NStps2yxH+0mM36ZuWXDmt b2lA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+V3ErynGLUDLjh4ZprzmyqXHykSR20qJY4r+C6siatU=; b=Xl7cq2wfyGIUir9t1EcQ+PdsJtkrzgmCunJFjTJ5P643JC/lE3ErI0rYDBI/T5lEsK KcBg47Ko4rGhkq4YTHan/28hQbTxwpUmDytxJDeOdaHZP7ENQna8vA0AHnipQQmRTP8Q CXOI8met1CmZOEstVTziNyxShH5KmXMTFaNsTPywtbG9EA0HKSiLxkxafWTXTPcOt+t4 i98hPDS7fsNANTFjZXP678LYjyl0zKhsWeqXTTLLsPZupFEf0lUYDqU1E/rXckeqQdj4 zEvYuHbcCwP675OFGq1ZAA0xoMbZv9xvhVlO+dDVRk5SS70GYAseIweaHpv7kFB1VcHa 3EDQ==
X-Gm-Message-State: APt69E1pEpMvxfms4bysdX//Qs47w4BPplhaf1W+l8xZrnw65iFqxXph EgvhmF2oFArwvv1LBCUNziZgAa9biYePTPm0Hl8=
X-Google-Smtp-Source: AAOMgpdw/Cp58OB5uNaTyhoUUIOscPi0wTA59+lkgDiEElabbbRDwxTfxeVoZSxDXutbiZ8hhNTNevOMJyZzFDwvCpI=
X-Received: by 2002:a2e:5617:: with SMTP id k23-v6mr4976245ljb.86.1530818870443; Thu, 05 Jul 2018 12:27:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a2e:709:0:0:0:0:0 with HTTP; Thu, 5 Jul 2018 12:27:49 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Greg Mirsky <>
Date: Thu, 05 Jul 2018 12:27:49 -0700
Message-ID: <>
Subject: Re: Mirja Kühlewind's Discuss on draft-ietf-bfd-multipoint-18: (with DISCUSS)
To: Mirja Kühlewind <>
Cc: The IESG <>,, Reshad Rahman <>,,
Content-Type: multipart/alternative; boundary="000000000000fd03050570458ac9"
Archived-At: <>
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Jul 2018 19:27:56 -0000

Hi Mirja,
thank you for the review and your comments. Please find my answers in-line
and tagged GIM>>.


On Tue, Jul 3, 2018 at 11:31 AM, Mirja Kühlewind <>

> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-bfd-multipoint-18: Discuss
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> This mechanism has the potentially to easily overload the network as there
> is
> no handshake and therefore also no feedback mechanism (as already noted by
> the
> TSV-ART review of Bob - Thanks!). Regarding the base spec in RFC5880, this
> mechanism can only be used under certain constrains which should be clearly
> stated in this doc, which are:
> 1) See sec 6.8.1 of RFC5880:
> "bfd.DesiredMinTxInterval
>       [...] The actual
>       interval is negotiated between the two systems.  This MUST be
>       initialized to a value of at least one second (1,000,000
>       microseconds) according to the rules described in section 6.8.3."
> As there no negotiation in this spec, bfd.DesiredMinTxInterval MUST always
> be
> at least one second. Actually RFC8085 even recommend 3 sec (see sec 3.1.3).
GIM>> I believe that such limit will negatively impact applicability of
this method to detect defects in networks. Analysis of BFD transmission
intervals provided in RFC 7419. The conclusion was:
   This document defines the set of Common Interval values to be: 3.3
   msec, 10 msec, 20 msec, 50 msec, 100 msec, and 1 sec.
I believe that systems that intended to use mpBFD should use RFC 7419 as
Also, consider two proposals to use mpBFD in VRRP
<> and
that been discussed by RTGWG and PIM WGs. The goal is to ensure sub-second
detection of head's failure by tails - Master in case of VRRP, DR in PIM-SM

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

> As there is no feedback and therefore no congestion control, this spec can
> only
> be used for one-hop scenarios and the TTL or Hop Count MUST be set to one.
GIM>> For VRRP and PIM-SM use cases TTL will be set to one as that is
mandated by the use cases. But making this generic requirement may be too
restrictive. As Martin noted, this specification, as BFD base specification
in RFC 5880, is centered on protocol, not encapsulation (with exception of
the last paragraph in section 5.8 with details of IP/UDP over MPLS

> 3) Also given the traffic load multipoint BFD generates depends on the
> number
> of active session, and there is no feedback mechanism, I recommend to also
> limit the number of active session of MultipointHead type to a small number
> (per link).
GIM>> Perhaps we can recomend limit the overall number of active sessions
so that distribution can be decided by implementation and operator. I think
that text suggested by Martin clearly communicates such recomendation to be
added to the list in the Security Considerations section:
      The implementation should have a reasonable upper bound on the
      number of MultipointHead sessions that can be created, with the
      upper bound potentially being computed based on the load these
      would generate.