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

Ketan Talaulikar <ketant.ietf@gmail.com> Thu, 28 September 2023 07:17 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 6D074C151525; Thu, 28 Sep 2023 00:17:53 -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 fruwZT0jz5Tw; Thu, 28 Sep 2023 00:17:49 -0700 (PDT)
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (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 D1B45C15E406; Thu, 28 Sep 2023 00:17:48 -0700 (PDT)
Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-9a648f9d8e3so1673121266b.1; Thu, 28 Sep 2023 00:17:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695885467; x=1696490267; 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=sKBxN+gSUWr1CVj4lVnwYkxDFpu5EdaTPqzJy9oTfdA=; b=Up4dmzcM6SXd90WESrlROVkHNRiXdaiOO8wjtOPbcLF9rWp8cOXiVNqSpxh+Ud/IM8 8B+0jRilnSIdsBGtlVzbJ0H9bVcAKId3bS7pQMUYpBjvL/u9wUmfnBk1bs1x2wjpwOUW AzK/0Oj6T3CdvoIqiMjHrLbbNc2gtW5ImxVjytt/mPT8rnl3sY3YFOKH0PhXyDJv9K/X ptTwF0nrvp9Jd35/TBVKgcBhAKcICAcLIc1z6MyjsZU3y19YynXfGElZz46JF9vcOFwk 0YvpyXYabyF5ctIO1sC3SzbqHud1lTei9NpaQxZJQdltp2G8yD0RgMSNCxXeoeM6HZAO 2NrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695885467; x=1696490267; 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=sKBxN+gSUWr1CVj4lVnwYkxDFpu5EdaTPqzJy9oTfdA=; b=Z3oB7WGdqGboVssTT54y2Zb29uLrsGKOEFM7+qFTmvDxSgXvBwtvCxqQ+2fbTviep6 VMbsRJhq6XQ/VWS+i0KMWLIsZOusYkAc6DUpMM8B4au/zLEqCdN5BtZMLmHG1CqHF9aM Ap9GEhPC+K3NogciBef0JNmOjDnemzi02vw/+kHJBGJ9v7OlcOXs4ZXkMzfFb3MnyGhQ uJDxwqEpEwRs7328m9lnikzrEWMB9GvBJdIqhrIEjMvMsuYdYzF1CAe4vGOHdmNw9/C6 +c6a2KK45PH0dLZLkaWjQuGKAqHlWDv/noZd5GBpqRz+ESFqtISO6ymna9KDEhqiv7VY x7bQ==
X-Gm-Message-State: AOJu0YxzXLUHZiBT0KsLN56qLx+K5NBzn0pHiK0AcX4X5kCiIRccUyBF rKt9sn50cE6QEDemK2gd9Fob2997BmnKXINOGhw=
X-Google-Smtp-Source: AGHT+IHI67Z8cX61TkX1c8Ux6HS8IshYfwPbrsxYmNg3kgLcc9YRE97H8OLbSj7yrd+BxgXoWwc8CA6pftkLsasZL9g=
X-Received: by 2002:a17:906:8a7c:b0:9a1:d0bb:d215 with SMTP id hy28-20020a1709068a7c00b009a1d0bbd215mr407713ejc.5.1695885466473; Thu, 28 Sep 2023 00:17:46 -0700 (PDT)
MIME-Version: 1.0
References: <CA+RyBmVCZoUeQ0S2kqYw1zy3pSrqhx7gWaFUoAnjFiPpKQ-yEg@mail.gmail.com> <202309270937414157322@zte.com.cn> <CA+RyBmXSBzXn_s=8oCO3g1Z0FFFs+Z=LQ9KU1s4ib+bLjJWoAA@mail.gmail.com>
In-Reply-To: <CA+RyBmXSBzXn_s=8oCO3g1Z0FFFs+Z=LQ9KU1s4ib+bLjJWoAA@mail.gmail.com>
From: Ketan Talaulikar <ketant.ietf@gmail.com>
Date: Thu, 28 Sep 2023 12:47:34 +0530
Message-ID: <CAH6gdPzO01SF=zpr4QynymRyXSv_Mh1C=d0wOpj_CeiOAVfZKA@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="000000000000cf1b050606661a24"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/Sdln9cB95rzVUj5kozB8c7h3Xow>
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: Thu, 28 Sep 2023 07:17:53 -0000

I would like to make a suggestion to the authors:

OLD:
Note that this method monitors the liveness of a node not including the
availability of a specific IP address at that node.

NEW:
Note that this method monitors the connectivity to a system over a specific
interface and does not verify the availability of a specific IP address at
that system.

My originally suggested text was not using the terminologies from RFC5880.
Greg, I hope this revised text addresses your concern?

Thanks,
Ketan


On Thu, Sep 28, 2023 at 2:43 AM Greg Mirsky <gregimirsky@gmail.com> wrote:

> Hi Xiao Min,
> thank you for your expedient response. Please find my notes below tagged
> GIM>>.
>
> Regards,
> Greg
>
> On Tue, Sep 26, 2023 at 6:37 PM <xiao.min2@zte.com.cn> wrote:
>
>> Hi Greg,
>>
>>
>> Please see inline.
>> Original
>> *From: *GregMirsky <gregimirsky@gmail.com>
>> *To: *Ketan Talaulikar <ketant.ietf@gmail.com>;
>> *Cc: *肖敏10093570;rtg-bfd WG <rtg-bfd@ietf.org>;
>> draft-ietf-bfd-unaffiliated-echo@ietf.org <
>> draft-ietf-bfd-unaffiliated-echo@ietf.org>;
>> *Date: *2023年09月27日 02:21
>> *Subject: **Re: Comments on draft-ietf-bfd-unaffiliated-echo-08*
>> Hi Ketan,
>> Thank you for sharing your interpretation of the introduced text. I agree
>> that your view is in line with how the scope of BFD is defined in RFC 5880:
>>
>>  protocol intended to detect faults in the    bidirectional path between two forwarding engines, including    interfaces, data link(s), and to the extent possible the forwarding    engines themselves
>>
>> But it is not clear to me how "liveness of a node" is retated to the definition above. I hope thr Authors will clarify that for me.
>> [XM]>>> In my understanding it's the liveness of the forwarding engine.
>> Do you expect s/the liveness of a node/the liveness of a node over the specific interface as Ketan clarified?
>>
>> GIM>>  I think that the Unaffiliated BFD and BFD, in general, do not
> detect defects on the nodal level. Thus, the "liveness of a node" seems
> inaccurate, overstretching the scope of BFD as defined in RFC 5880. I
> suggest referring to the definition of the BFD from RFC 5880 or providing
> an explanation of how the Unaffiliated BFD extends the defect detection
> domain up to the nodal scope.
>
> Regards,
> Greg
>
>>
>> Best Regards,
>> Xiao Min
>>
>>
>> Regards,
>>
>> Greg
>>
>>
>> On Tue, Sep 26, 2023, 09:56 Ketan Talaulikar <ketant.ietf@gmail.com>
>> wrote:
>>
>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>