[RTG-DIR] Rtgdir last call review of draft-ietf-bfd-unsolicited-09

Henning Rogge via Datatracker <noreply@ietf.org> Fri, 14 January 2022 12:29 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: rtg-dir@ietf.org
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 203F13A235A; Fri, 14 Jan 2022 04:29:48 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Henning Rogge via Datatracker <noreply@ietf.org>
To: rtg-dir@ietf.org
Cc: draft-ietf-bfd-unsolicited.all@ietf.org, last-call@ietf.org, rtg-bfd@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.42.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <164216338807.16153.9875928342258760333@ietfa.amsl.com>
Reply-To: Henning Rogge <hrogge@gmail.com>
Date: Fri, 14 Jan 2022 04:29:48 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/vXlsftYBiMMUH3_p0japqt46BJM>
Subject: [RTG-DIR] Rtgdir last call review of draft-ietf-bfd-unsolicited-09
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Jan 2022 12:29:48 -0000

Reviewer: Henning Rogge
Review result: Has Nits

Hi,

the RTGdir has asked me to do a review on draft-ietf-bfd-unsolicited-09 and I
think its ready for publication.

The concept of passively listening instances reacting on demand should simplify
deployment of BDF, especially when switching between active and passive role
can be done automatically decided on local demand. As far as I could see from
RFC 5880 BDF signals its state (active or passive), so it cannot accidentally
have two passive sides just reacting to each other (thinking the other as
active).

I have two nits with the document...

1st, I would like a clarification which/how many (all?) security measurements
you consider mandatory... if you (as an example) run the protocol in a trusted
environment, you might be able to skip authentication... but maybe using the
TTL to keep the protocol "linklocal" should still be mandatory.

2nd, I would suggest writing out the full name "Bidirectional Forwarding
Detection (BFD)" once in the abstract just to make sure nobody confuses the
acronym.

Henning Rogge