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

Ketan Talaulikar <> Fri, 22 September 2023 14:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1AE64C14F74E; Fri, 22 Sep 2023 07:55:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Status: No, score=-2.103 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_BLOCKED=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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sVTSPrOEQ64o; Fri, 22 Sep 2023 07:55:24 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::633]) (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 46698C14CE45; Fri, 22 Sep 2023 07:55:24 -0700 (PDT)
Received: by with SMTP id a640c23a62f3a-9adc75f6f09so268782766b.0; Fri, 22 Sep 2023 07:55:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1695394522; x=1695999322;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=m/5HcDKpfWo6PeD781Li4CYB+ZYVD06UJVVsZ9ZU/zw=; b=YY+ZVI5RYP49PYe9nz4SLPSCtFrJRQO8HmhUAIuJ+ehD1AOMrVb+GaT7e7GWyZivfp MsRgZtAkbtC4SAGniKvg+fc4q+5f/jZMKfCyldBFcJQbY9ZgJ4u+NrK+HWVPNPXz+D2C mj86rA3/+TPu4LYXhgegxm9fvdH7j+JXBKwDP0l+5aDvqeLUgxZOLlv5S5SnsgCUPQil jXJYOv33SSWZ5zQUNFfTQhcof1/UHHYHynMPawUd0k4SZckkJPlVs967hF0AqqHNZetr I71zRm6fGX3bp2hAAtT1FxavYPEZIDdbZKPgLbcD1McVoA7hJsH29C/3V60vsDxEcznZ z5ow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1695394522; x=1695999322; 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=m/5HcDKpfWo6PeD781Li4CYB+ZYVD06UJVVsZ9ZU/zw=; b=r9mH4ByZiYQ4QGz3x8rhTRD3PbGkaVZ2d3dp/qvQA2bxmPdmQYYpaLTmTisjlgDy3R wrgE7FQmUHmMySIiDVnJfsH911ye4Cd/X46yzZj/CkJ72rXbD6wHu5JH2icw3K54xkkt dF0PhyP2wmYz4U3PwtoDReiNFAqkSgcawPmrdRs/eF6Vx5R2h/947id3Bf9OoRmwq5rE jXWAVO5Gqp8F8q9JMG2dUcGnmJpS7HFIn1HSy3GGx0rfb/ZtWEYNjnG9TDdEEGwCtL/U Mi89TMc3cnmcIYyDKWq8ENpXTNbx5Ya6D/g0891aFR7cSbU9RjGNm6LV1g8jfM/nYKVK KTyg==
X-Gm-Message-State: AOJu0Yw6Sew0MRUYCfj3MfBUWg4+6fuuxYZa95YZpArxIaa5ECa+LzYF Xt92Z5DLamnGbxM4bgn+S6epqwkVV5dbQ0cgfxDLZ+EzRk0=
X-Google-Smtp-Source: AGHT+IGQkKnjMIwhQqroXGs2srgz3K+AyLBsbuzx/m3D8pXv9bEkiRVo34opw3hJRtLxjPOaE83zCL4vqwxNcKdlD88=
X-Received: by 2002:a17:906:18:b0:9ae:759e:3614 with SMTP id 24-20020a170906001800b009ae759e3614mr1571762eja.32.1695394522272; Fri, 22 Sep 2023 07:55:22 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Ketan Talaulikar <>
Date: Fri, 22 Sep 2023 20:25:10 +0530
Message-ID: <>
Subject: Comments on draft-ietf-bfd-unaffiliated-echo-08
Cc:, Jeffrey Haas <>
Content-Type: multipart/alternative; boundary="000000000000411ab20605f3cc8f"
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: Fri, 22 Sep 2023 14:55:28 -0000

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.

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?

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.

It would help if these aspects are clarified in the document.


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