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

Greg Mirsky <gregimirsky@gmail.com> Mon, 28 February 2022 15:34 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 B2F463A12C0; Mon, 28 Feb 2022 07:34:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 qyvjQuMFB6Ip; Mon, 28 Feb 2022 07:34:32 -0800 (PST)
Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (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 AB2263A12C9; Mon, 28 Feb 2022 07:34:31 -0800 (PST)
Received: by mail-ej1-x632.google.com with SMTP id vz16so25653354ejb.0; Mon, 28 Feb 2022 07:34:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eVvwv1fc1ilEwV5y4Q8VY+PxagdWWWov3jT+79tmgSI=; b=iCuwNGDmObtIsLgJB/SrkOPakzJrHB6KDp/FQ1VOdfh81vQcFeS0z1S1VUkRfOg7xm mbbI6aE1aQwZW4D8aA0Xcf28urgYjx6JvrIGAJMvOl55yAcugeNyqhsBMoE3TiRWRD6P Z3c3XozRJFScV7JqghKkk7ojQrbqY4AeUKhi1ofU8SawtbTHMLOaUwmaCyPtZqIlGv8I NL5CwQxn91DZzzaIh8Lz8UsGxgDQcchOivFrAuaUxUgkDJrUhSPYc3+qNwWYwuz7KEN7 I3X6xithT650l2ZGUrqyhxkdLZ02rGRUN5RJRVYvfZo66mGmSvilftN/ye1u9uYzWtLp uwSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eVvwv1fc1ilEwV5y4Q8VY+PxagdWWWov3jT+79tmgSI=; b=e8u5YxPjRJsz3jE1n9WeSmXUJX/E/IAumLl6y5lbi+bGy7GKtuJVr4Suc64Dzp/NOg V7m1YaJGybMZvIyOE4JvN8U+biP8A4rcEeEm43eUz9MhplvcNUggKQw1e1JMANWCzoVl dxgHY/4/9mFUESQNqVCaHC4feCkDsH90LL3lxzpVSZkAgGp7YsMlQmXDUxLp4XcYhYOb lgIXjgaBv71rIsC1m+1ZeajXGxJjeSS6hkHznes6+TeMZWQVAgdGSlBjSeAg7Stg3NrQ +Pr/8H4LrDTjtnuGXc1QaRFN6uO2QPZ5KN5olPD4cMIhP2CmZ4UyChz7KN0Bp+z3D3Ca Lo7w==
X-Gm-Message-State: AOAM531pFLqwm+ctLRQQV6bD/TtK1S87ZolA7OGm1bEtNxKkMUIHBwRg 9fkSH1DGLCJP3TiaGXfYfuJCh363RlqUnZ4a1CiHkRGA
X-Google-Smtp-Source: ABdhPJyUBq+9+K253hD3T5apBq9imTuArpEyc6/XsJoBxm7ytEDxAYkIp2BIhmxgPmE21kpUVvQcghO9iHg8Vh+/U20=
X-Received: by 2002:a17:906:2ed1:b0:6b6:bb09:178c with SMTP id s17-20020a1709062ed100b006b6bb09178cmr15946801eji.382.1646062469547; Mon, 28 Feb 2022 07:34:29 -0800 (PST)
MIME-Version: 1.0
References: <CA+RyBmX8oAQFqJMjVhcj_78wYfrvz+afnSoP2-VjWyfCEunqmQ@mail.gmail.com> <381777191.1553826.1645979075642@mail.yahoo.com>
In-Reply-To: <381777191.1553826.1645979075642@mail.yahoo.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 28 Feb 2022 07:34:18 -0800
Message-ID: <CA+RyBmWerxKKS6FCyaeQApuGkVT0JehrFToPBDf-ebrLkCSLnw@mail.gmail.com>
Subject: Re: Some comments to the authors of draft-ietf-bfd-unsolicited
To: Reshad Rahman <reshad@yahoo.com>
Cc: "draft-ietf-bfd-unsolicited@ietf.org" <draft-ietf-bfd-unsolicited@ietf.org>, rtg-bfd WG <rtg-bfd@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c6889f05d915c844"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/zTPh_x2sjyEUK4i8TQ7UxRoWpoo>
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: Mon, 28 Feb 2022 15:34:34 -0000

Hi Reshad,
thank you for clarifying things for me, much appreciated. I have several
follow-up notes logged in-line below under the GIM>> tag.

Regards,
Greg

On Sun, Feb 27, 2022 at 8:24 AM Reshad Rahman <reshad@yahoo.com> wrote:

> Hi Greg,
>
> Thanks for the review and comments. Please see inline.
>
> On Sunday, February 20, 2022, 05:09:22 PM EST, Greg Mirsky <
> gregimirsky@gmail.com> wrote:
>
>
> 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.
>
> <RR> This was debated extensively ~15 months ago. I'll defer to Jeff H and
> John S, but the last email I have on this is the following:
> https://mailarchive.ietf.org/arch/msg/rtg-bfd/vOMZl9ucZwNKu5_MHHti-4ImOjQ/#
>
>    - 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?
>
> <RR> As per reply to Gyan, we will extend the document + YANG to support
> multi-hop.
> https://mailarchive.ietf.org/arch/msg/rtg-bfd/567Ey36geGC427ulnAqcWFag3xc/
>
GIM>> Thank you, will read and follow up on that thread.

>
>
>
>    - 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?
>
> <RR> It is for the already created session. So a session is created in
> "passive" state via BFD unsolicited procedure (no local client or config
> for it). After that a local client wants the same session (e.g. because BFD
> was enabled under a client), the BFD session becomes "active". We'll see if
> we can make this clearer.
>
> GIM>> Thinking of what might had confused me, I feel that it may be the
use of "passive role" that was already described in Section 6.1 RFC 5880
<http://The state of New Hampshire removes ALL Russian liquor brands from
the state-owned (yes, alcohol is a state monopoly in NH) stores.>. What do
you see as the distinction between the Passive role behavior as described
in RFC 5880 and the passive role described in the draft?

>
>
>    - 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).
>
> <RR> Good point. I think it depends. e.g. if BFD authentication is already
> in use, this is not an issue.
>
> GIM>> And a thought on the Security Considerations.  All remedial steps
related to the security of BFD protocol are recommendations. What if an
implementation does not support any of them? Would it be reasonable to have
some as requirements?

>
> Regards,
> Reshad.
>
>
> Regards,
> Greg
>