Hi,
Please see inline.
On Thursday, April 13, 2023, 02:52:07 PM EDT, Jeffrey Haas <[email protected]>
wrote:
Tom,
> On Apr 13, 2023, at 7:05 AM, t petch <[email protected]> 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.
<RR> Not just the name, but the description. In this case the description says
"running in hardware". Sometimes that line is blurry, e.g. is VPP considered
hardware? Should the description instead say something along the times of
"running in forwarding plane".
>
> 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".
<RR> The BFD implementation I worked on many years ago was distributed to
linecards for SH (for scale) but was not "offloaded", in that there was no h/w
assist.
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".
<RR> I wouldn't make this option configurable right now, so config false is
good.
Regards,Reshad.
-- Jeff
