Re: Fw: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt

Greg Mirsky <gregimirsky@gmail.com> Fri, 28 April 2023 19: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 DDA04C1DF97B for <rtg-bfd@ietfa.amsl.com>; Fri, 28 Apr 2023 12:42:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.095 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfSackI0ngPz for <rtg-bfd@ietfa.amsl.com>; Fri, 28 Apr 2023 12:42:05 -0700 (PDT)
Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com [IPv6:2607:f8b0:4864:20::1134]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 153ABC1345E5 for <rtg-bfd@ietf.org>; Fri, 28 Apr 2023 12:42:05 -0700 (PDT)
Received: by mail-yw1-x1134.google.com with SMTP id 00721157ae682-54fae5e9ec7so3738917b3.1 for <rtg-bfd@ietf.org>; Fri, 28 Apr 2023 12:42:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682710924; x=1685302924; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ZA3kuDG0vz9hu5ZOgKLmEHuQNuWkMHeZJ2PbuJzPiLU=; b=EyGLy+OoMiE7zdfquqH1OFd9s3HcTAykS4Ocof0ZhmLqRtxo00HF5LOcNjYrci0jCo tWbwke3Y6050nJt5oCb6EHMuPdjajSnoAu9XgcH91vs9y/aosNIjj31I7i5S3R/ri+Jo nHTovSi7xtdywq6AFGnfUVIl23CbvyD44KirJgr/uoh7GdlRWJ9teu7j8aHBv0kpjmM7 EWmG6hZt+5PlIq8WphWog+EURKijdFns1fc28T5l2WlocajvcGilo2vTeNS2X4XmjXVy JwuiKXRgvOT4clBnp5XLNJwlL/BRwukZEx/IeiscLzfdnewAYwJ+gUalv6c9pvDKhvlB pNmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682710924; x=1685302924; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ZA3kuDG0vz9hu5ZOgKLmEHuQNuWkMHeZJ2PbuJzPiLU=; b=CnhpkpwL4okisacklCE78/A19ELwjPnZOWOs0xh/kDNdl0B2+R2fatOKoP6IwcH/Dq NVX143/Y8Do2Fehqyb3aqJ8tPuVQgbg0m4hRHmirK1lh90S0IFavADb8/cfBIzU2Tfza XtrRMFWLSmd0btccixEIqmOkin9BZomZ6crHlHCv7Zj7DmZnwem3ofinVmeYFxrlVZdK UmezabP5gYGdXuzUeADpsGu9p52oH7CThPes/EexWEYoznT4mPLer6bJKvaja0KyUVX0 ALZ81ej0JQTW3ac2B+tdcssMhLGnEFuU8UrgD0MU++UI+eUI/p9yLAlmpx4O3qUty4+y 0tjw==
X-Gm-Message-State: AC+VfDxfyL6p+Hk9FemiSTyCaEeqtuRLeArAzOBH0Ugi+BS0/gzXZU1m uqF58QXZag5a8e5qO3qDua8JA140QxNp/2eEp4V1On8KJ4Y=
X-Google-Smtp-Source: ACHHUZ4CSxBqxXpfspgok8Xk7gcSCXzqF3IxDQ9CuG6X+a/DqDzwL1Q3z4WCvWhACOWESe9yISckW8tt81R6OZU8gLI=
X-Received: by 2002:a0d:d817:0:b0:54f:315:68fa with SMTP id a23-20020a0dd817000000b0054f031568famr5031041ywe.22.1682710922042; Fri, 28 Apr 2023 12:42:02 -0700 (PDT)
MIME-Version: 1.0
References: <202304241016050852246@zte.com.cn>
In-Reply-To: <202304241016050852246@zte.com.cn>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Fri, 28 Apr 2023 12:41:50 -0700
Message-ID: <CA+RyBmWNYRpWVxGdeX39t+HUW_6BS=GbYCpy5hBkUxRMERR9ug@mail.gmail.com>
Subject: Re: Fw: New Version Notification for draft-ietf-bfd-unaffiliated-echo-07.txt
To: xiao.min2@zte.com.cn
Cc: rtg-bfd@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c4a0a705fa6aaa69"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/P-W200FL2rrUlPBxNIZXN4NeX6M>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 28 Apr 2023 19:42:08 -0000

Hi Xiao Min,
thank you for sharing updates. I've read the new version and have several
questions and comments.

   - It is stated in the Abstract:

   BFD Async procedures can be executed over the BFD

   Echo port where the neighboring system only loops packets back to the

   local system.

Is this conclusion differs from the definition of the BFD Echo function in
RFC 5880? If it is not, what is the value of such a re-statement? If it is,
it seems like an explicit attribution of this conclusion to this document
would be helpful.


   - Is the following a requirement or an observation:

   a network device must be able to quickly detect

   faults in communication with adjacent devices.

If the former, please capitalize the normative language. If the latter,
then it appears as an arguable view. Indeed, in some cases, local
protection is a viable option, while in other environments, e2e path
protection might be preferable.


   - Further, in Introduction, I read:

   Section 5 of
   [RFC5880] indicates that the payload of a BFD Echo packet is a local
   matter and hence its contents are outside the scope of that
   specification.  This document, on the other hand, specifies the
   contents of the Echo packets and what to do with them.

