Re: Adoption call for draft-cw-bfd-unaffiliated-echo (ending 16 August, 2020)

Greg Mirsky <gregimirsky@gmail.com> Wed, 05 August 2020 02:51 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 42F963A125D for <rtg-bfd@ietfa.amsl.com>; Tue, 4 Aug 2020 19:51:27 -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 3PFE70_YEQLw for <rtg-bfd@ietfa.amsl.com>; Tue, 4 Aug 2020 19:51:25 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 2957B3A123A for <rtg-bfd@ietf.org>; Tue, 4 Aug 2020 19:51:25 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id 185so35692852ljj.7 for <rtg-bfd@ietf.org>; Tue, 04 Aug 2020 19:51:25 -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=RY9HHLkw0cZPLUV79e2oJcdMBgfeRB/czQY2ZRFWnrE=; b=GDQDJxHnIkpUF/qJCHwI1hnm25aH8xka8DwfAB0mb2N+5iDBahL7BBgqbkgAei+wV+ AwfW2mhh4auXr/MZ5/t2ZxIKYT+sztNbsW8G6m2t8yDfdoKPby1sospQcm+DL5U2VYC6 cieHdHXZyqIXZBPlFBQRYowwXbQanEpCDb/5neDp5n5SZ/p4XQbAtXZE/UkWjQLjbq2b nd9ZSagDkhE/jcvp/I4MA3wkqJ413ggChFAqWCdBIzHVXVJSG2kXsjdXEfunKp0MJauw kSdKNZ9504EGsHHRTVCldLEi0w0I15/iVTSDk2QW/AO2RdGmkIXZzxJ7G1uDoHPYVVKa IwOw==
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=RY9HHLkw0cZPLUV79e2oJcdMBgfeRB/czQY2ZRFWnrE=; b=Txyl5vTPmxRfNlb2+cGe5JidZib05DXhxpgxxI+naMIGrGQjm0H7mwtnmREgkpL6Oa m3qvmorZ/CO6qv8TOZ+kgPcHMd5p9DoYQSsq0ZRQZ7FA3dXQ/xgvS9azRahw3+3XHlwI eacTozPHM0TmQOFyQSSzhyjqiZblDf0Y0+eFnT9FcTAkGAijEaf8zpLSTzzsDU4QKUT/ dYFqwXL9AkgJQT5i5ZR8OTJ7BQYz1wwjcveP4nPWcj81el8p92u15bDAgBJTQtFPm8QH zjaDWQr/y8ZVv+vmteCUB1TIdXQpsAfU43vwiPOz0IH4OA7reCiVmSwgNcHPsksh/4cG fCLA==
X-Gm-Message-State: AOAM530OPlMiBT3A0FIpbocCUTjNGONjLhtdpPTqLbwN2iE3ae32U727 13SujAtek4Ey93Hmt1pod9C6hzpkkkr6xf31Syo=
X-Google-Smtp-Source: ABdhPJzc/z140jg+tEqoTW/Qlel4NNffJze0Sk+LlTF4wi7A8beaEE1Zf6uQYKpskhBBYS8Gx8LIcmfXHmELeSbuVFU=
X-Received: by 2002:a2e:9bc1:: with SMTP id w1mr388411ljj.288.1596595883212; Tue, 04 Aug 2020 19:51:23 -0700 (PDT)
MIME-Version: 1.0
References: <20200804131549.GA31729@pfrc.org>
In-Reply-To: <20200804131549.GA31729@pfrc.org>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 4 Aug 2020 19:51:12 -0700
Message-ID: <CA+RyBmWmsQpAOm-SK2qaKQnnVVEVQ_Mad0c0L+n0rqPxg2FQpg@mail.gmail.com>
Subject: Re: Adoption call for draft-cw-bfd-unaffiliated-echo (ending 16 August, 2020)
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: rtg-bfd WG <rtg-bfd@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000078020f05ac187295"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/q4zgWQAT_fTJsHJA7QLxh_DAC5Y>
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: Wed, 05 Aug 2020 02:51:27 -0000

Dear Authors,
thank you for the well-written document. I have several questions and
comments that are listed below:

   - An Introduction, states that

   it is not clear whether the devices
   using echo function need to support the full BFD procotol, including
   maintaining the state machine of BFD session as described in
   [RFC5880] and [RFC5881].

I think that Section 6.8.9 in RFC 5880 explicitly states:
   BFD Echo packets MUST NOT be transmitted when bfd.SessionState is not
   Up.  BFD Echo packets MUST NOT be transmitted unless the last BFD
   Control packet received from the remote system contains a nonzero
   value in Required Min Echo RX Interval.

Could you point to a statement in RFC 5880 or RFC 5881 that updates the
requirements above?


   - Based on my understanding of the BFD Echo function definition in RFC
   5880, the use case described in section 6.2.2 TR-146 is not based on the
   standard use of the BFD Echo function.
   - Section 2 describes the behavior of a BFD system in the Unaffiliated
   Echo mode. Would there be a BFD session created? If yes, which BFD state
   variables must be set?
   - Regarding the encapsulation of the BFD Echo in unaffiliated mode
   section 2 states

   device will send the BFD echo packets with the IP
   address destined for itself

Which address will be used in IPv4 and IPv6? Which address will be used as
the source IP address? And as we are discussing the IP encapsulation, which
value be set in the TTL/HL field?


   - in the second paragraph, Section 2 stated that

   the device that does not support
   BFD protocol immediately loops back the packet by normal IP
   forwarding, implementing quick link failure detection
It appears that the quick link failure detection is on the side of the
system that does not support the BFD protocol. Is that right?


   - Further, you describe that system A (Fig.1) "rapidly detect a
   connectivity loss to device B". How in the unaffiliated BFD Echo mode is
   controlled the rate of transition for the BFD Echo packets? RFC 5880 allows
   the remote system to use Required Min Echo RX Interval for that. Which
   mechanism would you recommend in the unaffiliated BFD Echo mode?
   - Additionally, how does system A detects a failure? RFC 5880 in Section
   6.8.5 gives a hint:

   a sufficient number of Echo
   packets have not arrived as they should, the session has gone down
but the mechanism to determine when an Echo packet should arrive and by
that when it is lost, as I understand the text in the section, is outside
the scope of RFC 5880. Do you have a recommendation on how system A
determines that a packet is lost?


   - nits:

s/BFD procotol/BFD protocol/3
s/capablity/capability/

Regards,
Greg


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

> Working Group,
>
> https://datatracker.ietf.org/doc/draft-cw-bfd-unaffiliated-echo/
>
> At the virtual IETF 108, Unaffiliated BFD Echo Function was presented.
> This
> is a followup of a presentation given at IETF 106.
>
> The authors have indicated they would like to have this work adopted by the
> BFD WG.  This begins the adoption call ending August 16.  Please respond to
> the mailing list with your thoughts on this adoption.
>
> It should be noted that this document overlaps work in the Broadband Forum
> (BBF) document TR-146.  As noted in the presentation, the BBF document
> lacks
> some clarity and also doesn't discuss interactions with BFD
> implementations.
> This draft has good clarifications with regard to implementations of this
> mechanism when the a BFD Echo-capable implementation is used.
>
> This raises two points to consider as part of adoption:
> - This document with its current goals would Update RFC 5880.
> - The status of this document would need to be Proposed Standard.
>
> -- Jeff
>
>