Subject: Draft agenda posted for IETF 105

From: Jeffrey Haas <[email-masked]>
Date: Thu, 18 Jul 2019 12:12:41 -0400

Working Group,

Here's the draft agenda for IETF 105.

https://datatracker.ietf.org/meeting/105/materials/agenda-105-bfd

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.

Our request is if you are aware of individuals interested in general OAM
techologies in other IETF contexts that you please invite them to this BFD
session.

-- Jeff & Reshad

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 22 Jul 2019 13:44:46 +0000

Jeff, Reshad,

> On Jul 18, 2019, at 12:12 PM, Jeffrey Haas <[email-masked]> wrote:
> 
> Working Group,
> 

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.

For example, that draft used as a seed says in its Abstract:

   This document describes a mechanism to extend the capabilities of
   Bidirectional Forwarding Detection (BFD).  These extensions enable
   BFD to measure performance metrics like packet loss and packet delay.
   Also, a method to perform lightweight on-demand authentication is
   defined in this specification.

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

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

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?

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

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?

The BFD current charter says https://datatracker.ietf.org/wg/bfd/about/:

    Important characteristics of BFD include:

    - Simple, fixed-field encoding to facilitate implementations in 
    hardware.

Regarding: https://datatracker.ietf.org/doc/draft-mirmin-bfd-extended/

Can we please add an “Implementation Status” section as it has always guided the BFD WG?

> techologies in other IETF contexts that you please invite them to this BFD

Apologies I will not be in Montreal but can follow offline and remote.

Thanks,

Carlos.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 22 Jul 2019 10:28:13 -0400

[largely speaking as an individual contributor]

Carlos,

> 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.

> 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

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 22 Jul 2019 14:41:40 +0000

Jeff,

> On Jul 22, 2019, at 10:28 AM, Jeffrey Haas <[email-masked]> wrote:
> 

I believe that an identification of unique potentially useful properties of the protocol is a potentially fruitful approach. Things like:
1. continuous stream of communication between two systems (as you wrote above)
2. Underlying data protocol independence.
3. Boostrapping by other protocols or events.
4. State maintenance in the endpoints (and here S-BFD with a difference)

> hopefully decide how to conclude this upcoming session.

I agree on both counts.

> packet format.  So, we're still having a discussion about bfd PDUs.

Agreed also. And (as per above) decomposing in protocol characteristics useful in a different context can provide a good understanding of matching.

And even what augmentations of BFD are useful and whether other protocols can piggy-back. For example, appending IOAM can in some cases (but not in others) re-use the BFD interesting characteristics.

> to put more stuff into BFD.

Thanks for the clarification.

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

Ack. Thanks!

Carlos.