Clarifications on Atomic flag in GNMI Notifications

[amanand]

Gnmi Notification message contains a Boolean atomic flag:
https://github.com/openconfig/gnmi/blame/master/proto/gnmi/gnmi.proto#L92
// This notification contains a set of paths that are always updated together
// referenced by a globally unique prefix.
bool atomic = 6;
As there is not much information in the spec on this flag, based on the comments it is assumed that all the updates for a unique prefix will be bundled within the same Notification message and the flag is set to true. If the assumption is true then in the case of some prefixes which may be a list containing multiple sub-containers/lists inside it can grow the size of Notification message a lot hence causing the target producers to spend considerable amount of resources in completing all the updates for the prefix that can impact the core functionality of the producers.
This can be addressed if multiple Notification messages can be sent for same prefix which can carry its own event identifier and the one with atomic flag set to true will mean end of notifications for that event/prefix.
Question:
Can Event notifications for prefixes that are telemetry-atomic, but having huge data be sent across multiple Notification messages with the last one carrying atomic flag set to true? All notification messages part of the atomic update would carry the same prefix. But, initial notification messages which contain the split data will have the atomic flag set to false and only the last notification message will have the atomic flag set to true.

If not, then is there any guidance in handling the resource requirements at target producer side in case of large containers?

Will it be possible to include an identifier for a series of Notification messages for an atomic prefix to ease resourcing constraints on producer side?

[robshakir]

The atomic flag means that all leaves under the prefix are always updated together within the same Notification. It cannot be split across multiple Notification messages.

It should be expected that a client could just cache the last Notification for an atomic prefix, and this would contain all the leaves - so the method you discuss of having "the last message" specifying the atomic flag would be invalid.

Our observation is that the message sizes for these atomic containers have not been a problem - gRPC handles splitting the Notification in the transport if it is required to do so, and the message sizes are adequate by default, and can be specified as a larger message size if not. Given the usages today (IS-IS LSPs, or prefixes within the AFT), it's unclear why there would be producer resource challenges - both of these entities are likely updated atomically already (or parsed from an atomic input).