3.5.2.3: Telemetry SAMPLE update and delete notification

[raghubk]

In gNMI spec section 3.5.2.3,
"
Explicit deletion is required to signify the removal of a leaf that is no longer present on a target device in ON-CHANGE subscription mode, and optional in SAMPLE subscription mode.
"

Agree to @gcsl on issue#145.

Consider there are 5 paths in the SAMPLE subscribe request and one of the path later becomes unavailable.
What is not clear for SAMPLE subscription is that, if the subscribed path is no longer available, then delete field should be appended in only one following sample response or for all subsequent sample responses [remember there are 4 more paths that are available]?

I prefer the former, we send delete field (only once) in the next sample notification and not send any further updates for this path. Please let us know your thoughts on this.

[dplore]

Yes, a server should only send one DELETE for a given path. Additional deletes would be redundant and inefficient.

[dplore]

Feel free to reopen if there are follow up questions

[earies]

@dplore - am just noticing this PR but between this and the referenced #145, we still have some disambiguity that needs to be resolved.

There seems to be an expectation that SAMPLE mode subscriptions interleave delete notifications which means we diverge what we've generally seen in correspondance to the term "sample" (e.g. sample data at that point in time). If delete notifications are expected then we are either interleaving ON_CHANGE support now or calling for buffering of events. All of which is not described in the spec.

Will tag this for a discussion topic in the 2025-09-30 OC Community Meeting

[dplore]

Hi, DELETE in SAMPLE_MODE was clarified to be optional in #201.

ref: https://github.com/openconfig/reference/blob/master/rpc/gnmi/gnmi-specification.md#3523-sending-telemetry-updates

[earies]

hmm am I missing it in #201 ? I see no mention of deletes w/ SAMPLE there

In addition, there is nothing in the specification section you referenced above around this. I had thought the consensus was that deletes are only for ON_CHANGE and at the discretion of the implementation for TARGET_DEFINED

Even if the behavior were to be optional, that would drive divergence among implementations which should be a concern when drafting up pseudo standards. Interleaving deletes within a SAMPLE subscription imo violates the intention of sampling

[dplore]

Opps, wrong reference repository. See openconfig/reference#201

[earies]

Opps, wrong reference repository. See openconfig/reference#201

Thx @dplore - let's discuss this in the 2025-10-02 OC Community meeting further

From Section 3.5.2.3, the only verbiage around this is:

Explicit deletion is required to signify the removal of a leaf that is no longer present on a target device in ON-CHANGE subscription mode, and optional in SAMPLE subscription mode.

The problem with not well defined or optional behavior is it provides 0 guidance to implementors and consumers which results in conflicting interpretations, misperception and ultimately divergence and finger pointing. I think we can do better than that.

If we go back to what "sample" means - this behavior imo implies a breach of prior interpretations of sampling with a goal of eventual consistency (which is also not mentioned in spec intent). If deletions are optional in SAMPLE mode subscriptions then how is one to draw a firm contract from this? Are deletes sent as they occur thus turning SAMPLE into an ON_CHANGE hybrid? Are they to be batched for the next interval of a given path request? (Which now implies caching, overwriting/sending last values, etc.. -> additional cost/overhead on the data producer).

Since none of that is defined nor are there drawn out use-cases that should spearhead behaviors, I would propose adjusting that line in the spec to not even make deletes sent in SAMPLE mode subscriptions optional at this time.

[ncorran]

I'm not quite parsing the last sentence above. Is the suggestion to make DELETEs be sent as they happen (more true ON_CHANGE) vs updates which remain SAMPLE and only update at the SAMPLE period? (I think this is what Cisco-XR is implementing).

In most cases I would expect the originators of data to be returned to the SAMPLE subscription to be of a set of leaves of an object, and that a DELETE is of the object itself (so e.g. counters under an interface dont get deleted but an interface might). We then need the DELETE event in the stream, because next time there is a SAMPLE period the object doesnt exist and wont be present in the SAMPLE set

(We dont want to cache the prior existence of an object to send a later delete, especially on a per subscription basis - that becomes a bit like the work for suppress-redundant - which we dont support).

[jsterne]

[snip] next time there is a SAMPLE period the object doesnt exist and wont be present in the SAMPLE set

IMO that's the expected behavior for SAMPLE and the spirit of the original spec (and the fact that we have 3 different types of subscriptions SAMPLE, ON_CHANGE and TARGET_DEFINED which each have their unique behavior). SAMPLE subscriptions shouldn't have a delete (either interleaved nor at the sample interval).

[earies]

I'm not quite parsing the last sentence above. Is the suggestion to make DELETEs be sent as they happen (more true ON_CHANGE) vs updates which remain SAMPLE and only update at the SAMPLE period? (I think this is what Cisco-XR is implementing).

In most cases I would expect the originators of data to be returned to the SAMPLE subscription to be of a set of leaves of an object, and that a DELETE is of the object itself (so e.g. counters under an interface dont get deleted but an interface might). We then need the DELETE event in the stream, because next time there is a SAMPLE period the object doesnt exist and wont be present in the SAMPLE set

(We dont want to cache the prior existence of an object to send a later delete, especially on a per subscription basis - that becomes a bit like the work for suppress-redundant - which we dont support).

What I'm pointing out first is the behavior is undefined and the spec only states that deletions are optional in SAMPLE mode which can lead to various interpretations.

If we look at prior art in terms of "sampling", tmk there has not really been a concept of an "action" associated to a dataset but rather a sample is performed at some point in time and sent - whatever exists is sent, whatever doesn't is not sent (to your point). It is up to the collection side to reconcile, delete objects downstream due to lack of signal, etc...

We have other modes and am of the belief that we keep sample what it is and do not compound interleaving actions within.

What this does raise however is needing to know when a given sample-interval is "complete" which can spawn off discussion into the possibility of leveraging sync_response for each sample interval completion

[ncorran]

Agree that cadence based sampling is fine with no deletes, if there is a clear 'end of sample X' marker.
Within the on-change subscription we need the deletes including for system-sampled objects - even if there is a heartbeat.

[dplore]

As I recall the motivation for openconfig/reference#201 was to provide guidance in general on when DELETE must be sent in ON_CHANGE subscriptions. This exposed that there was also some ambiguity for TARGET_DEFINED and SAMPLE modes. The "deletes are optional for SAMPLE mode" was added because there was not a strong case to define what was needed.

The OC Community rough consensus today was to raise a PR to change "DELETE is optional for SAMPLE mode" to "DELETE is not supported for SAMPLE mode".

[raghubk]

openconfig/reference#231

Prefer to keep "delete" notification in SAMPLE mode as optional. No change to the spec. This would help collection side to update the DB when a path disappears.

Concerns raised in this thread for "delete" notification in SAMPLE mode can be addressed if "delete" notification is sent at "sample interval" instead of when it happens (like in ON-CHANGE). Yes, this requires caching, but gives implementors a choice to implement this "delete" notification if helpful or ignore.