Some comments to the authors of draft-ietf-bfd-unsolicited

Greg Mirsky <gregimirsky@gmail.com> Sun, 20 February 2022 22:09 UTC

Return-Path: <gregimirsky@gmail.com>
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 971683A0AB9; Sun, 20 Feb 2022 14:09:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 HyG7qWFE5pL6; Sun, 20 Feb 2022 14:09:18 -0800 (PST)
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2E0C3A0AC7; Sun, 20 Feb 2022 14:09:17 -0800 (PST)
Received: by mail-ej1-x62c.google.com with SMTP id vz16so28385532ejb.0; Sun, 20 Feb 2022 14:09:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=KK1oK3J0PLC6yzmYqw0zg5mohxMu2NWkHHZs0sIkCYo=; b=DEmCzQ2V+u6JEQNKLdfo+BzY0jL2NXF8dErmsBVRy2mkkjIIPw7lN055Jah/8rK3hS YpWVo864h4ERQCCoDzkYX+JCjA40tCnGVdz0PCa0DUbs2Jnxj1USoukvGn4qBg8EjLP8 m9EM+0ysLbOzAkUSlhwwRbIke7hA0rjcKfCVqaddYQXfPwSBHr3OxSJi1ktwXvo1jIRq PHtqAcn2zExVkh6J2KZJM5iglIMeMYA8Tn6lfr8gj+2Ng5VidZe74+nEU/MkoHvPko5l 6hxfF9fqvE2PMDDIrytt1E37EJZmt8C6c0gqLx9iMu3vDJEpK4AbnJOEI8Vm0B/xHKcY Y38A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=KK1oK3J0PLC6yzmYqw0zg5mohxMu2NWkHHZs0sIkCYo=; b=VvaUk1iAoj7VGQvZ7mZahr19ViOG6VoyXBzj2vhPEVtkH18/SutWzIuOvTBE3irJfY sJiS4o77eMNvvw1WTGk1yqWFMRDNfX7l48jC7vENE4E5iSXJklNZF1l1t4Cgz03AIJCU oCy6jX6WyjcekPWAwE4eQPT7naM5K/kbVZXVD4L25SPIfz8NLmEWacODFLCuIpw05LEm ajuAudLxXXklcBzlhJV0iNaBh3rpvmur+RrNO7gZYUVOfWJREaVUKSMSOHY0BVNFBdhF B0OLe7GBhh5/txGKz0wwPtCn842zpdltJKvr6ONV0/nTV4NZGziMvU42CBOsVXQlwyin 6VBw==
X-Gm-Message-State: AOAM533kkDPoLOp6mBw+w8YdBdyF/LhKkJt+x2kvyOGK8hiE1MyRTJzv CceI58fqhuSApILXY39kcS3lwlMJ8T0nkdEQ6LEhdRNVriE=
X-Google-Smtp-Source: ABdhPJyRfCHwFyn7GVeWevMJEuJDZX8onLXBTvrOZyk87f8FLHzONg2ilBaNrIBa4kzSW0tz6zXQqORhji1fkm6Jbz8=
X-Received: by 2002:a17:906:2695:b0:6ce:f9c:b476 with SMTP id t21-20020a170906269500b006ce0f9cb476mr13820453ejc.235.1645394955021; Sun, 20 Feb 2022 14:09:15 -0800 (PST)
MIME-Version: 1.0
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Sun, 20 Feb 2022 14:09:03 -0800
Message-ID: <CA+RyBmX8oAQFqJMjVhcj_78wYfrvz+afnSoP2-VjWyfCEunqmQ@mail.gmail.com>
Subject: Some comments to the authors of draft-ietf-bfd-unsolicited
To: draft-ietf-bfd-unsolicited@ietf.org, rtg-bfd WG <rtg-bfd@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000cf32a705d87a5dd3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/ji6QdrWo1HIz9UZ-rCefnFA5pBM>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 20 Feb 2022 22:09:21 -0000

Dear Authors,
I've read the current version of the draft and have several questions.
Greatly appreciate your consideration and feedback.

   - The document uses the normative language and is on the Standard track.
   At the same time, the behavior of the passive BFD system is entirely local
   and has no impact on the active BFD system. It appears like the use of
   normative language describing the implementation of the passive BFD system
   is unnecessary. It appears that the Informational track is more appropriate
   for this specification.
   - It appears that the YANG data model allows the BFD unsolicited only
   for the single-hop BFD. What, in your opinion, prevents allowing it for
   multi-hop BFD?
   - In the following text:

   The "Passive role" may change to the "Active role" when a local

   client registers for the same BFD session, and from the "Active role

   " to the "Passive role " when there is no longer any locally

   registered client for the BFD session.

it is not clear to me as to which BFD session is the reference "for the
same BFD session". Is that for the session that is already in the Up state?
Or something else?


   - Two recommendations in the Security Considerations section:

   o  Apply "access control" to allow BFD packets only from certain
      subnets or hosts.
...
   o  Use BFD authentication.

leave some serious doubts that the proposed model does bring any
operational simplification compared to explicitly configuring BFD on both
systems (especially to use authentication).


Regards,
Greg