openconfig
Can a leaf attribute be both ON-CHANGE and SAMPLE type?
Consider the below two event-driven attributes which fit "on-change" mode type.
/interfaces/interface/state/admin-status /interfaces/interface/state/oper-status
-
If gnmi "sample" mode subscribe rpc request is received for these leaf level attributes, should the gnmi server reject the request? And only accept "on-change" or "target-defined" mode for these attributes? Or is it left to the implementations?
-
Do implementations have to exclusively classify leaf level attributes as SAMPLE or ON-CHANGE mode type for stream-mode? Or can some attributes be of "both" type?
Clarity on this in gnmi spec is needed. For interoperability across vendors, one would prefer to see each attribute in the openconfig data models to be annotated with (SAMPLE, ON-CHANGE or both) type. I would like to hear experts opinion on this.
Thanks, Raghu
There is no expectation that any particular path is of a single type -- a user may want to subscribe to these leaves as a SAMPLE subscription (where the contract is "please send me this every X"), or they may wish to subscribe as ON_CHANGE if their application requires this. This is a property of the subscription, rather than the leaf.
Targets may have particular modes, or subscription rates that they do not support -- this is reasonable, and if they do not support a particular subscription then they should return an error.
It is not reasonable that the OpenConfig models dictate a single way that paths are subscribed to -- different operators have different requirements, and hence there is no single uniform way that is required. A set of compliance tests that enumerate some expectations are in github.com/openconfig/featureprofiles. Equally, there are operator-specific requirements that are shared with implementors that could guide your implementation.
TARGET_DEFINED provides a means by which the target can pick the best mode for it to send data, and the subscription request can be simplified. In this case, the data models provide a hint as to what the most efficient way to send the data is in some cases, but equally, this is not a strict requirement -- because a target may say "I actually do not yet support oper-status as ON_CHANGE so I will send it as SAMPLE in this subscription". This contract is obviously a lot looser, but helps with the changing state of implementations over time.