Re: BFD WG adoption for draft-haas-bfd-large-packets

Jeffrey Haas <jhaas@pfrc.org> Mon, 29 October 2018 15:36 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 3BF5612D4F0 for <rtg-bfd@ietfa.amsl.com>; Mon, 29 Oct 2018 08:36:19 -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 aOt7ccdEETF2 for <rtg-bfd@ietfa.amsl.com>; Mon, 29 Oct 2018 08:36:17 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC94130DF9 for <rtg-bfd@ietf.org>; Mon, 29 Oct 2018 08:36:17 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 5225E1E44B; Mon, 29 Oct 2018 11:35:35 -0400 (EDT)
Date: Mon, 29 Oct 2018 11:35:34 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
Cc: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "Naiming Shen (naiming)" <naiming@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets
Message-ID: <20181029153534.GL12336@pfrc.org>
References: <E052CA19-228D-4271-BF9E-7499255E7C53@cisco.com> <7332e35048d34d44a65ea70df409699c@XCH-ALN-001.cisco.com> <90B9205E-CBD8-4779-96D1-2D15BD1F7E24@cisco.com> <e08744fc4b264fd1bf9844dd0f29557e@XCH-ALN-001.cisco.com> <59DD4DA1-6C83-4D3D-92E7-B4271EB259E8@cisco.com> <2dc00a0d58db41958ad61d73d08ead17@XCH-ALN-001.cisco.com> <20181025153804.GD12336@pfrc.org> <B5988BA3-E039-47C5-9145-48747700E197@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <B5988BA3-E039-47C5-9145-48747700E197@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/PcYDjk9lJOtgWXshVwz-nvmUBVs>
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, 29 Oct 2018 15:36:19 -0000

Reshad,

On Fri, Oct 26, 2018 at 06:32:26PM +0000, Reshad Rahman (rrahman) wrote:
>On 2018-10-25, 11:38 AM, "Jeffrey Haas" <jhaas@pfrc.org> wrote:
> >     The draft I had previously worked on with Xiao Min discussing probing using
> >     BFD Echo had the concept of probes that would happen wherein the session is
> >     not torn down.  The example carries similarly with the "send occasional".
>
> <RR> We discussed use of echo at IETF102. The large-packets draft mentions
> that echo can only be used for single-hop, hence the need for padding the
> control packets. But isn't single-hop Albert's main use-case? 

It's Albert's primary use case.  And, I think a common related one is
protecting tunnels of various flavors; e.g. GRE or IPsec.

> I believe we
> should add the echo option in the large-packets draft, it has the benefit
> that you get the desired functionality even if only 1 side of the WAN link
> supports echo. I realize not all implementations support echo so they
> might have to do pad control packets instead.

While I don't think Albert or I would have any objections to adding Echo
discussion in the existing document, we perhaps risk running into one of the
issues Xiao and I had briefly discussed.  Echo is intentionally
under-specified in RFC 5880 et seq.  While it's possible that we can simply
put in a discussion section that says "if you use Echo mode with similar
padding, you can get similar benefit", I think that may be as far as we want
to go.

The related observation is that nothing stops an Echo implementation from
doing this with no changes to the protocol. :-)

-- Jeff