Re: [netmod] Unknown bits - backwards compatibility

["Jason Sterne (Nokia)" <[e-mail]>]

Hi Jeff,

You are absolutely right that this is a tricky case for identifying the specific affected node. I should have mentioned how to do that.

Basically in this case, the “description” field of the unknown-flags leaf should really change each time there are newly unreported bit-0, bit-1, etc bits. This is a situation where the YANG model itself doesn’t have a change for known-flags, but the underlying *behavior* of that leaf has changed.

This is one of the reasons why we’re having a debate right now for our “Schema Comparison” draft about how we should treat description changes by default (i.e. not as just “editorial” but as “potentially-nbc” or just “nbc”).

In the Schema Comparison draft we’re also debating whether to add “per node” compatibility tags (optional – use when needed, and this is a case where it is useful to flag a particular *node* as having an NBC change in version 2.0.0).

Jason

From: Jeffrey Haas <[e-mail]>
Sent: Thursday, April 13, 2023 5:18 PM
To: Jason Sterne (Nokia) <[e-mail]>
Cc: [e-mail]
Subject: Re: Unknown bits - backwards compatibility


CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.


Jason,



On Apr 13, 2023, at 5:00 PM, Jason Sterne (Nokia) <[e-mail]<mailto:[e-mail]>> wrote:

Hi Jeff,

We avoided getting into subtleties about “severity” of an NBC change (hard enough to just get agreement on basic rules). But I do think it is useful to come up with changes and approaches that have lower impact on users/clients even if they are still marked as NBC.

For the new versioning marking, it would basically be the following. In the “revision” statement of the new module:

  1.  Add "rev:non-backwards-compatible" as per draft-ietf-netmod-yang-module-versioning-08 - Updated YANG Module Revision Handling<https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning/>
  2.  Increment the major version of the YANG Semver (i.e. go from 1.0.0 to 2.0.0) as per draft-ietf-netmod-yang-semver-11 - YANG Semantic Versioning<https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-semver/11/>

That may seem harsh, but we leaned towards being strict on flagging any NBC change in order to avoid false-negatives (i.e. false-positives aren’t as bad). Users can then diff the module versions, see that only the unknown-bits stuff has changed, and then decide if they need to update their client, etc.

I think I'm still unclear on how this would manifest for my proposal.

The "known" field isn't having a NBC change, so I think we can ignore that.

The "unknown" field has a stable type. More importantly, and perhaps a larger question for the NBC work, what needs to be flagged is that a specific bit has been impacted at a specific version bump of the document.  How is that to be signaled on such a type?

Consider instead the non-general case, and one that's in the bgp-model:

    leaf unknown-flags {

          type bits {

            bit unknown-2 {

              position 2;

              description

                "Bit 2 was received but is currently RESERVED.";

            }

            bit unknown-3 {

              position 3;

              description

                "Bit 3 was received but is currently RESERVED.";

            }

          }
This represents the modeling from my unknown draft for the remaining two bits of the nybble that aren't assigned after the second bit was assigned.

If a future version of BGP's Graceful Restart feature assigned bit 2, and unknown-flags wasn't modeled using my proposed typedef, I can see the following actions being done:

Add new type to the known leaf.  (A backward compatible change.)
Delete "unknown-2".  This is NBC, but clearly documents the change.

Briefly scrolling through the module-versioning draft, it doesn't appear that there's ways to flag what nodes contribute to the NBC issues.

In any case, where the contents are visibly impacted, it's clear you can flag this.  I suspect you're missing a way to flag the case as documented in my current draft.

-- Jeff