Re:BFD Echo mode coverage in BFD for VXLAN

<xiao.min2@zte.com.cn> Wed, 11 September 2019 04:01 UTC

Return-Path: <xiao.min2@zte.com.cn>
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 C0243120024 for <rtg-bfd@ietfa.amsl.com>; Tue, 10 Sep 2019 21:01:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 zRoInPQgYeqd for <rtg-bfd@ietfa.amsl.com>; Tue, 10 Sep 2019 21:01:28 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD799120108 for <rtg-bfd@ietf.org>; Tue, 10 Sep 2019 21:01:25 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.164.217]) by Forcepoint Email with ESMTPS id A445342D515214707C27 for <rtg-bfd@ietf.org>; Wed, 11 Sep 2019 12:01:23 +0800 (CST)
Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id 94B5CC278EECCA85FF48; Wed, 11 Sep 2019 12:01:23 +0800 (CST)
Received: from njxapp01.zte.com.cn ([10.41.132.200]) by mse-fl2.zte.com.cn with SMTP id x8B41Bdi081629; Wed, 11 Sep 2019 12:01:11 +0800 (GMT-8) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njxapp02[null]) by mapi (Zmail) with MAPI id mid201; Wed, 11 Sep 2019 12:01:11 +0800 (CST)
Date: Wed, 11 Sep 2019 12:01:11 +0800
X-Zmail-TransId: 2afa5d787187d2dec9ad
X-Mailer: Zmail v1.0
Message-ID: <201909111201112154271@zte.com.cn>
In-Reply-To: <20190910175147.GG1662@pfrc.org>
References: CA+RyBmVZeLz-wuC04_V3QJxXDG_qOc_3KO0d3N5h0Y-dDTTFXQ@mail.gmail.com, 20190910175147.GG1662@pfrc.org
Mime-Version: 1.0
From: xiao.min2@zte.com.cn
To: jhaas@pfrc.org
Cc: rtg-bfd@ietf.org
Subject: Re:BFD Echo mode coverage in BFD for VXLAN
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl2.zte.com.cn x8B41Bdi081629
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/9KYcMYcdZTqC0YbxWC3DxD5AhEc>
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: Wed, 11 Sep 2019 04:01:31 -0000

Hi Jeff and Reshad,






From my personal perspective, I don't think we should require BFD for VxLAN to support Echo mode, because as I know, although the final standard is still on the way, many vendors including my company have already implemented BFD for VxLAN, and it seems that works fine, there is no request from them on Echo mode, which in my view is a lightweight BFD tool used to substitute a relatively more complex BFD implementation.






Best Regards,


Xiao Min



原始邮件



发件人:JeffreyHaas <jhaas@pfrc.org>
收件人:rtg-bfd@ietf.org <rtg-bfd@ietf.org>;
日 期 :2019年09月11日 01:49
主 题 :Re: BFD Echo mode coverage in BFD for VXLAN


[trimming headers]

Working Group,

While we're suspecting everyone is finishing up holidays, please take until
the end of this week to answer Reshad's question:  Should we require BFD for
vxlan to support Echo mode?

-- Jeff

On Thu, Aug 15, 2019 at 10:41:46PM +0000, Reshad Rahman (rrahman) wrote:
> Hi all,
> 
> It is up to the WG to decide whether echo support is desired for BFD over VxLAN (any other BFD use-cases also).  Since this hasn’t been brought up in the WG before, my take is that the WG isn’t interested in having echo for BFD over VxLAN. So if anybody feels that we need echo support, please speak up asap. Because it’s holiday season, let’s take 3 weeks instead of the usual 2, so please respond by September 5th.
> 
> Regards,
> Reshad (co-chair hat).
> 
> From: Greg Mirsky <gregimirsky@gmail.com>
> Date: Thursday, August 8, 2019 at 8:04 PM
> To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
> Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "bfd-chairs@ietf.org" <bfd-chairs@ietf.org>, Martin Vigoureux <martin.vigoureux@nokia.com>
> Subject: Re: BFD Echo mode coverage in BFD for VXLAN
> Resent-From: <alias-bounces@ietf.org>
> Resent-To: Jeffrey Haas <jhaas@pfrc.org>, <rrahman@cisco.com>
> Resent-Date: Thursday, August 8, 2019 at 8:04 PM
> 
> Dear All,
> I was pointed out that my previous e-mail asking for WG help to progress BFD over VXLAN document by sharing opinions regarding coverage of the BFD Echo mode may be overstepping the bounds of an Editor. I apologize, that was not my intention. I'm asking WG Chairs to help to arrive at the conclusion of this question in a reasonable time.
> 
> Regards,
> Greg
> 
> On Thu, Aug 8, 2019 at 4:06 PM Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:
> Dear All,
> I have not set the when this poll closes. I hope that two weeks would be sufficient time for the WG community to express their thoughts.
> 
> Dear Carlos,
> thank you for sharing your opinion on the scope of the document in regard to BFD Echo mode. You've expressed support for exploring the applicability of the BFD Echo mode. Would you support that effort by contributing some text, if WG decides that documenting the applicability of the Echo mode in BFD over VXLAN is useful?
> 
> Regards,
> Greg
> 
> 
> On Wed, Aug 7, 2019 at 6:18 PM Carlos Pignataro (cpignata) <cpignata@cisco.com<mailto:cpignata@cisco.com>> wrote:
> Dear Greg,
> 
> The option of replacing the existing text for something more ambiguous and implicit does not seem like progress in my humble opinion. The spec ends up with the same capabilities, but the text is more obscure. I do not support that option.
> 
> My recommendation for your consideration would be:
> 
>   1.  Explore if it is possible to run BFD Echo as a single-hop.
>   2.  If yes, add text supporting it.
>   3.  If no, add text explaining why not on technical grounds.
> 
> A less desirable option would be if the WG does not care about BFD Echo, to explicitly keep it out of scope (not on technical grounds).
> 
> Best,
> 
> Carlos.
> 
> 
> On Aug 5, 2019, at 6:16 PM, Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:
> 
> Dear All,
> in course of reviews of the draft, several times a question was asked about the rationale for excluding BFD Echo from the scope of this document:
> 
> 7.  Echo BFD
> 
>    Support for echo BFD is outside the scope of this document.
> Much appreciate your consideration of the following options:
> 
>   *   describe the applicability of BFD Echo in VXLAN environment in the document;
>   *   remove Section 7 and clarify in the Introduction
> NEW TEXT:
> This specification describes procedures only for BFD Asynchronous mode.
> 
>   *   make no changes at all.
> Regards,
> Greg
>