Re: Comments on draft-ietf-bfd-unaffiliated-echo-08

Greg Mirsky <gregimirsky@gmail.com> Tue, 26 September 2023 13:46 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 B11CEC17EB59; Tue, 26 Sep 2023 06:46:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 PUXWV6b0w0bg; Tue, 26 Sep 2023 06:46:31 -0700 (PDT)
Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (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 4AAB8C1519A9; Tue, 26 Sep 2023 06:46:26 -0700 (PDT)
Received: by mail-yb1-xb34.google.com with SMTP id 3f1490d57ef6-d81dd7d76e0so10060960276.1; Tue, 26 Sep 2023 06:46:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695735985; x=1696340785; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=PWmTQbHY+CoMNl3+oNWJ7Z84Fqgjk2z3c9Uucmsn4Zc=; b=gfA9y/qvFZHuWKRFDN3J/iZT9fqccuvyeyfQtGfz5On2sXpoGDLDMXu5tuCcFoC0z4 c/b95hH6PM14PKdKbSjk8EHeyVPo3ipBSi3zJCG+1gbIA1JvR3K8M1CscZMffMl1HA/A HW9Ns/tLoqyPyuCnD7hYT5c86OOelHvjV1WKBfjYCwLVS5CO0PRj8e/NU91LfTPIIiE5 5y1YAul8hVrumt+YLZTkFngFvHZ5sOlINOrfh3ARlBoP+3ya/p13Tjyjepo3OkpAaU2I t+zc/FCPMHtcJp3SI/ZdMBYhygRLaktk+dWq57RFArIms6xclRt2Ihk9fUR3MjXXuX0m oghQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695735985; x=1696340785; 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=PWmTQbHY+CoMNl3+oNWJ7Z84Fqgjk2z3c9Uucmsn4Zc=; b=vuDRZ8QnhqWK00afLy4fZs0+IiZLaZ6rOxcYXx1ajjQH85kHYoB6tGxYS8SQfrf9f3 4TYEcwzlw9EYnLu18PjVfmfeMnSCcW7Lm3wfJowGprHA5VSs9sR1ulsIf9Q6cEYtx1uZ 3GIFNh1KL+ZahxCGMo9mjhvpnw3x1unISXHwSWcOWH2MeIbnUs6/Gvzt6tiN90sit+d5 NbwykkJpAFQjRwvKxsXPUYoWfzvz+tl4rT8qxtUT9kvRiW9JfZtUjxrh6tkuzucPxN0G tXEUe+3hk826cNWYSeLXqCqgG2ZtQpNa3+qP7uTDK/kB0ej3GXDfxTO/SmBnNGDrX2hZ CiZw==
X-Gm-Message-State: AOJu0YzjsNGHzW1yQePmPrQeKNhF9CxQMXJE+x2iwu5nobTQgX0Tv3Iq MsKAybH+MFNsKLSJQXGF5WvhLQtZVemFCwCbVME=
X-Google-Smtp-Source: AGHT+IGjNYiiXCnFBIXSjDerC4XUiU7oVq+7MojPz/7ZHwIEzY9UWthBlSKKINgCLx1xxPxb9w1UT1Plr9YFQRiOng8=
X-Received: by 2002:a5b:98c:0:b0:d81:8c74:8f89 with SMTP id c12-20020a5b098c000000b00d818c748f89mr7740294ybq.11.1695735984838; Tue, 26 Sep 2023 06:46:24 -0700 (PDT)
MIME-Version: 1.0
References: <CAH6gdPxwHAjRqD=40iuxP_ZSjaX0XGQLj+1fJ08cn-HgR7M=5w@mail.gmail.com> <202309261528005567756@zte.com.cn> <CAH6gdPzoSy=XufqsTujq9aEqxGA3ZHa+L=tiDO+zQK3xRjL-Dg@mail.gmail.com>
In-Reply-To: <CAH6gdPzoSy=XufqsTujq9aEqxGA3ZHa+L=tiDO+zQK3xRjL-Dg@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 26 Sep 2023 06:46:10 -0700
Message-ID: <CA+RyBmVZPcXymMJ4Pngwz69gp4Um32YGtyYWUoJ6Gbpe2nwkdA@mail.gmail.com>
Subject: Re: Comments on draft-ietf-bfd-unaffiliated-echo-08
To: Ketan Talaulikar <ketant.ietf@gmail.com>
Cc: xiao.min2@zte.com.cn, rtg-bfd@ietf.org, draft-ietf-bfd-unaffiliated-echo@ietf.org
Content-Type: multipart/alternative; boundary="000000000000025c300606434d2f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/db6_Qa7BgC6K-4ZsEmJIye0o5i8>
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: Tue, 26 Sep 2023 13:46:35 -0000

Hi,
as I understand it, the update assigns to the Unaffiliated BFD a new
functionality, monitoring "the liveness of a node not including the
availability of a specific IP address at that node". In my opinion, that
raises some questions:

   - What is "the liveness of a node"?
   - When referring to the liveness of a node, does it applicable to
   a single-box system or also to a virtual, distributed, e.g., the one using
   the CUPS paradigm?
   - How the liveness of a node is derived from the functionality of a
   single interface? Is it equally applicable regardless the interface is
   physical or virtual?

Thank you for your consideration.

Regards,
Greg

On Tue, Sep 26, 2023 at 5:38 AM Ketan Talaulikar <ketant.ietf@gmail.com>
wrote:

> Thanks Xiao Min - the update looks good and addresses my comments.
>
> Thanks,
> Ketan
>
> On Tue, Sep 26, 2023 at 12:58 PM <xiao.min2@zte.com.cn> wrote:
>
>> Hi Ketan,
>>
>>
>> Thank you for the suggested text, very helpful.
>>
>> I've just posted a new revision that incorporates all your comments. Link
>> as below.
>>
>>
>> <https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-09>
>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-09
>>
>>
>> <https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-09>Please
>> see inline with [XM-2]>>>.
>> Original
>> *From: *KetanTalaulikar <ketant.ietf@gmail.com>
>> *To: *肖敏10093570;
>> *Cc: *draft-ietf-bfd-unaffiliated-echo@ietf.org <
>> draft-ietf-bfd-unaffiliated-echo@ietf.org>;rtg-bfd@ietf.org <
>> rtg-bfd@ietf.org>;jhaas@pfrc.org <jhaas@pfrc.org>;
>> *Date: *2023年09月25日 15:37
>> *Subject: **Re: Comments on draft-ietf-bfd-unaffiliated-echo-08*
>> Hi Xiao Min,
>> Thanks for your response. Please check inline below for further
>> suggestions.
>>
>> On Mon, Sep 25, 2023 at 11:41 AM <xiao.min2@zte.com.cn> wrote:
>>
>>> Dear Ketan,
>>>
>>>
>>> Thanks for your review and thoughtful comments.
>>> Please see inline.
>>> Original
>>> *From: *KetanTalaulikar <ketant.ietf@gmail.com>
>>> *To: *draft-ietf-bfd-unaffiliated-echo@ietf.org <
>>> draft-ietf-bfd-unaffiliated-echo@ietf.org>;
>>> *Cc: *rtg-bfd@ietf.org <rtg-bfd@ietf.org>;Jeffrey Haas <jhaas@pfrc.org>;
>>> *Date: *2023年09月22日 22:55
>>> *Subject: **Comments on draft-ietf-bfd-unaffiliated-echo-08*
>>> Hello Authors,
>>>
>>> Looks like I've missed the WGLC on this document, but nevertheless would
>>> like to share the following comments:
>>>
>>> Sec 1 of the document says:
>>>
>>> Section 5 of [RFC5880
>>> <https://www.ietf.org/archive/id/draft-ietf-bfd-unaffiliated-echo-08.html#RFC5880>
>>> ] indicates that the payload of an affiliated 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 Unaffiliated BFD Echo packet and what to do with them.
>>>
>>> However, when I go through the procedures in Section 2, there is no
>>> description of the actual construction of the IP packet that A sends out to
>>> B - what is the source and destination IP - or MAC addresses for that
>>> matter? How is it that B would loop it back? I believe it is important for
>>> the document to specify this.
>>>
>>> [XM]>>> This document does specify the source and destination IP,
>>> through reference to RFC 5881. In section 2 it says
>>>
>>> "Regarding the selection of IP address, the rules stated in Section 4
>>> of [RFC5881 <https://www.rfc-editor.org/info/rfc5881>] are applicable
>>> to the encapsulation of an Unaffiliated BFD Echo packet."
>>>
>>> In -07 version the rules of RFC 5881 were restated, however in -08
>>> version they're removed by following the suggestion from Greg.
>>>
>> KT> I missed that conversation. One small suggestion so it covers not
>> just IP address but also MAC.
>>
>> OLD: Regarding the selection of IP address, the rules stated in Section
>> 4 of [RFC5881
>> <https://www.ietf.org/archive/id/draft-ietf-bfd-unaffiliated-echo-08.html#RFC5881>
>> ] are applicable to the encapsulation of an Unaffiliated BFD Echo
>> packet.
>>
>> NEW: An Unaffiliated BFD Echo packet follows the same encapsulation rules
>> as for a BFD Echo packet as specified in Section 4 of [RFC5881
>> <https://www.ietf.org/archive/id/draft-ietf-bfd-unaffiliated-echo-08.html#RFC5881>
>> ].
>>
>> [XM-2]>>> Accepted.
>>
>>
>>
>>> Another important part is that normally BFD verifies the bidirectional
>>> path, the liveness of the other endpoint, but also validates the presence
>>> of a specific IP at that endpoint. Is that still the case when operating in
>>> this mode? This question arises since the document talks about liveness to
>>> servers - so is it monitoring liveness to the server host or a specific
>>> server IP?
>>>
>>> [XM]>>> It's monitoring liveness to the server host, not a specific
>>> server IP. Also note that the Unaffiliated BFD Echo can be used for
>>> multiple use cases, in section 1 it says
>>>
>>> "Section 6.2.2 of [BBF-TR-146
>>> <https://www.broadband-forum.org/technical/download/TR-146.pdf>] describes
>>> one use case of the Unaffiliated BFD Echo. Section 2 of [
>>> I-D.wang-bfd-one-arm-use-case
>>> <https://datatracker.ietf.org/doc/html/draft-wang-bfd-one-arm-use-case-00>
>>> ] describes another use case of the Unaffiliated BFD Echo."
>>>
>> KT> This is OK. I was looking for some text (perhaps in Section 1) that
>> says something on the lines of ... "The Unaffiliated BFD Echo functionality
>> only monitors liveness of the node and does not monitor the availability of
>> a specific IP address at that node." - I believe this is an important
>> distinction from normal BFD operations that needs to be called out. Would
>> you agree?
>>
>> [XM-2]>>> Some text as you want was added to section 1.
>>
>>>
>>> Finally, is it normal or natural to expect server hosts to be able to
>>> "loop them back by normal IP forwarding"? Or does it require some
>>> additional/special capabilities to be turned ON those hosts as hosts don't
>>> do forwarding by default.
>>>
>>> [XM]>>> As I know of a deployment, there is no need to turn ON those
>>> hosts. At the same time, it's feasible to have such a knob. Propose to add
>>> some text as below.
>>>
>>> OLD
>>>
>>> The method for provisioning device B to loop back BFD Unaffiliated Echo
>>> packets is outside the scope of this document.
>>>
>>> NEW
>>>
>>> There may be a knob to turn on/off the loopback of Unaffiliated BFD
>>> Echo packets at device B. The method for provisioning device B to loop
>>> back Unaffiliated BFD Echo packets is outside the scope of this
>>> document.
>>>
>>>
>>> KT> This is not quite where I was going. Perhaps something on the
>> following lines?
>> NEW:
>> BFD Unaffiliated Echo feature depends on device B performing IP
>> forwarding (actually IP redirect) functionality. While such functionality
>> may normally be expected to be supported on a router, it may not be enabled
>> on a host by default. The method for provisioning device B to loop back BFD
>> Unaffiliated Echo packets is outside the scope of this document.
>>
>> [XM-2]>>> Accepted.
>>
>>
>> Best Regards,
>>
>> Xiao Min
>>
>>
>> Thanks,
>> Ketan
>>
>> Best Regards,
>>>
>>> Xiao Min
>>>
>>>
>>> It would help if these aspects are clarified in the document.
>>>
>>>
>>> Thanks,
>>> Ketan
>>>
>>> On Thu, Jul 6, 2023 at 7:50 AM <internet-drafts@ietf.org> wrote:
>>>
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>> directories. This Internet-Draft is a work item of the Bidirectional
>>>> Forwarding Detection (BFD) WG of the IETF.
>>>>
>>>>    Title           : Unaffiliated BFD Echo
>>>>    Authors         : Weiqiang Cheng
>>>>                      Ruixue Wang
>>>>                      Xiao Min
>>>>                      Reshad Rahman
>>>>                      Raj Chetan Boddireddy
>>>>    Filename        : draft-ietf-bfd-unaffiliated-echo-08.txt
>>>>    Pages           : 12
>>>>    Date            : 2023-07-05
>>>>
>>>> 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 Control packet and its processing 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 datatracker status page for this Internet-Draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-bfd-unaffiliated-echo/
>>>>
>>>> There is also an htmlized version available at:
>>>>
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unaffiliated-echo-08
>>>>
>>>> A diff from the previous version is available at:
>>>>
>>>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-bfd-unaffiliated-echo-08
>>>>
>>>> Internet-Drafts are also available by rsync at rsync.ietf.org:
>>>> :internet-drafts
>>>>
>>>>
>>>>
>>>
>>