AFT atomic and counters

[dplore]

This issue is regarding counters in the afts tree (for example: /network-instances/network-instance/afts/next-hops/next-hop/state/counters )

Today the AFT tree contains state for routes and state for counters of packets sent via those routes. The desired behavior for a subscribe to /afts on a device is to stream the routes as they change (ON_CHANGE) and the counters on a periodic interval (SAMPLE). In practice we can observe in many implementations that subscription mode TARGET_DEFINED delivers this desired behavior.

But this is formally at odds with the aft model which defines the telemetry-atomic annotation, for example, at the next-hop list, below which are also counters. A strict interpretation says atomic must apply to the nexthop data and the counters which is not clear how that would work, not really what we want and isn't what implementations deliver.

So how should we address this?

Options might include:

• Update the telemetry-atomic description to say it does not apply to counters containers. This is clear enough, but is not an explicit model. It also doesn't provide a scalable way to subscribe to a child node in SAMPLE mode while some ancestor is in ON_CHANGE mode.
• Refactor the model to separate counters from the data which is intended to be atomic. However, it seems the counters container seems to be in a good place from an organization of the data.
• Other ideas?

NOTE: On a related note, there has been discussion regarding behavior of subscription using 'SAMPLE' vs. ON_CHANGE for counters. The summary I think so far is: ON_CHANGE could be interpreted as an event of the counter being refreshed/updated by the network operating system. One could theoretically change that refresh rate if config leaf(s) are exposed to allow this. Others I think have pointed out that the concept of ON_CHANGE is incompatible or undesirable counter leafs or any leaf which is expected to be monotonically changing and especially if changing rapidly. I don't think we need to consider that in this thread because we still don't want or need the atomic behavior for counters in either scenario.