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

Mirja Kühlewind <ietf@kuehlewind.net> Tue, 03 July 2018 18:31 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: rtg-bfd@ietf.org
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B93130DC0; Tue, 3 Jul 2018 11:31:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Mirja Kühlewind <ietf@kuehlewind.net>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-bfd-multipoint@ietf.org, Reshad Rahman <rrahman@cisco.com>, bfd-chairs@ietf.org, rrahman@cisco.com, rtg-bfd@ietf.org
Subject: Mirja Kühlewind's Discuss on draft-ietf-bfd-multipoint-18: (with DISCUSS)
X-Test-IDTracker: no
X-IETF-IDTracker: 6.81.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153064270085.5078.5189673902650964259.idtracker@ietfa.amsl.com>
Date: Tue, 03 Jul 2018 11:31:40 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/_ql1AcwVYZKihNtbFw8ncMXQKE4>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.26
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, 03 Jul 2018 18:31:41 -0000

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 https://www.ietf.org/iesg/statement/discuss-criteria.html
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:
      [...] 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).

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

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