Re: New Version Notification for draft-rvelucha-bfd-offload-yang-05.txt

[Jeffrey Haas <[e-mail]>]

Tom,


> On Apr 13, 2023, at 7:05 AM, t petch <[e-mail]> wrote:
> 
> Taking a step back
> 
> On 05/04/2023 10:20, t petch wrote:
>> On 04/04/2023 06:20, Rajaguru Veluchamy (rvelucha) wrote:
>>> Thanks, Tom for review/comments.
>>> 
>>> Version been updated for comments. Can u please check.
> 
> How widely is bfd offload implemented by manufacturers?  I had a look at the Juniper website and find it refers to Distributed BFD running on the Packet Forwarding Engine and Centralized BFD running on the Routing Engine.  Is this what you mean by BFD offload?  (Searching the Juniper website for BFD offload generates thousands of hits none of which seem to be about the offloading of BFD).

This is the same sense as the object in his model.  As usual, the headache with such things is often not where it goes in the model, but the gotchas a name gives by hidden semantics.

> 
> Who else supports it (such as I could see in publicly available documentation, I am not asking for anything proprietary)?  What other terms are used to reference it?

I'm pretty sure everyone supports it in some flavor.  The lack of visibility to see when it's used is a good attribute this model fixes.  The ability to force it to be used is the problematic aspect: Sometimes you can configure it, sometimes you can't.

The easiest scenario for you to visualize is a system designed with a control-plane sourced BFD implementation for multi-hop and MPLS and a broadcom linecard implementation of single-hop.  The latter is distributed/offloaded whereas the control-plane one is "centralized".

Dealing with the large number of scenarios when it cannot be configured will be the bulk of the interesting part of this work.  Do you simply make it a NOP when it's not supported?  Do you make it a commit failure?  Etc.

The related possibility is each vendor is permitted to publish a config false deviation for scenarios they know it's not possible to configure.

Another option for the working group to consider is that the default behavior for this model is to start with "config false" as the baseline expectation and to permit vendors to deviate as "config true".  

-- Jeff