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

[Jeffrey Haas <[e-mail]>]

Jürgen,

Thank you for your comments.

On Thu, Jan 26, 2023 at 11:40:33PM +0100, Jürgen Schönwälder wrote:
> On Thu, Jan 26, 2023 at 03:51:57PM -0500, Jeffrey Haas wrote:
> - I suggest to avoid talking about displaying data, the verb 'display'
>   is never used in RFC 7950.

What is the suggested verbiage for such things?

> - In the scenario, you seem to model the 'bits understood by the BGP
>   engine' and the 'unknown bits presumably ignored by the BGP engine'.
>   Having two separate leafs for this seems to be fine.
> 
>    <flags>restart</flags>               # what the BGP engine understood
>    <unknown-flags>b1</unknown-flags>    # what the BGP engine ignored
> 
>   Obviously, the presence of <unknown-flags> indicates that there were
>   unknown (presumably ignored) flags.

"Presumably ignored" is generally what we expect for such things out of most
of our protocols.  We tend to be interested in them for two reasons:
1. Things are not working as expected, and an unexpected bit may be the root cause.
2. Seeing such a bit tells us there is a user of these bits in the network.
This may be a new protocol extension.  This may also be an attempted
security breach.

> - Note that exposing bit-fields may be a slightly different thing,
>   i.e. exposing the bits understood by a BGP engine and the bit-field
>   contained in a protocol message received by a BGP engine should
>   likely look like this:
> 
>    <flags>restart</flags>               # what the BGP engine understood
>    <raw-flags>b0 b1</raw-flags>         # what was received by the BGP engine
> 
>   Obviously, raw flags would always be present and for wider bit-fields
>   one may choose types giving a more compact representation.

I have chosen to not use this form partly for the reason you note - it gets
noisy.

The "more compact representation" also doesn't have any guidance that I'm
aware of for general YANG modeling.  For example, if the field in question
can fit into one of the unsigned integer types, good advice may be to pick
the smallest unsigned integer type that can hold it.  The place where I
expect there to be some content is whether you start such a bit vector's
position 0 in the most significant bit, or position the bit vector's last
bit in the least significant bit position?  (Shove to the left or right.)
I've seen both forms in implementations.  It's also been the source of bugs
in both forms and sometimes seen in SNMP MIB implementation issues.

What I would have preferred to exist in the YANG language is a bits type
that provides for automatic default naming for unassigned positions.  Thus,
using your example:
<flags>restart b1</flags>

I understand the motivations to not do this since there's a desire to have
stable naming for the position 1 element.  Thus, we're driven to this
discussion.

The motivation for the unknown-flags representation is the expectation that
they are unusual, and it should be trivial to note the things that are
unexpected.  One should not have to dig through the raw bits to find that
there's one that doesn't have a mapping.  In your example above, seeing b0
means I have to know that "restart" is given position 0 and is expected, but
that "b1" hasn't been assigned anything.

Fundamentally, the contents of unknown flags would be, in C syntax:
unknown_flags = ~known_flags & received_value

> - Concerning the type definition, I suggest to simplify the
>   description statements:
> 
>   OLD
> 
>           "Bit 0 currently has no known mapping for this state.";
> 
>   NEW
> 
>           "Bit 0 is unknown";

This a reasonable change, and I'll incorporate it into the next revision.

>   And since there can be many unknown bits, I would probably just name
>   the bits b0, b1, ... instead of unknown-0, unknown-1, ....
> 
> /js (old fashioned person with a fable for 80 column terminals)

I'm sympathetic for this point, but not yet fully convinced.  Let me
consider and also see what feedback the rest of the Working Group has.

If we truly worried about the older terminals, we wouldn't be using XML. :-)

-- Jeff