In gNMI service, the client discovers the capabilities of the gRPC server through a Capability-Discovery RPC, which consists of ‟CapabiltyRequest” and ‟CapabilityResponse” messages.
During this message exchange, the gRPC server informs the client about following attributes:
supported gNMI version
supported models
supported encodings
The SR OS server announces the supported models based on the configuration under config>system>management-interface>yang-modules. The supported models includes the Nokia YANG or OpenConfig (OC) models.
The advertised module names and organizations are as follows:
nokia-conf, org = "Nokia"
nokia-state, org = "Nokia"
openconfig, org = "OpenConfig working group" (as specified by the 'organization' in the YANG models)
version - the version number is be defined as follows:
for Nokia YANG models, the version number corresponds to an SR OS release number, for example, "16.0.R1"
for OC YANG models, the version number corresponds to a version number defined in "oc-ext:openconfig-version" that is included in the respective YANG models
for OC-YANG models, including Nokia deviations, the version number corresponds to an SR OS release number, for example, "16.0.R1"
The following is an example of a ‟Capabilities Response Message”:
Going to send message of type gnmi.CapabilityResponse:
.gnmi_version: 0.4.0
.supported_encodings (1):
.encoding: 0 = JSON
.supported_models (47):
{ .name: 'nokia-conf', .organization: 'Nokia', .version: '16.0.R1' }
{ .name: 'nokia-state', .organization: 'Nokia', .version: '16.0.R1' }
{ .name: 'openconfig-
bgp', .organization: 'OpenConfig working group', .version: '4.0.1' }
<snip>
{ .name: 'nokia-sr-openconfig-if-ethernet-deviations', .organization: 'Nokia',
.version: '16.0.R1' }
{ .name: 'nokia-sr-openconfig-if[[-ip-deviations', .organization: 'Nokia',
.version: '16.0.R1'..."