Update gnmi hld #112
Update gnmi hld #112
Conversation
Signed-off-by: Tejaswi Goel <[email protected]>
Signed-off-by: Tejaswi Goel <[email protected]>
* Update the sFlow admin-state from enable/disable to up/down. Signed-off-by: Garrick He <[email protected]>
Add Docker to Host communication Design document
HLD - Openconfig support for FDB dump using management framework interfaces (CLI/REST API/gNMI)
* Add default polling-interval. * Update sFlow data model. Signed-off-by: Garrick He <[email protected]>
* Fix revision table format. Signed-off-by: Garrick He <[email protected]>
* Fix revision table format. Signed-off-by: Garrick He <[email protected]>
…quirements in mgmt framework and dependencies on existing features. 2. add details for dynamic route leaking
sFlow HLD Document
This revision incorporates formatting changes to improve rendering and readability of the document.
Add formatting fixes and update content in several sections. Add documentation on the limitations of the initial implementation and desirable supplementary file transfer capability in a future release to make the current implementation fully compatible with a management framework based client interface.
In-band management via mgmt VRF
Added details for response_type in Generic client
Developer Guide: Update DB access layer with link to HLD
PIM HLD Minor updates (Yang changes updates & show cmds spacing updates)
REST server profiling data collection procedure
Updated switchport trunk commands for VLAN
Update SONiC_OC_Interface_HLD.md
* Add HLD for platform command Signed-off-by: Garrick He <[email protected]>
* Add platform firmware information. Signed-off-by: Garrick He <[email protected]>
Alias Feature HLD
management framework NTP support HLD
HLD for Interface range Specification feature
Platform HLD
|
|
||
| ###### 3.2.2.5.11 API Versioning | ||
|
|
||
| gNMI server will allow clients to specify API version through a custom gNMI Extension field BundleVersion with extentsion id 700. |
There was a problem hiding this comment.
I am not an expert in gNMI; just wondering if "custom gNMI Extension field BundleVersion with extentsion id 700" conveys all details to the developer. I feel you can include the protobuf message definition for the extension message.
Also we can explicitly mention that the standard ModelData in Get and Subscribe RPCs will be ignored.
doc/mgmt/Management Framework.md
Outdated
|
|
||
| Version checks are bypassed if Accept-Version header is not present in the request. | ||
|
|
||
| For YANG defined RESTCONF APIs, the server's version can be discovered through the standard Capabilities gNMI RPC. |
There was a problem hiding this comment.
I feel we should avoid using term "RESTCONF APIs" in gNMI section.
Also, I guess the capabilities PRC will return supported yang bundle version through an extension message. Please provide that information as well.
There was a problem hiding this comment.
Ok I added the proto definition and referenced the sonic.proto file.
|
|
||
| gNOI Allows the gNMI server to add custom RPC operations. gNOI Provides a number of standardized RPCs, however currently on the the system/Time RPC is available from those RPCs. | ||
|
|
||
| OpenConfig and Sonic customer RPCs are also available via gNOI via the sonic_gnoi.proto file in the telemetry repository. This file provides the protobuf definition for calling these RPCs as well as the format of their arguments and their responses. |
There was a problem hiding this comment.
Table at section 3.2.2.5.7 says any oc-rpc will be mapped to translib.Action. Is it automatic? Will the sonic_gnoi.proto autogenerated from yang?
There was a problem hiding this comment.
No, there is no auto-generation currently.
There was a problem hiding this comment.
In that case, can we change "ANY OC-RPC" to "gNOI RPC" in table 3.2.2.5.7? All oc-yang defined RPCs may not have corresponding gNOI RPCs.
Add more sections for gNMI and update some outdated info.