Difference between revisions of "Sweetcomb/RPCop"
From fd.io
m (→RPC Operations) |
m (→Openconfig style) |
||
| Line 22: | Line 22: | ||
=== Openconfig style === | === Openconfig style === | ||
| + | |||
| + | [[File:Openconfig-rpc.png|thumb|Illustrate where data is fetched depending on the RPC used for an Openconfig model.]] | ||
=== IETF without NMDA === | === IETF without NMDA === | ||
=== IETF with NMDA === | === IETF with NMDA === | ||
Revision as of 17:37, 21 March 2019
RPC Operations
This page aims at describing which data should be read when a user uses a RPC method on sweetcomb control agent.
First, there are two types of data:
- Configuration data/desired state: data that is read from an intermediate database (ex: data fetched by sr_get_item)
- Operational data: fresh data directly read from the networking devices (ex: telemetry data, all data fetched with VAPI)
Second, there are three types of organization of YANG trees:
- Openconfig style: 'config' and 'state' containers
- IETF withtout NMDA: 'config' and 'state' top level trees
- IETF with NMDA:
Third, as sweetcomb only supports NETCONF and gNMI, there are 5 RPCs supported:
- gNMI get
- gNMI set
- NETCONF get
- NETCONF get-config
- NETCONF edit-config
In order to know if your IETF support NMDA, please use YangCatalog.
Openconfig style
