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

Weiqiang Cheng <chengweiqiang@chinamobile.com> Mon, 17 August 2020 06:07 UTC

Return-Path: <chengweiqiang@chinamobile.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 EB0D53A09C3 for <rtg-bfd@ietfa.amsl.com>; Sun, 16 Aug 2020 23:07:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmNTZ61icrZ0 for <rtg-bfd@ietfa.amsl.com>; Sun, 16 Aug 2020 23:07:46 -0700 (PDT)
Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with ESMTP id C07823A09C1 for <rtg-bfd@ietf.org>; Sun, 16 Aug 2020 23:07:45 -0700 (PDT)
Received: from spf.mail.chinamobile.com (unknown[172.16.121.13]) by rmmx-syy-dmz-app09-12009 (RichMail) with SMTP id 2ee95f3a1ea6428-971f9; Mon, 17 Aug 2020 14:07:34 +0800 (CST)
X-RM-TRANSID: 2ee95f3a1ea6428-971f9
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from cmcc (unknown[10.2.53.197]) by rmsmtp-syy-appsvr07-12007 (RichMail) with SMTP id 2ee75f3a1ea4633-80306; Mon, 17 Aug 2020 14:07:34 +0800 (CST)
X-RM-TRANSID: 2ee75f3a1ea4633-80306
From: "Weiqiang Cheng" <chengweiqiang@chinamobile.com>
To: "'Santosh P K'" <santosh.pallagatti@gmail.com>, "'Jeffrey Haas'" <jhaas@pfrc.org>
Cc: "'rtg-bfd WG'" <rtg-bfd@ietf.org>
References: <20200804131549.GA31729@pfrc.org> <CACi9rdu-6Mdd-b2zG0d8XYoZKbEqHNAhq6A29U1Umcg378g0ug@mail.gmail.com>
In-Reply-To: <CACi9rdu-6Mdd-b2zG0d8XYoZKbEqHNAhq6A29U1Umcg378g0ug@mail.gmail.com>
Subject: Re: Adoption call for draft-cw-bfd-unaffiliated-echo (ending 16 August, 2020)
Date: Mon, 17 Aug 2020 14:07:33 +0800
Message-ID: <016f01d6745c$b2de88b0$189b9a10$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0170_01D6749F.C101C8B0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AdZz4ZPjLs6GyDRfQumfp4AbfjP8owAevYBA
Content-Language: zh-cn
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/zwMdJ7MAL7UAwV21D569WpGFkmk>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 17 Aug 2020 06:07:49 -0000

Hi Santosh,

Thanks for your review and good questions.

Please see inline responses with <Weiqiang>.

Best Regards,

Weiqiang

 

 

发件人: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] 代表 Santosh P K
发送时间: 2020年8月16日 23:26
收件人: Jeffrey Haas
抄送: rtg-bfd WG
主题: Re: Adoption call for draft-cw-bfd-unaffiliated-echo (ending 16 August, 2020)

 

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 below:"

 

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. 

<Weiqiang> This draft would update RFC 5880, in other words, some text in RFC 5880 would not apply to unaffiliated BFD echo function.

 

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

<Weiqiang> In this draft, unaffiliated BFD Echo Function is defined as that the local system needs to support BFD protocol. If both the local system and the neighboring system don't support BFD, then it's outside the scope of this draft.

 

Thanks

Santosh P K 

 

 

 

 

On Tue, Aug 4, 2020 at 6:34 PM Jeffrey Haas <jhaas@pfrc.org> wrote:

Working Group,

https://datatracker.ietf.org/doc/draft-cw-bfd-unaffiliated-echo/

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