Difference between revisions of "Sweetcomb/RPCop"

From fd.io
Jump to: navigation, search
(Created page with "== 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: * '...")
 
m (→‎Requirements for sweetcomb current datastore architecture (RFC 6241))
 
(50 intermediate revisions by the same user not shown)
Line 1: Line 1:
−
== RPC Operations ==
+
= RPC Operations =
  
−
This page aims at describing which data should be read when a user uses a RPC method on sweetcomb control agent.
+
This page aims at describing which data or error should be replied when a user uses a RPC method on sweetcomb control agent.
  
−
First, there are two types of data:
+
== Context ==
−
* '''Configuration data''': 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)
+
=== Types of data ===
 +
 
 +
There are '''three types''' of data:
 +
* '''Configuration data, intented config''', ''(config=true)'': "Configuration data is the set of writable data that is required to transform a system from its initial default state into its current state." [https://tools.ietf.org/html/rfc6241 RFC6241]
 +
 
 +
* '''Operational state data''', ''(config=false)'': "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." [https://tools.ietf.org/html/rfc6244 RFC6244]
 +
** '''Applied configuration''',  (oc:operational=false) :  "Reflection of configuration parameters" [https://www.ietf.org/proceedings/94/slides/slides-94-netmod-15.pdf OpenConfig OpState]
 +
** '''Derived state''', ''(oc:operational=true)'': "Counters, Statistics, protocol-parameters" [https://www.ietf.org/proceedings/94/slides/slides-94-netmod-15.pdf OpenConfig OpState]
 +
 
 +
NB: oc:operational is openconfig specific, IETF models do not make this difference.
 +
 
 +
"[Operational state data and configuration data] 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]
 +
 
 +
=== Datastore ===
 +
 
 +
First, NETCONF and RESTCONF protocol have been defined to use datastores [RFC 6241] & [RFC 8040]  but not gNMI. Though, gNMI  support a datatype field in GetRequest which defines properties similar to a datastore.
 +
* NETCONF works with several datastores defined after.
 +
* RESTCONF "provides only a writable unified datastore". (similar to NETCONF running datastore)
 +
* gNMI communicate with a YANG speaking network device containing configuration and operational data. No notion of datastore exists.
 +
 
 +
In NETCONF environment, there are several datastores:
 +
* '''startup - [https://tools.ietf.org/html/rfc6241#section-8.7 RFC6241]''': Automatically handled by sysrepo and netopeer
 +
* '''candidate - [https://tools.ietf.org/html/rfc6241#section-8.3 RFC6241]''': Automatically handled by sysrepo and netopeer
 +
* '''running - [https://tools.ietf.org/html/rfc6241#section-5.1 RFC6241] ''': This is when changes are commited to running that VPP is configured
 +
* '''intended - [https://tools.ietf.org/html/rfc8342 RFC8342]''': Not supported by sysrepo [https://github.com/sysrepo/sysrepo/issues/954#issuecomment-336848261 yet]
 +
* '''operational - [https://tools.ietf.org/html/rfc8342 RFC8342]''': Not supported by sysrepo [https://github.com/sysrepo/sysrepo/issues/954#issuecomment-336848261 yet]
 +
 
 +
=== Architectures of datastores ===
 +
 
 +
<table>
 +
<tr><td>'''Original Architecture from RFC 6241'''</td> <td>'''NMDA Architecture from RFC 8342'''</td></tr>
 +
<tr><td>
 +
+-------------+                +-----------+
 +
| <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
 +
</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]
 +
 
 +
=== YANG tree architectures ===
  
 
Second, there are [https://www.ietf.org/proceedings/99/slides/slides-99-rtgwg-sessa-guidelines-for-yang-module-authors-on-using-nmda-00.pdf three types of organization] of YANG trees:  
 
Second, there are [https://www.ietf.org/proceedings/99/slides/slides-99-rtgwg-sessa-guidelines-for-yang-module-authors-on-using-nmda-00.pdf three types of organization] of YANG trees:  
 
* '''Openconfig style''': 'config' and 'state' containers
 
* '''Openconfig style''': 'config' and 'state' containers
−
* '''IETF withtout NMDA''': 'config' and 'state' top level trees
+
* '''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''':  
+
* '''IETF with NMDA''': leverage the targetted datastore to know if it is operational or configuration (running) data.
  
−
Third, as sweetcomb only supports NETCONF and gNMI, there are 5 RPCs supported:
+
In order to know if your IETF model supports NMDA, please use [https://www.yangcatalog.org/yang-search/ YangCatalog].
 +
 
 +
=== RPC types ===
 +
 
 +
Third, as sweetcomb only supports NETCONF and gNMI, there are 6 RPCs supported:
 +
* '''gNMI subscribe'''
 
* '''gNMI get'''
 
* '''gNMI get'''
 
* '''gNMI set'''
 
* '''gNMI set'''
Line 19: Line 114:
 
* '''NETCONF edit-config'''
 
* '''NETCONF edit-config'''
  
−
In order to know if your IETF support NMDA, please use [https://www.yangcatalog.org/yang-search/ YangCatalog].
+
== Requirements ==
 +
 
 +
=== Requirements for sweetcomb current datastore architecture (RFC 6241) ===
 +
 
 +
[[File:Rpc no rmda.png|frameless|What we are reading/writing to when RPC is performed]]
 +
 
 +
draw.io source can be found [https://github.com/YohanPipereau/drawio_sweetcomb/blob/master/rpc_no_rmda.drawio here]
 +
 
 +
=== Future work: Requirements for sweetcomb support for NMDA ===
 +
 
 +
For the moment, sweetcomb does not support NMDA.
 +
YANG models with an NMDA tree type MUST NOT be used with sweetcomb.
  
−
=== Openconfig style ===
+
* Help link: https://github.com/netmod-wg/FAQ/wiki/FAQ-related-to-NMDA-implementations#Q7
  
−
=== IETF without NMDA ===
+
=== Source for requirements ===
  
−
=== IETF with NMDA ===
+
* gNMI errors: https://github.com/openconfig/reference/blob/master/rpc/gnmi/gnmi-specification.md#347-error-handling
 +
* gNMI proto get data types: https://github.com/openconfig/gnmi/blob/master/proto/gnmi/gnmi.proto#L397
 +
* gNMI spec get datatypes: https://github.com/openconfig/reference/blob/master/rpc/gnmi/gnmi-specification.md#331-the-getrequest-message
 +
* NETCONF errors: https://tools.ietf.org/html/rfc6241#appendix-A

Latest revision as of 16:47, 1 April 2019

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.

Context

Types of data

There are three types of data:

  • Configuration data, intented config, (config=true): "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 state data, (config=false): "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
    • Applied configuration, (oc:operational=false) : "Reflection of configuration parameters" OpenConfig OpState
    • Derived state, (oc:operational=true): "Counters, Statistics, protocol-parameters" OpenConfig OpState

NB: oc:operational is openconfig specific, IETF models do not make this difference.

"[Operational state data and configuration data] 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

Datastore

First, NETCONF and RESTCONF protocol have been defined to use datastores [RFC 6241] & [RFC 8040] but not gNMI. Though, gNMI support a datatype field in GetRequest which defines properties similar to a datastore.

  • NETCONF works with several datastores defined after.
  • RESTCONF "provides only a writable unified datastore". (similar to NETCONF running datastore)
  • gNMI communicate with a YANG speaking network device containing configuration and operational data. No notion of datastore exists.

In NETCONF environment, there are several 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

Architectures of datastores

Original Architecture from RFC 6241 NMDA Architecture from RFC 8342
+-------------+                 +-----------+
| <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 6 RPCs supported:

  • gNMI subscribe
  • gNMI get
  • gNMI set
  • NETCONF get
  • NETCONF get-config
  • NETCONF edit-config

Requirements

Requirements for sweetcomb current datastore architecture (RFC 6241)

What we are reading/writing to when RPC is performed

draw.io source can be found here

Future work: Requirements for sweetcomb support for NMDA

For the moment, sweetcomb does not support NMDA. YANG models with an NMDA tree type MUST NOT be used with sweetcomb.

Source for requirements

Retrieved from "https://wiki.fd.io/index.php?title=Sweetcomb/RPCop&oldid=9287"