Difference between revisions of "Sweetcomb/RPCop"

From fd.io
Jump to: navigation, search
m (YANG tree architectures)
m (Data stores)
Line 54: Line 54:
  
 
Fourth, there are many available datastores:
 
Fourth, there are many available datastores:
* '''startup - [https://tools.ietf.org/html/rfc6241#section-8.7 RFC6241]''' : Automatically handled by sysrepo and netopeer
+
* '''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  
 
* '''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
+
* '''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]''':
 +
* '''operational - [https://tools.ietf.org/html/rfc8342 RFC8342]''':
  
 
=== Openconfig style ===
 
=== Openconfig style ===

Revision as of 23:38, 28 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.

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:

         +-------------+                 +-----------+
         | <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

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:

In order to know if your IETF support 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:
  • operational - RFC8342:

Openconfig style

Illustrate where data is fetched depending on the RPC used for an Openconfig model.

draw.io source can be found here

IETF without NMDA

IETF with NMDA