grpcyang

In gNMI, What's the difference between the "Origin" that can be specified in a path and "use_model" option from get/subscribe requests?


I'm trying to understand and write tests for a gNMI target application and have been reading the gNMI spec. It specifies that a path can have an "origin" which specifies a schema to use. Examples it gives are OpenConfig or CLI. In the GetRequest and SubscribeRequest Sections it says one can also include a "use_model" argument. This argument should specify a data model.

I don't understand the difference between a data model and schema.

In my understanding, the target will implement one or more YANG models to model its data. Would that YANG model be the Schema or the Data model? If the Device's YANG model is it's Schema then what would its Data Model be or vice versa?

I've found an example where Origin looks to be used to specify the device's YANG Model: Cisco gNMI info showing Origin can be used to specify the device's yang model (source site:, Table 3)

This seems to indicate that "Origin" is where you specify the YANG model (or other model) but then what is "use_model" for??

Thanks for the help in advance


Solution

  • I had a summer student just finishing who worked on our implementation of gNMI. We struggled a bit with this question as well.

    One clue came from the tools that Google provide at https://github.com/google/gnxi, which we were using to test our implementation. In, for example, the gnmi_get tool, the command line parameter "prefix" is a simple string which the help says can take on values like "oc" (for openconfig) or "srl" (for I don't know what). But this parameter is used to set the Origin field of the Prefix message. Setting Path values in the prefix does not appear to be supported by these tools.

    Given that we didn't want to mess around with the tools too much, we decided to support Origin as the tool does. Origin values we are looking to support are "openconfig" and "ietf", and the use of these values is to create a mapping from origin and the first element in the path to a particular data model, when there would otherwise be ambiguity because the first element is shared among different models (for example openconfig-interfaces and ietf-interfaces).

    This begs a whole lot of questions like what about use_models (as you asked) or what if origin appears elsewhere? This may well be something in real-world implementations that depends on the implementer, but hopefully when working with a particular target you will have enough information to be able to format your messages right.

    To answer your other question:

    On re-reading this answer I realise that it is fairly difficult to understand. I will try to revisit in case you have follow-up questions.