It seems to me that this draft is positioned as the definition of the
content of an Echo message and the processing of it, whether as an
unaffiliated or affiliated (RTC5880-style) function. Is that correct?


   - I hope you can help me understand the demultiplexing of Unaffiliated
   BFD sessions:

   Device A performs its
   initial demultiplexing of a Unaffiliated BFD Echo session using the
   source IP address or UDP source port, once the remote system echoes
   back the local discriminator, all further received packets are
   demultiplexed based on the "Your Discriminator" field only, which is
   conformed to the procedure specified in Section 6.3 of [RFC5880].


   - Does "initial demultiplexing" refers to the first BFD Control message
   transmitted in the Unaffiliated BFD Echo mode?
   - Considering that "device B would not intercept any received
   Unaffiliated BFD Echo packet", how "the remote system echoes back the local
   discriminator"?


   - A lengthy copy of a text from Section 4 of RFC 5881 seems like
   unnecessary:

   the destination address MUST be chosen in such a way as to
   cause the remote system to forward the packet back to the local
   system.  The source address MUST be chosen in such a way as to
   preclude the remote system from generating ICMP or Neighbor Discovery
   Redirect messages.  In particular, the source address SHOULD NOT be
   part of the subnet bound to the interface over which the BFD Echo
   packet is being transmitted, and it SHOULD NOT be an IPv6 link-local
   address, unless it is known by other means that the remote system
   will not send Redirects.

It seems that a reference to that section and something like "rules stated
in Section 4 [RFC5881] are applicable to the encapsulation of an
Unaffiliated BFD Echo Control message" could be sufficient.


   - What is the interpretation of "expected value"? It appears that none
   of these values are used, but are ignored. Right?
   - A zero value of the Required Min Echo RX Interval field per RFC 5880
   is interpreted as no support for the Echo function. But it is the
   recommended value. Although it is ignored. Thus, what is the benefit of
   initializing the field after all?
   - In the description

   Afterwards, the
   provisioned transmission interval is used.

What is the event that triggers the "afterward" transition?


   - With the high number of "this value MUST be ignored on receipt", "the
   Unaffiliated BFD Echo packet reuses the format of the BFD Control packet
   defined in [RFC5880]" seems like a severe overstatement.
   - Which event triggers the transition in

   *  Your Discriminator MUST be set to 0 initially, and then MUST be
      set to the same as My Discriminator echoed back.


   - What happens if Desired Min TX Interval, Required Min RX Interval,
   or Required Min Echo is not set to "the expected value"?

In conclusion. As we learned from the BBF Liason, the Broadband Forum is
not seeking standardization of the mechanism described in TR-146. Also, I
learned about the implementation of the mechanism described in
BBF's TR-146, and the authors are not interested in standardization either,
as, in their opinion, there's no externally noticeable behavior that
requires specification. So, I still don't see any value in standardizing
what is described in the document.

Regards,
Greg

On Sun, Apr 23, 2023 at 7:16 PM <xiao.min2@zte.com.cn> wrote:

> Dear BFD WG,
>
>
> A -07 revision of draft-ietf-bfd-unaffiliated-echo has been posted,
> attempting to address all the WGLC comments.
>
> The main updates are as below.
>
> * add a sentence to clarify that this document doesn't change the
> affiliated BFD Echo function.
>
> * change the order of section 2 "Updates to RFC 5880" and section 3
> "Unaffiliated BFD Echo Procedures".
>
> * add a summary on the Unaffiliated BFD Echo packet fields setting into
> the end of section "Unaffiliated BFD Echo Procedures".
>
> * change the text on IP address setting to the same as specified in
> section 4 of RFC 5881.
>
> * some editorial changes, e.g., s/BFD Unaffiliated Echo
> packet/Unaffiliated BFD Echo packet/g.
>
>
> Best Regards,
>
> Xiao Min
> Original
> *From: *internet-drafts@ietf.org <internet-drafts@ietf.org>
> *To: *Raj Boddireddy <rchetan@juniper.net>;Raj Chetan Boddireddy <
> rchetan@juniper.net>;Reshad Rahman <reshad@yahoo.com>;Ruixue Wang <
> wangruixue@chinamobile.com>;Weiqiang Cheng <chengweiqiang@chinamobile.com
> >;肖敏10093570;
> *Date: *2023年04月24日 10:09
> *Subject: **New Version Notification for
> draft-ietf-bfd-unaffiliated-echo-07.txt*
>
> A new version of I-D, draft-ietf-bfd-unaffiliated-echo-07.txt
> has been successfully submitted by Xiao Min and posted to the
> IETF repository.
>
> Name:        draft-ietf-bfd-unaffiliated-echo
> Revision:    07
> Title:        Unaffiliated BFD Echo
> Document date:    2023-04-23
> Group:        bfd
> Pages:        12
> URL:
> https://www.ietf.org/archive/id/draft-ietf-bfd-unaffiliated-echo-07.txt
> Status:
> https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-bfd-unaffiliated-echo-07
>
> Abstract:
>    Bidirectional Forwarding Detection (BFD) is a fault detection
>    protocol that can quickly determine a communication failure between
>    two forwarding engines.  This document proposes a use of the BFD Echo
>    where the local system supports BFD but the neighboring system does
>    not support BFD.  BFD Async procedures can be executed over the BFD
>    Echo port where the neighboring system only loops packets back to the
>    local system.
>
>    This document updates RFC 5880.
>
>
>
>
>
> The IETF Secretariat
>
>
>