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

Ketan Talaulikar <ketant.ietf@gmail.com> Tue, 26 September 2023 16:56 UTC

Return-Path: <ketant.ietf@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 10DDDC1522B9; Tue, 26 Sep 2023 09:56:33 -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_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 ZzzPUWMXq04d; Tue, 26 Sep 2023 09:56:29 -0700 (PDT)
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 D1C46C14F74A; Tue, 26 Sep 2023 09:56:28 -0700 (PDT)
Received: by mail-ej1-x635.google.com with SMTP id a640c23a62f3a-99357737980so1132500466b.2; Tue, 26 Sep 2023 09:56:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695747387; x=1696352187; 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=6f6hyW7bxsIhAetyQ+g6c75mVk6l1cktIQfhmsLIxfg=; b=Wdh5h9Usu6W5xlMLDk0tsPy/5J7f957NQwHUGc+6h0bHjMFNXSeCwp2oPR1onkQ9LU 07klBC9mbGFWjJ1HsAi2x+xSmRM441AKqH+UcGNy3MLa66vnSdyukkjKlD4YhNogHTf+ On3BKso3BZtStAoTJuFVACfW6e+2RXKMiLp8EVOVfbZTqTHsXUcErl8h3a1V/xzxrgaF 56aeHEaEtaXM8KolKpvTRjywVs5jBI/Bba7GJ/9O4sOICIMHuQkW3yGWoKlsHnNnr8+R SrEAXKe5qUFI1e6r/5Dvt1mOnFJfKSTCOj8Z77Ly9gb9oJk2m9ktrI6/24GUGathb23L BwUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695747387; x=1696352187; 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=6f6hyW7bxsIhAetyQ+g6c75mVk6l1cktIQfhmsLIxfg=; b=Cx1NWNh6chGo6kyHfs5slorWTiBd5L5uJAOsJI216JZf9wDsYqJ0/NbUiii/Vlcv/M 3qrbq0lTnYVvWdbTOx1wyZyt0WIfnN8d+UL803116qMcINzMvqM95U3NKGnLcgsH3wZg AgrBBteLFL9csuAxruEGWc50mro4X+EhLPJOxLgGFpF96pObL0KwCVEzhk1SsLFw3UPm KbI9mkQbLD2tKu5GrNn6Z+WN9ufINDoYnEzTlQufcAXT2OoepR9I08qlQZyc/nddXIcr P0SWGVJT2J8iEyiZHdWpi964F8AsSqVaiWVAwKGP9lfLKhL92pZa03wrrB/4Ed/hcbEB Y/xQ==
X-Gm-Message-State: AOJu0YwIyanbjUhc0b5r3uYgBB6SwBQDlCMU8sySbwo/V5nppnLCNWdS 1Tf/HH6GQiP6GgEuj84WH56B1RUFmXeHsnDJCtfpnwoZ
X-Google-Smtp-Source: AGHT+IFIalVKNAFxl7421iO7BLEjBHT96QpRWqzUQbb7DFqEGHcXjpcN/Bj2MiQ5V/O/krM7C2c21ZMiwovaVNBmSFY=
X-Received: by 2002:a17:906:100b:b0:9a1:bb8f:17d0 with SMTP id 11-20020a170906100b00b009a1bb8f17d0mr9525795ejm.30.1695747386517; Tue, 26 Sep 2023 09:56:26 -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> <CA+RyBmVZPcXymMJ4Pngwz69gp4Um32YGtyYWUoJ6Gbpe2nwkdA@mail.gmail.com>
In-Reply-To: <CA+RyBmVZPcXymMJ4Pngwz69gp4Um32YGtyYWUoJ6Gbpe2nwkdA@mail.gmail.com>
From: Ketan Talaulikar <ketant.ietf@gmail.com>
Date: Tue, 26 Sep 2023 22:26:14 +0530
Message-ID: <CAH6gdPxfYjUPXJURR3bn6KBvurEothyhY3XG1mVSV5Fu_+st4g@mail.gmail.com>
Subject: Re: Comments on draft-ietf-bfd-unaffiliated-echo-08
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: xiao.min2@zte.com.cn, rtg-bfd@ietf.org, draft-ietf-bfd-unaffiliated-echo@ietf.org
Content-Type: multipart/alternative; boundary="0000000000009a2e74060645f4e4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/so0oHr07JkixspcmCwCmylv-n4A>
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 16:56:33 -0000

Hi Greg,

I would read it as " ... the liveness of a node over the specific interface
..." i.e, the node is reachable and responding over that interface.

Thanks,
Ketan


On Tue, Sep 26, 2023 at 7:16 PM Greg Mirsky <gregimirsky@gmail.com> wrote:

> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>