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

"Mirja Kuehlewind (IETF)" <> Wed, 01 August 2018 11:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B477A130E6A for <>; Wed, 1 Aug 2018 04:59:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); domainkeys=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2YCCK-SrkVlW for <>; Wed, 1 Aug 2018 04:59:43 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 032F7130E78 for <>; Wed, 1 Aug 2018 04:59:42 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default;; b=aGd9qfQz6tEwM48lRb0/odFmF6497IXfZWS1ccvZ7YyeE20ZyBpFaB50gXNaMxDBacyink9x1UKiS7cqcYxa7KZkqf90Y1uPhSulcI+SGVeac4FKCMDCB1BybS6+flsdNKVT+5dZLBFqPSbKOrtXUx9RsS68Jo0k8tj+qT3ksvw=; 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 1060 invoked from network); 1 Aug 2018 13:32:59 +0200
Received: from (HELO ? ( by with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 1 Aug 2018 13:32:59 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Subject: Re: Mirja Kühlewind's Discuss on draft-ietf-bfd-multipoint-18: (with DISCUSS)
From: "Mirja Kuehlewind (IETF)" <>
In-Reply-To: <>
Date: Wed, 01 Aug 2018 13:32:58 +0200
Cc: Greg Mirsky <>, Reshad Rahman <>,,, The IESG <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Jeffrey Haas <>
X-Mailer: Apple Mail (2.3445.9.1)
X-PPP-Message-ID: <>
Archived-At: <>
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Aug 2018 11:59:45 -0000

Hi Jeff,

sorry for the very late reply. Please see below.

> Am 11.07.2018 um 02:13 schrieb Jeffrey Haas <>:
> Mirja,
> On Mon, Jul 09, 2018 at 04:01:22PM +0200, Mirja Kuehlewind (IETF) wrote:
>>> Am 05.07.2018 um 21:27 schrieb Greg Mirsky <>:
>>> 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 guidance.
>>> Also, consider two proposals to use mpBFD in VRRP and PIM-SM 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 case.
>> I understand that this makes failure detection harder, however, the BFD base spec has a feedback mechanism that can be used to limit the rate, e.g. if the receiver is overloaded. This is not the case for multipoint BFD and therefore a higher interval than 1 sec is not permitted by the BFD base spec.
> Let me pose the issue a different way: 
> What is the general text the IESG wants out of multicast senders (ASM,
> SSM, e.g.) with potentially passive receivers to avoid such overload?

The IETF’s recommendation for this case in RFC8085 section 4  which refers to section 3.1.3 for your use case respectively. Section 3.1.1 recommends to not send more then one package per 3 sec. The BFD base spec already has a lower limit of 1 sec. Given this is a BFD extension this is the specified limit this spec needs to align to. If you want to send at a higher rate, RFC8085 recommend to implement some kind of congestion control.

>> However, even if you update/remove the restriction, you would still need to specify additional safety measures to ensure that no BFD packets overflow the whole network or leak to other networks, as there is not feedback what clearly indicated that there is a receiver listing at the other end. 
> What is the text the IESG wants out of multicast signaling protocols and
> senders  to avoid this concern?

You would need to add some kind of congestion control/feedback multicast receiver to the sender to reduce the rate or determinate the connection to the congested receiver (circuit breaker).

>>> 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. 
>> More guidance is needed to specify what „reasonable“ means here. 
> What is the text the IESG wants out of multicast signaling protocols to
> restrict the numbers of joins to either a source in source-specific
> protocols, or to rendezvous points in such mechanisms?

The spec could specify a default value and explain when this default value is applicable or in which scenarios the default may be changed based on the given network conditions.


> -- Jeff