Re: [netmod] Modeling unknown bits in YANG (draft-haas-netmod-unknown-bits-00)

[Jeffrey Haas <[e-mail]>]

Jason,

Thanks for your comments.

On Tue, Jan 31, 2023 at 09:50:49PM +0000, Jason Sterne (Nokia) wrote:
> One potential consideration that came to my mind is about the choice of using 'bits' at all (vs a set of Boolean leafs), and it is related to on-change telemetry.
> 
> With a leaf of type 'bits' that has on-change telemetry support, an update will return the entire bitfield. That means you don't immediately know which particular bit changed.
> 
> If a set of Boolean leafs was used instead, then a client immediately knows which specific condition changed state.
> 
> There are pros and cons to both sides of this though. With on-change and 'bits', you do get the entire bitfield in the notification. So if you want purely stateless processing, and are willing to go through the entire analysis of all the bits every time you get an on-change notification, then it works well. It also works well if you need/want to look at a combination of the bits in order to process the update in the collector/client/consuming-app.
> 
> But if you just want to immediately know exactly which item changed, with bits you would have to cache the previously received value and compare to see which bit(s) changed.
> 
> I'm not sure this is a important consideration for your proposal but wanted to bring it up in case is resonates with others.

I think there are a few different things to respond to here.

For a small number of bits, as in my example in the draft, modeling as
individual booleans may be reasonable.  For "known" bits, the ability to see
the on-change behavior might be useful.  For my specific example where the
op state is created once per BGP session connection, it's not a great use
case, but perhaps other cases are a better fit.

Atomicity is also perhaps a consideration as well.  If many bits can change
in the same field in short order, receiving multiple notifications in your
streaming may be less useful if you need to know what the final state of the
bits are to take action.  A notification shouldn't turn immediately into a
poll for the current state of the full bit set.

I think the modeling as individual booleans runs into the same "unknown"
problem that this draft is attempting to discuss.  If bit position 1 is
unknown, this pattern would require the creation of a leaf, unknown-1, that
would similarly need to be renamed when it became known.  Then we compound
the modeling noise of multiple leaves, I think.


-- Jeff