Jeff, > On Jul 22, 2019, at 10:28 AM, Jeffrey Haas <jh...@pfrc.org> wrote: > > [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 <jh...@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. :-)
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) > >> 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. I agree on both counts. > >> 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. 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. > >> 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. Thanks for the clarification. > >> 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. Ack. Thanks! Carlos. > > > -- Jeff
