Re: BFD Echo mode coverage in BFD for VXLAN

Jeffrey Haas <jhaas@pfrc.org> Wed, 21 August 2019 19:46 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 1D2C3120E60; Wed, 21 Aug 2019 12:46:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qkxzO2egJawy; Wed, 21 Aug 2019 12:46:28 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 975DD1209EC; Wed, 21 Aug 2019 12:46:28 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 1BFD81E2F6; Wed, 21 Aug 2019 15:48:47 -0400 (EDT)
Date: Wed, 21 Aug 2019 15:48:46 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
Cc: Greg Mirsky <gregimirsky@gmail.com>, "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, rtg-bfd WG <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
Message-ID: <20190821194846.GA367@pfrc.org>
References: <CA+RyBmVZeLz-wuC04_V3QJxXDG_qOc_3KO0d3N5h0Y-dDTTFXQ@mail.gmail.com> <3747ADED-2F3A-42B8-BD72-20218D167DEE@cisco.com> <CA+RyBmURk5ew+DuHm9S_6yv0op=ALadoMfwWw9Qs5XLpsog2fA@mail.gmail.com> <CA+RyBmVwSyD3aERjprcTJChAVqkwf1R1JsV_TerZ4Sw54UaDDQ@mail.gmail.com> <2952AB5F-FBD5-4113-BA1B-CD22FC11B58F@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2952AB5F-FBD5-4113-BA1B-CD22FC11B58F@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/9YuckfZ7RtZ3ykGBHM1pietqEDg>
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, 21 Aug 2019 19:46:38 -0000

Continuing the ugly top-post:

There is precedent for BFD Echo not being mentioned as part of other BFD
extensions.  RFC 5884 explicitly says it's not dealt with in that document.
RFC 5885 doesn't mention it at all.

As noted previously, and partially in private replies, for vxlan
applications BFD Echo might be useful, and may be possible to implement.
However, unlike simply BFD Echo for IPv4/IPv6, there are several additional
challenges:
- You still need the encapsulation defined for the echo packets.
- You will need necessary forwarding support for the packet loopback.  

Presuming a vxlan environment where the necessary loopback behaviors are
implemented, and presuming the format for the async packets is documented,
Echo procedures might be able to be derived.

Supporting Reshad's call, it's up to the Working Group to determine if we
want to expand the scope of the document to cover Echo procedures.  Carlos,
as a member of the Working Group is permitted to ask about such coverage.
But it is also within the purview of the Working Group to decide to follow
examples such as RFC 5884 and leave Echo explicitly out of scope.

-- Jeff

Citing RFC 5884, section 6:
"Further, the use of the Echo function is outside the scope of this specification."


On Thu, Aug 15, 2019 at 10:41:46PM +0000, Reshad Rahman (rrahman) wrote:
> 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
>