draft-ietf-netmod-revised-datastores-08.txt   draft-ietf-netmod-revised-datastores-09.txt 
skipping to change at page 1, line 15 skipping to change at page 1, line 15
Updates: 7950 (if approved) J. Schoenwaelder Updates: 7950 (if approved) J. Schoenwaelder
Intended status: Standards Track Jacobs University Intended status: Standards Track Jacobs University
Expires: June 23, 2018 P. Shafer Expires: June 23, 2018 P. Shafer
K. Watsen K. Watsen
Juniper Networks Juniper Networks
R. Wilton R. Wilton
Cisco Systems Cisco Systems
December 20, 2017 December 20, 2017
Network Management Datastore Architecture Network Management Datastore Architecture
draft-ietf-netmod-revised-datastores-08 draft-ietf-netmod-revised-datastores-09
Abstract Abstract
Datastores are a fundamental concept binding the data models written Datastores are a fundamental concept binding the data models written
in the YANG data modeling language to network management protocols in the YANG data modeling language to network management protocols
such as NETCONF and RESTCONF. This document defines an architectural such as NETCONF and RESTCONF. This document defines an architectural
framework for datastores based on the experience gained with the framework for datastores based on the experience gained with the
initial simpler model, addressing requirements that were not well initial simpler model, addressing requirements that were not well
supported in the initial model. This document updates RFC 7950. supported in the initial model. This document updates RFC 7950.
skipping to change at page 8, line 34 skipping to change at page 8, line 34
+-----------+ +-----------+
| |
v v
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
Figure 1
Note that this diagram simplifies the model: read-only (ro) and read- Note that this diagram simplifies the model: read-only (ro) and read-
write (rw) is to be understood at a conceptual level. In NETCONF, write (rw) is to be understood at a conceptual level. In NETCONF,
for example, support for <candidate> and <startup> is optional and for example, support for <candidate> and <startup> is optional and
<running> does not have to be writable. Furthermore, <startup> can <running> does not have to be writable. Furthermore, <startup> can
only be modified by copying <running> to <startup> in the only be modified by copying <running> to <startup> in the
standardized NETCONF datastore editing model. The RESTCONF protocol standardized NETCONF datastore editing model. The RESTCONF protocol
does not expose these differences and instead provides only a does not expose these differences and instead provides only a
writable unified datastore, which hides whether edits are done writable unified datastore, which hides whether edits are done
through <candidate> or by directly modifying <running> or via some through <candidate> or by directly modifying <running> or via some
other implementation specific mechanism. RESTCONF also hides how other implementation specific mechanism. RESTCONF also hides how
skipping to change at page 10, line 16 skipping to change at page 10, line 16
| <candidate> | | <startup> | | <candidate> | | <startup> |
| (ct, rw) |<---+ +--->| (ct, rw) | | (ct, rw) |<---+ +--->| (ct, rw) |
+-------------+ | | +-----------+ +-------------+ | | +-----------+
| | | | | | | |
| +-----------+ | | +-----------+ |
+-------->| <running> |<--------+ +-------->| <running> |<--------+
| (ct, rw) | | (ct, rw) |
+-----------+ +-----------+
| |
| // configuration transformations, | // configuration transformations,
| // e.g., removal of "inactive" | // e.g., removal of nodes marked as
| // nodes, expansion of templates | // "inactive", expansion of
| // templates
v v
+------------+ +------------+
| <intended> | // subject to validation | <intended> | // subject to validation
| (ct, ro) | | (ct, ro) |
+------------+ +------------+
| // changes applied, subject to | // changes applied, subject to
| // local factors, e.g., missing | // local factors, e.g., missing
| // resources, delays | // resources, delays
| |
dynamic | +-------- learned configuration dynamic | +-------- learned configuration
skipping to change at page 10, line 41 skipping to change at page 10, line 42
v v v v v v
+---------------+ +---------------+
| <operational> | <-- system state | <operational> | <-- system state
| (ct + cf, ro) | | (ct + 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 named datastores boxes denote named datastores
Figure 2
5.1. Conventional Configuration Datastores 5.1. Conventional Configuration Datastores
The conventional configuration datastores are a set of configuration The conventional configuration datastores are a set of configuration
datastores that share exactly the same datastore schema, allowing datastores that share exactly the same datastore schema, allowing
data to be copied between them. The term is meant as a generic data to be copied between them. The term is meant as a generic
umbrella description of these datastores. If a module does not umbrella description of these datastores. If a module does not
contain any configuration data nodes and it is not needed to satisfy contain any configuration data nodes and it is not needed to satisfy
any imports, then it MAY be omitted from the datastore schema for the any imports, then it MAY be omitted from the datastore schema for the
conventional configuration datastores. The set of datastores conventional configuration datastores. The set of datastores
include: include:
skipping to change at page 18, line 19 skipping to change at page 18, line 19
Actions are always invoked in the context of the operational state Actions are always invoked in the context of the operational state
datastore. The node for which the action is invoked MUST exist in datastore. The node for which the action is invoked MUST exist in
the operational state datastore. the operational state datastore.
Note that this document does not constrain the result of invoking an Note that this document does not constrain the result of invoking an
RPC or action in any way. For example, an RPC might be defined to RPC or action in any way. For example, an RPC might be defined to
modify the contents of some datastore. modify the contents of some datastore.
7. YANG Modules 7. YANG Modules
<CODE BEGINS> file "ietf-datastores@2017-08-17.yang" <CODE BEGINS> file "ietf-datastores@2017-12-20.yang"
module ietf-datastores { module ietf-datastores {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-datastores"; namespace "urn:ietf:params:xml:ns:yang:ietf-datastores";
prefix ds; prefix ds;
organization organization
"IETF Network Modeling (NETMOD) Working Group"; "IETF Network Modeling (NETMOD) Working Group";
contact contact
skipping to change at page 19, line 19 skipping to change at page 19, line 19
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX This version of this YANG module is part of RFC XXXX
(http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself (http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself
for full legal notices."; for full legal notices.";
revision 2017-08-17 { revision 2017-12-20 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Network Management Datastore Architecture"; "RFC XXXX: Network Management Datastore Architecture";
} }
/* /*
* Identities * Identities
*/ */
skipping to change at page 20, line 44 skipping to change at page 20, line 44
base datastore; base datastore;
} }
description description
"A datastore identity reference."; "A datastore identity reference.";
} }
} }
<CODE ENDS> <CODE ENDS>
<CODE BEGINS> file "ietf-origin@2017-08-17.yang" <CODE BEGINS> file "ietf-origin@2017-12-20.yang"
module ietf-origin { module ietf-origin {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-origin"; namespace "urn:ietf:params:xml:ns:yang:ietf-origin";
prefix or; prefix or;
import ietf-yang-metadata { import ietf-yang-metadata {
prefix md; prefix md;
} }
skipping to change at page 21, line 48 skipping to change at page 21, line 48
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX This version of this YANG module is part of RFC XXXX
(http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself (http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself
for full legal notices."; for full legal notices.";
revision 2017-08-17 { revision 2017-12-20 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Network Management Datastore Architecture"; "RFC XXXX: Network Management Datastore Architecture";
} }
/* /*
* Identities * Identities
*/ */
skipping to change at page 23, line 43 skipping to change at page 23, line 43
} }
/* /*
* Metadata annotations * Metadata annotations
*/ */
md:annotation origin { md:annotation origin {
type origin-ref; type origin-ref;
description description
"The 'origin' annotation can be present on any configuration "The 'origin' annotation can be present on any configuration
data node in the operational datastore. It specifies from data node in the operational state datastore. It specifies
where the node originated. If not specified for a given from where the node originated. If not specified for a given
configuration data node then the origin is the same as the configuration data node then the origin is the same as the
origin of its parent node in the data tree. The origin for origin of its parent node in the data tree. The origin for
any top level configuration data nodes must be specified."; any top level configuration data nodes must be specified.";
} }
} }
<CODE ENDS> <CODE ENDS>
8. IANA Considerations 8. IANA Considerations
skipping to change at page 24, line 24 skipping to change at page 24, line 24
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-origin URI: urn:ietf:params:xml:ns:yang:ietf-origin
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
8.2. Updates to the YANG Module Names Registry 8.2. Updates to the YANG Module Names Registry
This document registers two YANG modules in the YANG Module Names This document registers two YANG modules in the YANG Module Names
registry [RFC6020]. Following the format in [RFC6020], the the registry [RFC6020]. Following the format in [RFC6020], the following
following registrations are requested: registrations are requested:
name: ietf-datastores name: ietf-datastores
namespace: urn:ietf:params:xml:ns:yang:ietf-datastores namespace: urn:ietf:params:xml:ns:yang:ietf-datastores
prefix: ds prefix: ds
reference: RFC XXXX reference: RFC XXXX
name: ietf-origin name: ietf-origin
namespace: urn:ietf:params:xml:ns:yang:ietf-origin namespace: urn:ietf:params:xml:ns:yang:ietf-origin
prefix: or prefix: or
reference: RFC XXXX reference: RFC XXXX
skipping to change at page 32, line 9 skipping to change at page 32, line 9
to a default value, a loopback interface is automatically added by to a default value, a loopback interface is automatically added by
the system, and the result of the "speed" auto-negotiation. All of the system, and the result of the "speed" auto-negotiation. All of
this is reflected in <operational>. Note how the origin metadata this is reflected in <operational>. Note how the origin metadata
attribute for several "config true" data nodes is inherited from attribute for several "config true" data nodes is inherited from
their parent data nodes. their parent data nodes.
<system <system
xmlns="urn:example:system" xmlns="urn:example:system"
xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin"> xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
<hostname or:origin="or:dynamic">bar</hostname> <hostname or:origin="or:learned">bar</hostname>
<interface or:origin="or:intended"> <interface or:origin="or:intended">
<name>eth0</name> <name>eth0</name>
<auto-negotiation> <auto-negotiation>
<enabled or:origin="or:default">true</enabled> <enabled or:origin="or:default">true</enabled>
<speed>1000</speed> <speed>1000</speed>
</auto-negotiation> </auto-negotiation>
<speed>100</speed> <speed>100</speed>
<address> <address>
<ip>2001:db8::10</ip> <ip>2001:db8::10</ip>
<prefix-length>64</prefix-length> <prefix-length>64</prefix-length>
</address> </address>
<address or:origin="or:dynamic"> <address or:origin="or:learned">
<ip>2001:db8::1:100</ip> <ip>2001:db8::1:100</ip>
<prefix-length>64</prefix-length> <prefix-length>64</prefix-length>
</address> </address>
</interface> </interface>
<interface or:origin="or:system"> <interface or:origin="or:system">
<name>lo0</name> <name>lo0</name>
<address> <address>
<ip>::1</ip> <ip>::1</ip>
<prefix-length>128</prefix-length> <prefix-length>128</prefix-length>
 End of changes. 12 change blocks. 
13 lines changed or deleted 18 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/