...
- <intended>: which contains validated configuration data that a client application intends to be in effect
- <operational>: which contains operational state data as well as configuration data that is actually in effect.
Intention of RFC 9144
RFC 9144 YANG data model that defines RPCs intended to be used in conjunction with NETCONF [RFC6241] or RESTCONF [RFC8040]. These RPCs allow a client to request a server to compare two NMDA datastores and report any differences.
RFC 9144 Data Model and the current approach of CPS Delta
The core of the RFC 9144 solution is a new management operation, <compare>, that compares the data tree contents of two datastores. The operation checks whether there are any differences in values or in data nodes that are contained in either datastore and returns any differences as output. The output is returned in the format specified in YANG Patch [RFC8072].
...
| Code Block |
|---|
| title | Sample JSON Patch document |
|---|
| collapse | true |
|---|
|
PATCH /my/data HTTP/1.1
Host: example.org
Content-Length: 326
Content-Type: application/json-patch+json
If-Match: "abc123"
[
{ "op": "test", "path": "/a/b/c", "value": "foo" },
{ "op": "remove", "path": "/a/b/c" },
{ "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] },
{ "op": "replace", "path": "/a/b/c", "value": 42 },
{ "op": "move", "from": "/a/b/c", "path": "/a/b/d" },
{ "op": "copy", "from": "/a/b/d", "path": "/a/b/e" }
] |
RFC 9144 Overview and example of RESTCONF
The YANG data model defines the <compare> operation as a new RPC. The operation takes the following input parameters:
...
| Code Block |
|---|
| title | Structure of ietf-nmda-compare. Source: RFC9144 |
|---|
| collapse | true |
|---|
|
module: ietf-nmda-compare
rpcs:
+---x compare
+---w input
| +---w source identityref
| +---w target identityref
| +---w all? empty
| +---w report-origin? empty
| +---w (filter-spec)?
| +--:(subtree-filter)
| | +---w subtree-filter?
| +--:(xpath-filter)
| +---w xpath-filter? yang:xpath1.0 {nc:xpath}?
+--ro output
+--ro (compare-response)?
+--:(no-matches)
| +--ro no-matches? empty
+--:(differences)
+--ro differences
+--ro yang-patch
+--ro patch-id string
+--ro comment? string
+--ro edit* [edit-id]
+--ro edit-id string
+--ro operation enumeration
+--ro target target-resource-offset
+--ro point? target-resource-offset
+--ro where? enumeration
+--ro value?
+--ro source-value? |
RESTCONF Example
Sample YANG Model
| Code Block |
|---|
| title | YANG Model |
|---|
| collapse | true |
|---|
|
container interfaces {
description
"Interface parameters.";
list interface {
key "name";
leaf name {
type string;
description
"The name of the interface.";
}
leaf description {
type string;
description
"A textual description of the interface.";
}
leaf enabled {
type boolean;
default "true";
description
"This leaf contains the configured, desired state of the
interface.";
}
}
} |
Sample Data
| Code Block |
|---|
| title | Intended/Reference Data |
|---|
| collapse | true |
|---|
|
{
"interfaces": {
"interface": {
"name": "eth0",
"enabled": false,
"description": "ip interface"
}
}
} |
...
| Code Block |
|---|
| title | Operational/Comparand/Target Data |
|---|
| collapse | true |
|---|
|
{
"interfaces": {
"interface": {
"name": "eth0",
"enabled": true
}
}
} |
Request in RESTCONF
| Code Block |
|---|
| title | POST Request |
|---|
| collapse | true |
|---|
|
POST /restconf/operations/ietf-nmda-compare:compare HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json
Accept: application/yang-data+json
{ "ietf-nmda-compare:input" : {
"source" : "ietf-datastores:operational",
"target" : "ietf-datastores:intended",
"report-origin" : null,
"xpath-filter" : "/ietf-interfaces:interfaces"
}
} |
Response in RESTCONF
| Code Block |
|---|
| title | Response |
|---|
| collapse | true |
|---|
|
HTTP/1.1 200 OK
Date: Thu, 24 Jan 2019 20:56:30 GMT
Server: example-server
Content-Type: application/yang-data+json
{ "ietf-nmda-compare:output" : {
"differences" : {
"ietf-yang-patch:yang-patch" : {
"patch-id" : "interface status",
"comment" : "diff between intended (source) and operational",
"edit" : [
{
"edit-id" : "1",
"operation" : "replace",
"target" : "/ietf-interfaces:interface=eth0/enabled",
"value" : {
"ietf-interfaces:interface/enabled" : "false"
},
"source-value" : {
"ietf-interfaces:interface/enabled" : "true",
"@ietf-interfaces:interface/enabled" : {
"ietf-origin:origin" : "ietf-origin:learned"
}
}
},
{
"edit-id" : "2",
"operation" : "create",
"target" : "/ietf-interfaces:interface=eth0/description",
"value" : {
"ietf-interface:interface/description" : "ip interface"
}
}
]
}
}
}
} |
Open Questions
- What are the advantages of using RFC 9144?
- Any different than current approach? Can it be modified as per requirements of CPS? For example using xpath format
- The documentation defines a POST operation to find the delta. Does this mean this approach intends to persist the Delta generated ti a database? If so will it be an indefinite persistence of delta report or will the delta be removed from storage after a specific time period.
- The current approach is a GET operation with no intention to persist the delta report
