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

Ketan Talaulikar <> Mon, 25 September 2023 07:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 49CF1C151541; Mon, 25 Sep 2023 00:37:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Status: No, score=-7.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_HI=-5, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id apGbqhq6Iqir; Mon, 25 Sep 2023 00:37:26 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::62d]) (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 (Postfix) with ESMTPS id C0188C15108F; Mon, 25 Sep 2023 00:37:26 -0700 (PDT)
Received: by with SMTP id a640c23a62f3a-9a9cd066db5so765602166b.0; Mon, 25 Sep 2023 00:37:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1695627444; x=1696232244;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=f9A5uVzl3N0ZNGI/jwk1s1zLXqTKVVyqPz+Ftq83dXE=; b=fcav+eirccJ3Hbb9qOMQpE8xN7+FsjRBkoAYp7WVM7TwKUp8sP7SWZD0XNwu8d/JP+ TtV+iwfnHPPOHN8EVTcsiO4Bo7iuZOX2pDQVO7zCrd6pHG3ROSL3bQCd0hMXg0URtMi0 S5ZcvVgbVQ7wlbrakqoq6ZCRDI7vUauGIcTn0rg0ALyrVS7uI31VCvMk/UrQACj3oDaw QB6kRDyKZ748aGyEIoP8MkcEwb9KSfDDj4bwrbrKr3mv6sMf4XZT5q5fbgeudnasQB3a Riix9ssMsxiIfqHHZXHhjfw5CKLhrimjjNj2J5xvmNvVjQYuIs7Z8Vw+92Pd6bwARkFG QAEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1695627444; x=1696232244; 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=f9A5uVzl3N0ZNGI/jwk1s1zLXqTKVVyqPz+Ftq83dXE=; b=VzWCwX3Wj+AQ27mJvCl/JTgD98PFxvuWIfNCZy6l+1xwlSpXdiqGxMYkSGY4BsBljB K+x6fxsKDEaDBbx6JTXKek9Cn4GFxSoe6mhHRO5wPIA8pg5qZ2B86RJ5s5KVKikDMCtA ohtgFkloixudoqOPXtE/cn/6Ho426noOA0BXikaI2zWsM+1CVkLNJaG1TKH8b5ygibUM UbveDQYYD6ec/TEDAq3PoEH72NCPld55J6eijxug+gfsLl3OPchPdiugAxWkZVcOYjqP xFEPYTeajBYFC2o94qwmmSiFeoiY3vRIjriYqEWqeickzYq8fpevAAgUbQesbmijTA2b Xc6A==
X-Gm-Message-State: AOJu0Yw9YfRRBZUE0Gb+j4YUn4HHZAzmYNl/85x6EiM8JVsfgC0yZES1 +Psypyl8OHZ7MhdHqFjsNF4USFu5AwSD2bEO5Ng=
X-Google-Smtp-Source: AGHT+IHQBVkjf5fe0iaJIaZzuqNib5qyIf8fnClZcwuqA+yKlJz8MZHYDwAJqMr1G91webXlfUiGHlMGUIi6ulk34nY=
X-Received: by 2002:a17:906:25d:b0:9a5:cade:8047 with SMTP id 29-20020a170906025d00b009a5cade8047mr6118732ejl.71.1695627443943; Mon, 25 Sep 2023 00:37:23 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Ketan Talaulikar <>
Date: Mon, 25 Sep 2023 13:07:11 +0530
Message-ID: <>
Subject: Re: Comments on draft-ietf-bfd-unaffiliated-echo-08
Content-Type: multipart/alternative; boundary="00000000000077bb5006062a074b"
Archived-At: <>
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 25 Sep 2023 07:37:31 -0000

Hi Xiao Min,

Thanks for your response. Please check inline below for further suggestions.

On Mon, Sep 25, 2023 at 11:41 AM <> wrote:

> Dear Ketan,
> Thanks for your review and thoughtful comments.
> Please see inline.
> Original
> *From: *KetanTalaulikar <>
> *To: * <
> *Cc: * <>;Jeffrey Haas <>;
> *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
> <>
> ] 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 <>] 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
] 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

> 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
> <>] describes
> one use case of the Unaffiliated BFD Echo. Section 2 of [
> <>
> ] 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?

> 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.
> The method for provisioning device B to loop back BFD Unaffiliated Echo
> packets is outside the scope of this document.
> 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?
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.


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 <> 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:
>> There is also an htmlized version available at:
>> A diff from the previous version is available at:
>> Internet-Drafts are also available by rsync at
>> :internet-drafts