Difference between revisions of "Sweetcomb/RPCop"
From fd.io
m (→Data stores) |
m (→RPC Operations) |
||
| Line 1: | Line 1: | ||
== RPC Operations == | == RPC Operations == | ||
| − | This page aims at describing which data should be | + | This page aims at describing which data or error should be replied when a user uses a RPC method on sweetcomb control agent. |
=== Types of data === | === Types of data === | ||
| Line 10: | Line 10: | ||
"These two values may be different for a number of reasons, e.g., system internal interactions with hardware, interaction with protocols or other devices, or simply the time it takes to propagate a configuration change to the software and hardware components of a system." | "These two values may be different for a number of reasons, e.g., system internal interactions with hardware, interaction with protocols or other devices, or simply the time it takes to propagate a configuration change to the software and hardware components of a system." | ||
[https://tools.ietf.org/html/rfc8342#section-2 RFC8342] | [https://tools.ietf.org/html/rfc8342#section-2 RFC8342] | ||
| + | |||
Original Model of Datastores as described per [https://tools.ietf.org/html/rfc6241 RFC6241]: | Original Model of Datastores as described per [https://tools.ietf.org/html/rfc6241 RFC6241]: | ||
| + | |||
| + | <table> | ||
| + | <tr><td>RFC 6241</td> <td>RFC8888</td></tr> | ||
| + | <tr><td> | ||
| + | |||
| + | |||
+-------------+ +-----------+ | +-------------+ +-----------+ | ||
| Line 26: | Line 33: | ||
operational state <--- control plane | operational state <--- control plane | ||
(cf, ro) | (cf, ro) | ||
| − | |||
ct = config true; cf = config false | ct = config true; cf = config false | ||
rw = read-write; ro = read-only | rw = read-write; ro = read-only | ||
boxes denote datastores | boxes denote datastores | ||
| + | </td> | ||
| + | <td> | ||
| + | +-------------+ +-----------+ | ||
| + | | <candidate> | | <startup> | | ||
| + | | (ct, rw) |<---+ +--->| (ct, rw) | | ||
| + | +-------------+ | | +-----------+ | ||
| + | | | | | | ||
| + | | +-----------+ | | ||
| + | +-------->| <running> |<--------+ | ||
| + | | (ct, rw) | | ||
| + | +-----------+ | ||
| + | | | ||
| + | | // configuration transformations, | ||
| + | | // e.g., removal of nodes marked as | ||
| + | | // "inactive", expansion of | ||
| + | | // templates | ||
| + | v | ||
| + | +------------+ | ||
| + | | <intended> | // subject to validation | ||
| + | | (ct, ro) | | ||
| + | +------------+ | ||
| + | | // changes applied, subject to | ||
| + | | // local factors, e.g., missing | ||
| + | | // resources, delays | ||
| + | | | ||
| + | dynamic | +-------- learned configuration | ||
| + | configuration | +-------- system configuration | ||
| + | datastores -----+ | +-------- default configuration | ||
| + | | | | | ||
| + | v v v | ||
| + | +---------------+ | ||
| + | | <operational> | <-- system state | ||
| + | | (ct + cf, ro) | | ||
| + | +---------------+ | ||
| + | |||
| + | </td></table> | ||
| + | |||
Source: [https://tools.ietf.org/html/rfc8342#section-4.1 RFC8342] | Source: [https://tools.ietf.org/html/rfc8342#section-4.1 RFC8342] | ||
Revision as of 22:37, 29 March 2019
Contents
RPC Operations
This page aims at describing which data or error should be replied when a user uses a RPC method on sweetcomb control agent.
Types of data
- Configuration data/desired state: "Configuration data is the set of writable data that is required to transform a system from its initial default state into its current state." RFC6241
- Operational data: "Operational state data is a set of data that has been obtained by the system at runtime and influences the system's behavior similar to configuration data. In contrast to configuration data, operational state is transient and modified by interactions with internal components or other systems via specialized protocols." RFC6244
"These two values may be different for a number of reasons, e.g., system internal interactions with hardware, interaction with protocols or other devices, or simply the time it takes to propagate a configuration change to the software and hardware components of a system." RFC8342
Original Model of Datastores as described per RFC6241:
| RFC 6241 | RFC8888 |
|
+-------------+ +-----------+
| <candidate> | | <startup> |
| (ct, rw) |<---+ +--->| (ct, rw) |
+-------------+ | | +-----------+
| | | |
| +-----------+ |
+-------->| <running> |<--------+
| (ct, rw) |
+-----------+
|
v
operational state <--- control plane
(cf, ro)
ct = config true; cf = config false
rw = read-write; ro = read-only
boxes denote datastores
|
+-------------+ +-----------+
| <candidate> | | <startup> |
| (ct, rw) |<---+ +--->| (ct, rw) |
+-------------+ | | +-----------+
| | | |
| +-----------+ |
+-------->| <running> |<--------+
| (ct, rw) |
+-----------+
|
| // configuration transformations,
| // e.g., removal of nodes marked as
| // "inactive", expansion of
| // templates
v
+------------+
| <intended> | // subject to validation
| (ct, ro) |
+------------+
| // changes applied, subject to
| // local factors, e.g., missing
| // resources, delays
|
dynamic | +-------- learned configuration
configuration | +-------- system configuration
datastores -----+ | +-------- default configuration
| | |
v v v
+---------------+
| <operational> | <-- system state
| (ct + cf, ro) |
+---------------+
|
Source: RFC8342
YANG tree architectures
Second, there are three types of organization of YANG trees:
- Openconfig style: 'config' and 'state' containers
- IETF withtout NMDA: two separate branches rooted at the root of the data tree: one branch for configuration data objects and one branch for operational state data objects.
- IETF with NMDA: leverage the targetted datastore to know if it is operational or configuration (running) data.
In order to know if your IETF model supports NMDA, please use YangCatalog.
RPC types
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
Data stores
Fourth, there are many available datastores:
- startup - RFC6241: Automatically handled by sysrepo and netopeer
- candidate - RFC6241: Automatically handled by sysrepo and netopeer
- running - RFC6241 : This is when changes are commited to running that VPP is configured
- intended - RFC8342: Not supported by sysrepo yet
- operational - RFC8342: Not supported by sysrepo yet
Openconfig style
draw.io source can be found here
