Re: Adoption call for draft-cw-bfd-unaffiliated-echo (ending 16 August, 2020)

Santosh P K <> Sun, 16 August 2020 15:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3A9EE3A0CF4 for <>; Sun, 16 Aug 2020 08:26:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 xtQhE43a5YCr for <>; Sun, 16 Aug 2020 08:26:02 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8400E3A0CF2 for <>; Sun, 16 Aug 2020 08:26:02 -0700 (PDT)
Received: by with SMTP id p18so8591284ilm.7 for <>; Sun, 16 Aug 2020 08:26:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oKjzeWEiENiHIYvCpW8ioG939yZdK0lazSUEQVs7Vxo=; b=SfPQLETpJlDkBUnUUMPUjqjGr3667E+CpTgytiQl9Zzjekk89isJNehTSXzy2U6mCu xUAbW2gruadAEBezYPzJmzc/6wqa0xOmLPa4TEuTFGSVU4hvCcnHW8CqoHg24vSjIywS 0hfRLOk41wYdhHWKLbPEBNj23tSCwPBcQnQattcqoH+XR4WKPYtl0Uq0hPeEra2YSf/A LXxzQKLuuxQyNPZNkZkJ/0kTVApTB5UjDKsg6j99tiVeU74TweOKACxw3KHJ4bwa4Xey Ouqsim1IiM6zaZ9cIoIvNwJcC5cbuo3nW5MOqKU6OMZwn6ZYC2QuJ3GsY9UmH4uK+/uQ BMAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oKjzeWEiENiHIYvCpW8ioG939yZdK0lazSUEQVs7Vxo=; b=aFNfuSeNAsJa3dG6YOOSlpsKHLFqNBk+9STwVhACjj6nXGmYYVQT+8FPCsmmYxGRcP KKwdg4ugmZPOrjmwd2nd9Fq3ntl3pPbXi4MJJAp5z0V+iANEkl94Lc8gA7z8f9LjKN4j Zo5MFStUMltrzYvUzoByFcYIRuS4NnAN9haYZsFC+Q6T75C8BrjZhKpB3oLGOLy9MEwV HFVHN4y7tRAsDchVw9buPHb2Nkkao3JYLGq3YmZwDBWSUchXpv/rZdxgdcgiMQYzrqwj Dd3pA8htNNhyWzty7texB13fQfShhnMLR/9YUpGRCbeJ0mlPwpfEHqRK45hfNXelrUGm 0EWw==
X-Gm-Message-State: AOAM531hJDF8heyktbnObh4tdER4wcoNMf7AmchHxOEtHWMZpiruZjqA p/9JmZzcYOSTGXlv+z6ARh0olknzRSDzUrURVgo=
X-Google-Smtp-Source: ABdhPJyd4e3cCp5eonMNHtxAI4Ddpeh6cd8rqAYYkr7eMKk5kBMS5uIsw2PcRbKXuKeeGcGJg3Wdzh/1avHU5T+Qrcw=
X-Received: by 2002:a92:40c1:: with SMTP id d62mr9451540ill.35.1597591561770; Sun, 16 Aug 2020 08:26:01 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Santosh P K <>
Date: Sun, 16 Aug 2020 20:55:50 +0530
Message-ID: <>
Subject: Re: Adoption call for draft-cw-bfd-unaffiliated-echo (ending 16 August, 2020)
To: Jeffrey Haas <>
Cc: rtg-bfd WG <>
Content-Type: multipart/alternative; boundary="000000000000891ad605ad0045c0"
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 16 Aug 2020 15:26:04 -0000

Hello Authors,
    I read the document and I do have some questions.

In section 1 text below

"When using BFD echo function, it is not clear whether the devices using
echo function need to support the full BFD procotol, including maintaining
the state machine of BFD session as described in [RFC5880] and [RFC5881].
According to different understanding, there are two typical scenarios as

I think RFC 5880 section 6.4 "The Echo Function and Asymmetry" clearly
calls out BFD echo function is negotiated and also it suggests to keep BFD
state machine on both ends with a sedated interval. So not sure why you
mention it is not clear in RFC 5880.

Secondly if we do not need BFD async then it need not be BFD echo it can be
any packet which is has destination IP set to self IP can do that job isn't

Santosh P K

On Tue, Aug 4, 2020 at 6:34 PM Jeffrey Haas <> wrote:

> Working Group,
> At the virtual IETF 108, Unaffiliated BFD Echo Function was presented.
> This
> is a followup of a presentation given at IETF 106.
> The authors have indicated they would like to have this work adopted by the
> BFD WG.  This begins the adoption call ending August 16.  Please respond to
> the mailing list with your thoughts on this adoption.
> It should be noted that this document overlaps work in the Broadband Forum
> (BBF) document TR-146.  As noted in the presentation, the BBF document
> lacks
> some clarity and also doesn't discuss interactions with BFD
> implementations.
> This draft has good clarifications with regard to implementations of this
> mechanism when the a BFD Echo-capable implementation is used.
> This raises two points to consider as part of adoption:
> - This document with its current goals would Update RFC 5880.
> - The status of this document would need to be Proposed Standard.
> -- Jeff