Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)

Greg Mirsky <gregimirsky@gmail.com> Tue, 04 August 2020 22:39 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 194483A1109 for <rtg-bfd@ietfa.amsl.com>; Tue, 4 Aug 2020 15:39:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, 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 gRHKPlvQ5lMt for <rtg-bfd@ietfa.amsl.com>; Tue, 4 Aug 2020 15:39:07 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 EB1583A1010 for <rtg-bfd@ietf.org>; Tue, 4 Aug 2020 15:39:06 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id v12so15110522ljc.10 for <rtg-bfd@ietf.org>; Tue, 04 Aug 2020 15:39:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qv8/LvnlWf1IQrlEUqRIsmZ6fbqRLkWvP2s/fHvoiKo=; b=BsS4uoScKLNjNRcphOpWnCIZPGc/0wadF0GY+ZXtLsxYlBT7mMvg/QthU7z3w+siWb xNLvp7i/ciYVanIQqm5JcABXK/S2S3V+94y9ulMQqSZUXWb4jVSKR+VehQ/Q5mRm+9qw vJI88cIb81Fw6s9HkabzjNIau3pK7Gx9GTc7KIpKalFf3dFfUKqRKlbZJdEJFqfN0ZTk 6pditF1DB1jRCMfcow8jrdegKSw139JPFCACopZuxa/styRgNFJg8zOyBNCLSPHPKhNq CRfFYnabZDR6vBzu7loGdUhlGohE4787+7hWJa9geYGH5MXtGDHL+Wk5DtMFTQnEn4UP uEAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Qv8/LvnlWf1IQrlEUqRIsmZ6fbqRLkWvP2s/fHvoiKo=; b=Or0/BToRUVJ2vP6DCL345RTJW1HJGBir380iasyTiyKPrtGQn0WTnSP8BxWvJglGwX mdf/nLGjrxS7wf/TXSiP1Q5hreADzvWUx8fWy7jn9PeIfIHmI8pIiKUGt4qF2vuwqYI9 P2IE0cDZ5LWDXQgH38ddrE/TlXw/ZDgwLOcySf7qyNSn6su41QICByCaZpLuxAofvVY5 Yk17W8JC0ITySzEAtU5m3OSiOTh3r6uBalPXFl83EEm7dNsAx0mA15DwaRt5a1u+PZh0 iGdHUmUX1+u4bF0LX9FV9wBzwU85iSW9zlH3nRDH4PwXgUzwCUficMedDMtvK6spO/0B myJw==
X-Gm-Message-State: AOAM533IBeuj4PAHcfgr3sga4kjRt3Vi2aTlYAFsOv2kaQTjCd19i5uk BuWa3B3iAvyY2D/5YDTvbcOJzVpHZF/pbdFtnI3wiyv8
X-Google-Smtp-Source: ABdhPJxCS50m7+8daUiabTqt+ejKe9aW73spKMuSTVknZqG+Vl5mo6UYcMXdB2r5iiFD36u5OreUMTidKDa895/SuuE=
X-Received: by 2002:a2e:87c4:: with SMTP id v4mr31786ljj.8.1596580744837; Tue, 04 Aug 2020 15:39:04 -0700 (PDT)
MIME-Version: 1.0
References: <20200804132122.GC31729@pfrc.org>
In-Reply-To: <20200804132122.GC31729@pfrc.org>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 4 Aug 2020 15:38:53 -0700
Message-ID: <CA+RyBmWtGHyDd01-53Gx_JSqKT08Y0qPqkMPVOfSZR6DbgtdEw@mail.gmail.com>
Subject: Re: Working Group Last Call for draft-ietf-bfd-unsolicited (ending 16 August, 2020)
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: rtg-bfd WG <rtg-bfd@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000026be7b05ac14ec1d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/naYc-qtNmf8ZH2sRF8S76DqzgYc>
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, 04 Aug 2020 22:39:09 -0000

Dear Authors, et al.,
thank you for this well-written document. The mechanism described in the
draft is, in my opinion, useful and will save considerable efforts of the
operator. I have several questions and comments listed below:

   - Would the introduction of Unsolicited mode make this draft updating
   RFC 5881?
   - I didn't find any new values of BFD parameters that distinguish an
   unsolicited BFD session from the "classic single-hop" session. Do you think
   such a distinction could be useful to an operator?
   - In Section 2 stated

   On the passive side, the "unsolicited BFD" SHOULD be configured
   explicitly on an interface.

Does that imply that it MAY be configured node-wide? I think it would be
helpful to explicitly list the alternative option.


   - The fourth paragraph in Section 2 explains the handling of the first
   BFD control packet with Your Discriminator == 0, i.e., "it does not find an
   existing session with the same source address". What happens if the
   matching BFD session has been found?
   - A BFD session then created "based on the source address and
   destination address". Does that mean that there will be only one session
   with the same source address despite different destination addresses
   listed? If that is the case, could the BFD session be associated only with
   the source IP address of the received BFD control packet?
   - Between creating the BFD session (above) and

   It would
   then start sending the BFD Control packets and perform necessary
   procedure for bringing up, maintaining and tearing down the BFD
   session.

the local BFD system assigns My Discriminator to the session. Though it is
standard (RFC 5880) step, it might be useful to mention it.


   - Does "an established BFD session goes down" mean the state is Down and
   only Down or it also includes AdminDown state?
   - Furter stated

   the
   passive side would stop sending BFD Control packets and delete the
   BFD session created until the BFD Control packets is initiated by the
   active side again.

Probably some normative language be helpful to replace "would". And is the
stop applied immediately or after some grace period? The same question
about the deletion of BFD parameters and the FSM (probably this is left to
the implementation).


   - I'd admit got confused by the last paragraph in Section 2:

  The "Passive role" may change to the "Active role" when a local
   client registers for the same BFD session ...

Is it normative MAY? Does that mean that the unsolicited BFD cannot be in
passive role if it has a local client registered? But what I wonder is how
these transitions affect the operation. What happens if both BFD systems
are passive after changes in the clients registered? Or both are active?


   - Section 5.1 appears to only RECOMMEND setting TTL to 255 while RFC
   5881 says that TTL MUST be set to 255. What could be the case for not
   setting TTL to 255?
   - Nits:
      - s/"Discriminator"/"My Discriminator"
      - s/does not initiates/does not initiate/
      - s/"remote-discriminator"/"Your Discriminator"/

Regards,
Greg

On Tue, Aug 4, 2020 at 6:10 AM Jeffrey Haas <jhaas@pfrc.org> wrote:

> Working Group,
>
> https://datatracker.ietf.org/doc/draft-ietf-bfd-unsolicited/
>
> With apologies to the authors of BFD unsolicited, this document is past due
> for Working Group Last Call.  The primary holdup on the document had been
> last minute interaction with the RFC Editor with regard to its impact on
> the
> BFD Yang model.  That work had completed some time ago.  (The Yang model,
> however, is still lingering in MISREF state.)
>
> This begins a last call period ending on 16 August.
>
> Please send your comments to the mailing list whether you think this work
> is
> ready to advance to the IESG or not.
>
> -- Jeff & Reshad
>
>