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

Greg Mirsky <gregimirsky@gmail.com> Tue, 01 March 2022 16:42 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 3F7F23A0D27; Tue, 1 Mar 2022 08:42:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, 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 7jCSFy_28MUJ; Tue, 1 Mar 2022 08:42:06 -0800 (PST)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 BD1A53A0D36; Tue, 1 Mar 2022 08:42:03 -0800 (PST)
Received: by mail-ed1-x536.google.com with SMTP id h15so22792278edv.7; Tue, 01 Mar 2022 08:42:03 -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=OGZeFZYsfqA2r+ouTPn1JGagvIEE+2kLDu/H0WtVPh4=; b=jvG65Gao4d9QbvUyFX0MsDTuLsA/s1njR6JvVRzfqxaZHSfsh/03+/HCatVkrUxVbX nck/6HkiwnaSokPz37skJwCG+JhFTs+xf/OtH3Vv3uW1h6Mq+uCr1t0mMBF8hciM1KbN 0Rh9yzvF3xSogyeJ/mnCQPs/ZKcDWWIKmf9qXLY3dmyejoMOkuHCfaKNbC4dIrdev8HD NUYioi8g4Qn8BhboQL23GDRqzCBpb5Dt4Fi9wD9Xu7NbLYqf/POgjhLYLeBY3F0oZyF0 PlLNYeMQIjweogwaLdaxo64HnubTq+fb3xqQVUL0O30b6rrkUGcyk126UzsOM+nipe/G DevA==
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=OGZeFZYsfqA2r+ouTPn1JGagvIEE+2kLDu/H0WtVPh4=; b=3/XeBIu6+G3q6Wm3lnXE3PQI7iYKM3NqSFn0gPMek1nVsy1WC5MJml5p2gdstJHdz7 snYqIRH+5NDU5N9m8iSKEYKCC2fETDLNj74umUQUgAQPufMLhLHbf1kRL02RZk1DsZRW acDwmrkDKWPJKB4mde2hUJ+oUfalhDMo60S6eITOsf+70gSTIatfYSBAgyD6tZL7317U minQU2JcE0r/plaRQoR9jEQmY+xBkHuuxNBF5BxFKcBXNIGWE6dH1tFRcMVglULaQU2v 9mGKAW5csXMIrUS44bIt5AnJvDa2ERnBfSLpGvrCBCOwcQFiv6RtNEDeWcLu7Mz0pVkS Ryhw==
X-Gm-Message-State: AOAM530412g/ZIC+cfET4rfa/Wflh03frmuBzoxd2yKrS53DGPjPX0k3 ijMw5FC2jdZj4xywDPXVgib4fm0tRaE1ms/MsBg+JMvMhAI=
X-Google-Smtp-Source: ABdhPJwN6HQUJmlGeKtTXHoZVaCbUxeRLSUV2qyuLkLuURpzZDkzTpdiK0ll/fsgFLi55i4yegHj6sdZ9gI8KS8KGpQ=
X-Received: by 2002:a05:6402:518b:b0:412:d173:1e29 with SMTP id q11-20020a056402518b00b00412d1731e29mr25225725edd.302.1646152921566; Tue, 01 Mar 2022 08:42:01 -0800 (PST)
MIME-Version: 1.0
References: <CA+RyBmX8oAQFqJMjVhcj_78wYfrvz+afnSoP2-VjWyfCEunqmQ@mail.gmail.com> <381777191.1553826.1645979075642@mail.yahoo.com> <CA+RyBmWerxKKS6FCyaeQApuGkVT0JehrFToPBDf-ebrLkCSLnw@mail.gmail.com> <682D13B3-A62E-4A0D-9192-2D0D5844B86B@pfrc.org> <CA+RyBmUsse6pB72PG9MBmyD0sUK07GzfsossqvpCVn3Xim6TmA@mail.gmail.com> <20220301123834.GA31482@pfrc.org>
In-Reply-To: <20220301123834.GA31482@pfrc.org>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 01 Mar 2022 08:41:50 -0800
Message-ID: <CA+RyBmVx7U5SodPfTc5CHuL_sOtOzWeLAj2JDvspR5W+FMH+2w@mail.gmail.com>
Subject: Re: Some comments to the authors of draft-ietf-bfd-unsolicited
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: Reshad Rahman <reshad@yahoo.com>, rtg-bfd WG <rtg-bfd@ietf.org>, "draft-ietf-bfd-unsolicited@ietf.org" <draft-ietf-bfd-unsolicited@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000022d11705d92ad83e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/nWVYjBrraQBHBT24bB9Ekkodgl8>
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: Tue, 01 Mar 2022 16:42:11 -0000

Hi Jeff,
thank you for the clarification. Top-posting:

In the unsolicited draft:
- The passive side is not sending packets.
- It is waiting for an incoming session.

In my understanding, that is already defined in Section 6.1 RFC 5880:
   A system taking the
   Passive role MUST NOT begin sending BFD packets for a particular
   session until it has received a BFD packet for that session, and thus
   has learned the remote system's discriminator value.
If my understanding of RFC 5880 and the draft is correct, it appears that
the draft does not define any new local behavior but re-tells what already
has been defined in Section 6.1. Or the new behavior is that the passive
role might be not only for the specified BFD session ("particular BFD
session" in RFC 5880) but any yet unlearned BFD session? But that, in my
opinion, would require Security Considerations stepping up from
recommendations to requirements, especially when the draft includes the
multi-hop BFD scenario.

Regards,
Greg

On Tue, Mar 1, 2022 at 4:38 AM Jeffrey Haas <jhaas@pfrc.org> wrote:

> Greg,
>
> On Mon, Feb 28, 2022 at 09:34:19AM -0800, Greg Mirsky wrote:
> > it is also my impression that the concept described in the draft is
> > different from the Passive role as defined in RFC 5880. I think that
> needs
> > to be clearly explained in the draft and, it seems to be helpful to even
> > use another term to avoid any possible confusion.
>
> I spent some time reviewing the text of the draft and I don't think I agree
> with this statement.
>
> Section 2, Procuedures for Unsolicited BFD, has the following as its first
> paragraph:
>
> :   With "unsolicited BFD", one side takes the "Active role" and the
> :   other side takes only the "Passive role" as described in [RFC5880].
> :   On the passive side, the "unsolicited BFD" SHOULD be explicitly
> :   configured on an interface or globally (apply to all interfaces).
> :   The BFD parameters can be either per-interface or per-router based.
> :   It MAY also choose to use the parameters that the active side uses in
> :   its BFD Control packets.  The "My Discriminator", however, MUST be
> :   chosen to allow multiple unsolicited BFD sessions.
>
> Passive is covered in RFC 5880 section 6.1:
>
> :   A system may take either an Active role or a Passive role in session
> :   initialization.  A system taking the Active role MUST send BFD
> :   Control packets for a particular session, regardless of whether it
> :   has received any BFD packets for that session.  A system taking the
> :   Passive role MUST NOT begin sending BFD packets for a particular
> :   session until it has received a BFD packet for that session, and thus
> :   has learned the remote system's discriminator value.  At least one
> :   system MUST take the Active role (possibly both).  The role that a
> :   system takes is specific to the application of BFD, and is outside
> :   the scope of this specification.
>
> In the unsolicited draft:
> - The passive side is not sending packets.
> - It is waiting for an incoming session.
>
> I don't see a mismatch of expected behaviors.
>
> -- Jeff
>