Clarification: Should gNMI spec and openconfig-telemetry.yang model looked in conjunction?

[gsindigi]

I am referring to gNMI spec ver 0.6.0 and openconfig-telemetry.yang ver "0.4.1". As I understand by yang module, the dynamic subscriptions are typically configured through an RPC channel; I presume gNMI's Subscribe is one such RPC. However, I do see there are some differences between the spec and Yang model.

1. gNMI spec details the subscription modes ONCE, STREAM and POLL. And within STREAM mode, there sub-modes ON_CHANGE, SAMPLE and TARGET_DEFINED. We do not have such level of detailing in the Yang model. Though there are some related artifacts, they are not in-line with the spec. E.g., telemetry-stream-frequency-config could very well by looked similar to sample_interval within SAMPLE mode subscription; but, when this is 0 the meaning and interpretation is different.
2. Same with telemetry-stream-encoding-config as well. This may be SubscriptionList.Encoding. But, the values are different in spec and yang model.

There are others as well, but am not listing all here.

So, should these gNMI spec (especially Subscription parts) and openconfig-telemetry.yang model be looked in conjunction? If so, then both needs to be in synch as much as possible. If not, bringing in that coherence between gNMI's gRPC models and openconfig-telemetry.yang module will be challenging. One would be forced to either augment existing module and define the requisite artifacts in-line with gNMI spec or may need to maintain different yang module.

Appreciate any inputs/clarifications on this front.

[robshakir]

The original intention of the telemetry model was to be agnostic to underlying export protocol, but it's likely that as things evolve, some alignment is likely needed in the context of dial-out. Particularly, today's gNMI doesn't support the persistent-subscription concept that is included in the openconfig-telemetry module. Rather, we have the dial-in collector specifying the SubscriptionList that is included in the SubscribeRequest payload of the Subscribe RPC.

One feature request that we've received is to have dial-in subscriptions be able to reference a known set of subscription parameters. This will need extension to gNMI to identify a persistent subscription. At this point, we'll also want to try and align the SubscriptionList semantics with the logic that is within the openconfig-telemetry model. I think the gNMI model is more proven and mature at this point -- so I'd expect that convergence will be towards the gNMI model.

For the dial-out model, there is also a requirement to support persistently configured subscriptions -- which is again part of an ongoing FR.

Are you currently working on an implementation that needs alignment between the two?

Another FR that it is worth mentioning in this breath is the requirement for better telemetry-on-telemetry. Operational experience has shown that we would like a number of stats relating to a telemetry implementation if they are available -- so we are looking to add new telemetry here.

Please LMK if there are other questions.

Cheers, r.

[gsindigi]

Thanks Rob for the clarifications. Glad to know about FRs; these will certainly enhance telemetry feature.

We started looking into gNMI when we had to support openconfig-telemetry module's dynamic subscriptions. Soon, we realized that gNMI model is more detailed and mature than corresponding/related artifacts in yang module. In a manner it forced us to start from the spec perspective and see what can be mapped in the module ! It would be ideal to have a convergence between two and have model the artifacts likewise. On other hand, it is not practical to have both models supported. Having said that, is there any FR related to such convergence?

At this moment, we are looking at gNMI's Subscription RPC alone as the means to leverage dynamic subscriptions of opencofig-telemetry. I presume, this will fall into dial-in model.

[ashumundra]

Hello @robshakir , I am also into the same dilemma. Which model to support to be future proof? Apart from the differences listed by @gsindigi , the tree hierarchy of both the models is quite different. For an example, whether it is ok to keep the encoding per subscription or per subscribe request having multiple subscriptions? Similarly shall we treat subscribing to one XPath as one subscription (which seems ideal) as per spec or a list of sensor Xpaths as one subscription as per yang model.

It will be hard to change the openconfig yang, it may require lot of deviations, augmentations to keep in sync with gNMI proto. I am going ahead with a custom proprietary telemetry yang which conforms more to gNMI spec than dynamic subscriptions in openconfig yang. But I hope, we don't make big changes in the current proto hierarchy which otherwise do not let us scale and align with the spec in future because of the same modification challenges assoiciated with Yang.

CC: @aashaikh