Re: Draft agenda posted for IETF 105

Jeffrey Haas <jhaas@pfrc.org> Mon, 22 July 2019 14:26 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 6D0F41201F2 for <rtg-bfd@ietfa.amsl.com>; Mon, 22 Jul 2019 07:26:30 -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 tjl5HBytXz7H for <rtg-bfd@ietfa.amsl.com>; Mon, 22 Jul 2019 07:26:28 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 18922120059 for <rtg-bfd@ietf.org>; Mon, 22 Jul 2019 07:26:27 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 01AE81E2F2; Mon, 22 Jul 2019 10:28:13 -0400 (EDT)
Date: Mon, 22 Jul 2019 10:28:13 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: Draft agenda posted for IETF 105
Message-ID: <20190722142813.GB28302@pfrc.org>
References: <20190718161241.GE21401@pfrc.org> <2BCA3525-0E7B-419A-A2A8-985F545F6EA8@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <2BCA3525-0E7B-419A-A2A8-985F545F6EA8@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/dja8fLLvM8DuoKAt5QuafayKeAg>
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, 22 Jul 2019 14:26:30 -0000

[largely speaking as an individual contributor]

Carlos,

On Mon, Jul 22, 2019 at 01:44:46PM +0000, Carlos Pignataro (cpignata) wrote:
> > On Jul 18, 2019, at 12:12 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:
> > Please note we are reserving the end of the session for discussion about BFD
> > v2.  We are using Greg's presentation as a seed item for that discussion.
> 
> To further seed and guide this discussion, it would be useful and productive to start with the problems intended to be solved with BFD v2.

To offer an observation I'll be using during the BFD session:
BFD is a "popular" protocol.  Much like BGP or DNS, it has certain
properties that make it attractive to have other things added to it.

In BFD's case, it's the fact that we have a continuous stream of
communication between two systems.

At some point, if this is the primary useful property, one might envision
that the BFD protocol and general machinery are forked to provide such a
channel for other mechanisms.  Especially for things that don't need to be
in constant contact every 3.3ms. :-)

> Is performance metrics like packet loss and packet delay the main goal? Or a new on-demand auth?

I'll note that IPPM already has solution space stuff here.  This is much why
we're inviting them specifically.

The auth space is also covered to a large extent in open drafts that we'll
hopefully decide how to conclude this upcoming session.

> If the former, why not shim IOAM to BFD (and to actual data packets as well) instead of refactoring the protocol?

I look forward to hearing from those who are working on such things in IPPM.

> Further, even better, S-BFD seems much (much!) more friendly to this set of uses than BFD. Why not start with S-BFD which has implementation?

I'm sympathetic with this view, but will note that s-bfd is using the same
packet format.  So, we're still having a discussion about bfd PDUs.

> Maybe this starts the discussion early, but starting with this proposed solution confused me.

To a large extent, this presentation order is being done not because the
chairs believe this is the way to go, but mostly because we're being
pressurd into even having this discussion because we keep getting proposals
to put more stuff into BFD.

> We could add TLVs. But starting with the problem statement will enable us to think holistically on universe of potential solutions.
> 
> 
> A second topic after the Intention and Goals, would be Charter. How does design Perf Mgmt intersect with other WGs?

As I noted in the invite mail for this topic, such things are currently out
of charter.  


-- Jeff