draft-ietf-netmod-revised-datastores-03.txt   draft-ietf-netmod-revised-datastores-04.txt 
Network Working Group M. Bjorklund Network Working Group M. Bjorklund
Internet-Draft Tail-f Systems Internet-Draft Tail-f Systems
Intended status: Standards Track J. Schoenwaelder Intended status: Standards Track J. Schoenwaelder
Expires: January 4, 2018 Jacobs University Expires: February 25, 2018 Jacobs University
P. Shafer P. Shafer
K. Watsen K. Watsen
Juniper Networks Juniper Networks
R. Wilton R. Wilton
Cisco Systems Cisco Systems
July 3, 2017 August 24, 2017
Network Management Datastore Architecture Network Management Datastore Architecture
draft-ietf-netmod-revised-datastores-03 draft-ietf-netmod-revised-datastores-04
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. supported in the initial model.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2018. This Internet-Draft will expire on February 25, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Original Model of Datastores . . . . . . . . . . . . . . 6 3.1. Original Model of Datastores . . . . . . . . . . . . . . 7
4. Architectural Model of Datastores . . . . . . . . . . . . . . 8 4. Architectural Model of Datastores . . . . . . . . . . . . . . 8
4.1. The Startup Configuration Datastore (<startup>) . . . . . 9 4.1. The Startup Configuration Datastore (<startup>) . . . . . 9
4.2. The Candidate Configuration Datastore (<candidate>) . . . 10 4.2. The Candidate Configuration Datastore (<candidate>) . . . 10
4.3. The Running Configuration Datastore (<running>) . . . . . 10 4.3. The Running Configuration Datastore (<running>) . . . . . 10
4.4. The Intended Configuration Datastore (<intended>) . . . . 10 4.4. The Intended Configuration Datastore (<intended>) . . . . 10
4.5. Conventional Configuration Datastores . . . . . . . . . . 11 4.5. Conventional Configuration Datastores . . . . . . . . . . 11
4.6. Dynamic Datastores . . . . . . . . . . . . . . . . . . . 11 4.6. Dynamic Configuration Datastores . . . . . . . . . . . . 11
4.7. The Operational State Datastore (<operational>) . . . . . 11 4.7. The Operational State Datastore (<operational>) . . . . . 11
4.7.1. Missing Resources . . . . . . . . . . . . . . . . . . 12 4.7.1. Remnant Configuration . . . . . . . . . . . . . . . . 12
4.7.2. System-controlled Resources . . . . . . . . . . . . . 13 4.7.2. Missing Resources . . . . . . . . . . . . . . . . . . 13
4.7.3. Origin Metadata Annotation . . . . . . . . . . . . . 13 4.7.3. System-controlled Resources . . . . . . . . . . . . . 13
5. Implications on YANG . . . . . . . . . . . . . . . . . . . . 14 4.7.4. Origin Metadata Annotation . . . . . . . . . . . . . 13
5.1. XPath Context . . . . . . . . . . . . . . . . . . . . . . 14 5. Implications on YANG . . . . . . . . . . . . . . . . . . . . 15
6. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. XPath Context . . . . . . . . . . . . . . . . . . . . . . 15
6. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7.1. Updates to the IETF XML Registry . . . . . . . . . . . . 21 7.1. Updates to the IETF XML Registry . . . . . . . . . . . . 21
7.2. Updates to the YANG Module Names Registry . . . . . . . . 22 7.2. Updates to the YANG Module Names Registry . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Guidelines for Defining Datastores . . . . . . . . . 24 Appendix A. Guidelines for Defining Datastores . . . . . . . . . 24
A.1. Define which YANG modules can be used in the datastore . 24 A.1. Define which YANG modules can be used in the datastore . 24
A.2. Define which subset of YANG-modeled data applies . . . . 25 A.2. Define which subset of YANG-modeled data applies . . . . 25
A.3. Define how data is actualized . . . . . . . . . . . . . . 25 A.3. Define how data is actualized . . . . . . . . . . . . . . 25
A.4. Define which protocols can be used . . . . . . . . . . . 25 A.4. Define which protocols can be used . . . . . . . . . . . 25
A.5. Define YANG identities for the datastore . . . . . . . . 25 A.5. Define YANG identities for the datastore . . . . . . . . 25
Appendix B. Ephemeral Dynamic Datastore Example . . . . . . . . 25 Appendix B. Ephemeral Dynamic Configuration Datastore Example . 26
Appendix C. Example Data . . . . . . . . . . . . . . . . . . . . 27 Appendix C. Example Data . . . . . . . . . . . . . . . . . . . . 27
C.1. System Example . . . . . . . . . . . . . . . . . . . . . 27 C.1. System Example . . . . . . . . . . . . . . . . . . . . . 27
C.2. BGP Example . . . . . . . . . . . . . . . . . . . . . . . 29 C.2. BGP Example . . . . . . . . . . . . . . . . . . . . . . . 29
C.2.1. Datastores . . . . . . . . . . . . . . . . . . . . . 31 C.2.1. Datastores . . . . . . . . . . . . . . . . . . . . . 31
C.2.2. Adding a Peer . . . . . . . . . . . . . . . . . . . . 31 C.2.2. Adding a Peer . . . . . . . . . . . . . . . . . . . . 31
C.2.3. Removing a Peer . . . . . . . . . . . . . . . . . . . 32 C.2.3. Removing a Peer . . . . . . . . . . . . . . . . . . . 32
C.3. Interface Example . . . . . . . . . . . . . . . . . . . . 33 C.3. Interface Example . . . . . . . . . . . . . . . . . . . . 33
C.3.1. Pre-provisioned Interfaces . . . . . . . . . . . . . 33 C.3.1. Pre-provisioned Interfaces . . . . . . . . . . . . . 33
C.3.2. System-provided Interface . . . . . . . . . . . . . . 34 C.3.2. System-provided Interface . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
skipping to change at page 3, line 26 skipping to change at page 3, line 27
management data models to network management protocols. Agreement on management data models to network management protocols. Agreement on
a common architectural model of datastores ensures that data models a common architectural model of datastores ensures that data models
can be written in a network management protocol agnostic way. This can be written in a network management protocol agnostic way. This
architectural framework identifies a set of conceptual datastores but architectural framework identifies a set of conceptual datastores but
it does not mandate that all network management protocols expose all it does not mandate that all network management protocols expose all
these conceptual datastores. This architecture is agnostic with these conceptual datastores. This architecture is agnostic with
regard to the encoding used by network management protocols. regard to the encoding used by network management protocols.
2. Terminology 2. Terminology
This document defines the following terms: This document defines the following terminology. Some of the terms
are revised definitions of terms originally defined in [RFC6241] and
[RFC7950] (see also section Section 3). The revised definitions are
semantically equivalent with the definitions found in [RFC6241] and
[RFC7950]. It is expected that the revised definitions provided in
this section will replace the definitions in [RFC6241] and [RFC7950]
when these documents are revised.
o datastore: A conceptual place to store and access information. A o datastore: A conceptual place to store and access information. A
datastore might be implemented, for example, using files, a datastore might be implemented, for example, using files, a
database, flash memory locations, or combinations thereof. A database, flash memory locations, or combinations thereof. A
datastore maps to an instantiated YANG data tree. datastore maps to an instantiated YANG data tree.
o configuration: Data that is required to get a device from its o configuration: Data that is required to get a device from its
initial default state into a desired operational state. This data initial default state into a desired operational state. This data
is modeled in YANG using "config true" nodes. Configuration can is modeled in YANG using "config true" nodes. Configuration can
originate from different sources. originate from different sources.
skipping to change at page 4, line 29 skipping to change at page 4, line 35
o conventional configuration datastore: One of the following set of o conventional configuration datastore: One of the following set of
configuration datastores: <running>, <startup>, <candidate>, and configuration datastores: <running>, <startup>, <candidate>, and
<intended>. These datastores share a common schema and protocol <intended>. These datastores share a common schema and protocol
operations allow copying data between these datastores. The term operations allow copying data between these datastores. The term
"conventional" is chosen as a generic umbrella term for these "conventional" is chosen as a generic umbrella term for these
datastores. datastores.
o conventional configuration: Configuration that is stored in any of o conventional configuration: Configuration that is stored in any of
the conventional configuration datastores. the conventional configuration datastores.
o dynamic datastore: A datastore holding data obtained dynamically o dynamic configuration datastore: A configuration datastore holding
during the operation of a device through interaction with other configuration obtained dynamically during the operation of a
systems, rather than through one of the conventional configuration device through interaction with other systems, rather than through
datastores. one of the conventional configuration datastores.
o dynamic configuration: Configuration obtained via a dynamic o dynamic configuration: Configuration obtained via a dynamic
datastore. configuration datastore.
o learned configuration: Configuration that has been learned via o learned configuration: Configuration that has been learned via
protocol interactions with other systems that is not conventional protocol interactions with other systems and that is neither
or dynamic configuration. conventional nor dynamic configuration.
o system configuration: Configuration that is supplied by the device o system configuration: Configuration that is supplied by the device
itself. itself.
o default configuration: Configuration that is not explicitly o default configuration: Configuration that is not explicitly
provided but for which a value defined in the data model is used. provided but for which a value defined in the data model is used.
o applied configuration: Configuration that is actively in use by a o applied configuration: Configuration that is actively in use by a
device. Applied configuration originates from conventional, device. Applied configuration originates from conventional,
dynamic, learned, system and default configuration. dynamic, learned, system and default configuration.
skipping to change at page 7, line 43 skipping to change at page 7, line 48
configuration is made persistent. Note that implementations may also configuration is made persistent. Note that implementations may also
have additional datastores that can propagate changes to <running>. have additional datastores that can propagate changes to <running>.
NETCONF explicitly mentions so called named datastores. NETCONF explicitly mentions so called named datastores.
Some observations: Some observations:
o Operational state has not been defined as a datastore although o Operational state has not been defined as a datastore although
there were proposals in the past to introduce an operational state there were proposals in the past to introduce an operational state
datastore. datastore.
o The NETCONF <get/> operation returns the content of the <running> o The NETCONF <get/> operation returns the content of the running
configuration datastore together with the operational state. It configuration datastore together with the operational state. It
is therefore necessary that "config false" data is in a different is therefore necessary that "config false" data is in a different
branch than the "config true" data if the operational state can branch than the "config true" data if the operational state can
have a different lifetime compared to configuration or if have a different lifetime compared to configuration or if
configuration is not immediately or successfully applied. configuration is not immediately or successfully applied.
o Several implementations have proprietary mechanisms that allow o Several implementations have proprietary mechanisms that allow
clients to store inactive data in <running>; this inactive data is clients to store inactive data in <running>; this inactive data is
only exposed to clients that indicate that they support the only exposed to clients that indicate that they support the
concept of inactive data; clients not indicating support for concept of inactive data; clients not indicating support for
skipping to change at page 9, line 27 skipping to change at page 9, line 27
| // nodes, expansion of templates | // nodes, 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
| |
| +-------- learned configuration dynamic | +-------- learned configuration
dynamic | +-------- system configuration configuration | +-------- system configuration
datastores -----+ | +-------- default configuration datastores -----+ | +-------- default configuration
| | | | | |
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
skipping to change at page 11, line 37 skipping to change at page 11, line 37
Other conventional configuration datastores may be defined in future Other conventional configuration datastores may be defined in future
documents. documents.
The flow of data between these datastores is depicted in section The flow of data between these datastores is depicted in section
Section 4. Section 4.
The specific protocols may define explicit operations to copy between The specific protocols may define explicit operations to copy between
these datastores, e.g., NETCONF's <copy-config> operation. these datastores, e.g., NETCONF's <copy-config> operation.
4.6. Dynamic Datastores 4.6. Dynamic Configuration Datastores
The model recognizes the need for dynamic datastores that are, by The model recognizes the need for dynamic configuration datastores
definition, not part of the persistent configuration of a device. In that are, by definition, not part of the persistent configuration of
some contexts, these have been termed ephemeral datastores since the a device. In some contexts, these have been termed ephemeral
information is ephemeral, i.e., lost upon reboot. The dynamic datastores since the information is ephemeral, i.e., lost upon
datastores interact with the rest of the system through reboot. The dynamic configuration datastores interact with the rest
<operational>. of the system through <operational>.
4.7. The Operational State Datastore (<operational>) 4.7. The Operational State Datastore (<operational>)
The operational state datastore (<operational>) is a read-only The operational state datastore (<operational>) is a read-only
datastore that consists of all "config true" and "config false" nodes datastore that consists of all "config true" and "config false" nodes
defined in the schema. In the original NETCONF model the operational defined in the schema. In the original NETCONF model the operational
state only had "config false" nodes. The reason for incorporating state only had "config false" nodes. The reason for incorporating
"config true" nodes here is to be able to expose all operational "config true" nodes here is to be able to expose all operational
settings without having to replicate definitions in the data models. settings without having to replicate definitions in the data models.
<operational> contains system state and all configuration actually <operational> contains system state and all configuration actually
used by the system. This includes all applied configuration from used by the system. This includes all applied configuration from
<intended>, system-provided configuration, and default values defined <intended>, learned configuration, system-provided configuration, and
by any supported data models. In addition, <operational> also default values defined by any supported data models. In addition,
contains applied data from dynamic datastores. <operational> also contains applied configuration from dynamic
configuration datastores.
Requests to retrieve nodes from <operational> always return the value Requests to retrieve nodes from <operational> always return the value
in use if the node exists, regardless of any default value specified in use if the node exists, regardless of any default value specified
in the YANG module. If no value is returned for a given node, then in the YANG module. If no value is returned for a given node, then
this implies that the node is not used by the device. this implies that the node is not used by the device.
The interpretation of what constitutes as being "in use" by the
system is dependent on both the schema definition and the device
implementation. Generally, functionality that is enabled and
operational on the system would be considered as being 'in use'.
Conversely, functionality that is neither enabled nor operational on
the system could be considered as not being 'in use', and hence may
be omitted from <operational>.
<operational> should conform to any constraints specified in the data
model, but given the principal aim of returning "in use" values, it
is possible that constraints may be violated under some
circumstances, e.g., an abnormal value is "in use", or due to remnant
configuration (described below). Note, that deviations are still
used when it is known in advance that a device does not fully conform
to the <operational> schema.
Only semantic constraints may be violated, these are the YANG "when",
"must", "mandatory", "unique", "min-elements", and "max-elements"
statements.
Syntactic constraints cannot be violated, including hierarchical
organization, identifiers, and type-based constraints. If a node in
<operational> does not meet the syntactic constraints then it cannot
be returned, and some other mechanism should be used to flag the
error.
<operational> does not persist across reboots. <operational> does not persist across reboots.
4.7.1. Remnant Configuration
Changes to configuration may take time to percolate through to Changes to configuration may take time to percolate through to
<operational>. During this period, <operational> may contain nodes <operational>. During this period, <operational> may contain nodes
for both the previous and current configuration, as closely as for both the previous and current configuration, as closely as
possible tracking the current operation of the device. Such remnant possible tracking the current operation of the device. Such remnant
configuration from the previous configuration persists until the configuration from the previous configuration persists until the
system has released resources used by the newly-deleted configuration system has released resources used by the newly-deleted configuration
(e.g., network connections, memory allocations, file handles). (e.g., network connections, memory allocations, file handles).
As a result of remnant configuration, the semantic constraints Remant configuration is a common example of where the semantic
defined in the data model cannot be relied upon for <operational>, constraints defined in the data model cannot be relied upon for
since the system may have remnant configuration whose constraints <operational>, since the system may have remnant configuration whose
were valid with the previous configuration and that are not valid constraints were valid with the previous configuration and that are
with the current configuration. Since constraints on "config false" not valid with the current configuration. Since constraints on
nodes may refer to "config true" nodes, remnant configuration may "config false" nodes may refer to "config true" nodes, remnant
force the violation of those constraints. The constraints that may configuration may force the violation of those constraints.
not hold include "when", "must", "min-elements", and "max-elements".
Note that syntactic constraints cannot be violated, including
hierarchical organization, identifiers, and type-based constraints.
4.7.1. Missing Resources 4.7.2. Missing Resources
Configuration in <intended> can refer to resources that are not Configuration in <intended> can refer to resources that are not
available or otherwise not physically present. In these situations, available or otherwise not physically present. In these situations,
these parts of the <intended> configuration are not applied. The these parts of <intended> are not applied. The data appears in
data appears in <intended> but does not appear in <operational>. <intended> but does not appear in <operational>.
A typical example is an interface configuration that refers to an A typical example is an interface configuration that refers to an
interface that is not currently present. In such a situation, the interface that is not currently present. In such a situation, the
interface configuration remains in <intended> but the interface interface configuration remains in <intended> but the interface
configuration will not appear in <operational>. configuration will not appear in <operational>.
Note that configuration validity cannot depend on the current state Note that configuration validity cannot depend on the current state
of such resources, since that would imply the removing a resource of such resources, since that would imply the removing a resource
might render the configuration invalid. This is unacceptable, might render the configuration invalid. This is unacceptable,
especially given that rebooting such a device would fail to boot due especially given that rebooting such a device would fail to boot due
to an invalid configuration. Instead we allow configuration for to an invalid configuration. Instead we allow configuration for
missing resources to exist in <running> and <intended>, but it will missing resources to exist in <running> and <intended>, but it will
not appear in <operational>. not appear in <operational>.
4.7.2. System-controlled Resources 4.7.3. System-controlled Resources
Sometimes resources are controlled by the device and the Sometimes resources are controlled by the device and the
corresponding system controlled data appear in (and disappear from) corresponding system controlled data appear in (and disappear from)
<operational> dynamically. If a system controlled resource has <operational> dynamically. If a system controlled resource has
matching configuration in <intended> when it appears, the system will matching configuration in <intended> when it appears, the system will
try to apply the configuration, which causes the configuration to try to apply the configuration, which causes the configuration to
appear in <operational> eventually (if application of the appear in <operational> eventually (if application of the
configuration was successful). configuration was successful).
4.7.3. Origin Metadata Annotation 4.7.4. Origin Metadata Annotation
As data flows into <operational>, it is conceptually marked with a As configuration flows into <operational>, it is conceptually marked
metadata annotation ([RFC7952]) that indicates its origin. The with a metadata annotation ([RFC7952]) that indicates its origin.
origin applies to all data nodes except non-presence containers. The The origin applies to all configuration nodes except non-presence
"origin" metadata annotation is defined in Section 6. The values are containers. The "origin" metadata annotation is defined in
YANG identities. The following identities are defined: Section 6. The values are YANG identities. The following identities
are defined:
o origin: abstract base identity from which the other origin o origin: abstract base identity from which the other origin
identities are derived. identities are derived.
o intended: represents data provided by <intended>. o intended: represents configuration provided by <intended>.
o dynamic: represents data provided by a dynamic datastore. o dynamic: represents configuration provided by a dynamic
configuration datastore.
o system: represents data provided by the system itself, including o system: represents configuration provided by the system itself.
both system configuration and system state. Examples of system Examples of system configuration include applied configuration for
configuration include applied configuration for an always existing an always existing loopback interface, or interface configuration
loopback interface, or interface configuration that is auto- that is auto-created due to the hardware currently present in the
created due to the hardware currently present in the device. device.
o learned: represents configuration that has been learned via o learned: represents configuration that has been learned via
protocol interactions with other systems, including protocols such protocol interactions with other systems, including protocols such
as link-layer negotiations, routing protocols, DHCP, etc. as link-layer negotiations, routing protocols, DHCP, etc.
o default: represents data using a default value specified in the o default: represents configuration using a default value specified
data model, using either values in the "default" statement or any in the data model, using either values in the "default" statement
values described in the "description" statement. The default or any values described in the "description" statement. The
origin is only used when the data has not been provided by any default origin is only used when the configuration has not been
other source. provided by any other source.
o unknown: represents data for which the system cannot identify the o unknown: represents configuration for which the system cannot
origin. identify the origin.
These identities can be further refined, e.g., there could be These identities can be further refined, e.g., there could be
separate identities for particular types or instances of dynamic separate identities for particular types or instances of dynamic
datastore derived from "dynamic". configuration datastores derived from "dynamic".
In all cases, the device should report the origin that most For all configuration data nodes in <operational>, the device should
accurately reflects the source of the data that is actively being report the origin that most accurately reflects the source of the
used by the system. configuration that is actively being used by the system.
In cases where it could be ambiguous as to which origin should be In cases where it could be ambiguous as to which origin should be
used, i.e. where the same data node value has originated from used, i.e. where the same data node value has originated from
multiple sources, then the description statement in the YANG module multiple sources, then the description statement in the YANG module
should be used as guidance for choosing the appropriate origin. For should be used as guidance for choosing the appropriate origin. For
example: example:
If for a particular configuration node, the associated YANG If for a particular configuration node, the associated YANG
description statement indicates that a protocol negotiated value description statement indicates that a protocol negotiated value
overrides any configured value, then the origin would be reported as overrides any configured value, then the origin would be reported as
"learned", even when a learned value is the same as the configured "learned", even when a learned value is the same as the configured
value. value.
Conversely, if for a particular configuration node, the associated Conversely, if for a particular configuration node, the associated
YANG description statement indicates that a protocol negotiated value YANG description statement indicates that a protocol negotiated value
does not override an explicitly configured value, then the origin does not override an explicitly configured value, then the origin
would be reported as "intended" even when a learned value is the same would be reported as "intended" even when a learned value is the same
as the configured value. as the configured value.
In the case that a device cannot provide an accurate origin for a In the case that a device cannot provide an accurate origin for a
particular data node then it should use the origin "unknown". particular configuration data node then it should use the origin
"unknown".
5. Implications on YANG 5. Implications on YANG
5.1. XPath Context 5.1. XPath Context
If a server implements the architecture defined in this document, the If a server implements the architecture defined in this document, the
accessible trees for some XPath contexts are refined as follows: accessible trees for some XPath contexts are refined as follows:
o If the XPath expression is defined in a substatement to a data o If the XPath expression is defined in a substatement to a data
node that represents system state, the accessible tree is all node that represents system state, the accessible tree is all
skipping to change at page 15, line 29 skipping to change at page 16, line 10
"output" statement in an "rpc" or "action" statement, the "output" statement in an "rpc" or "action" statement, the
accessible tree is the RPC or action operation instance and all accessible tree is the RPC or action operation instance and all
operational state in the server. The root node has top-level data operational state in the server. The root node has top-level data
nodes in all modules as children. Additionally, for an RPC, the nodes in all modules as children. Additionally, for an RPC, the
root node also has the node representing the RPC operation being root node also has the node representing the RPC operation being
defined as a child. The node representing the operation being defined as a child. The node representing the operation being
defined has the operation's output parameters as children. defined has the operation's output parameters as children.
6. YANG Modules 6. YANG Modules
<CODE BEGINS> file "ietf-datastores@2017-04-26.yang" <CODE BEGINS> file "ietf-datastores@2017-08-17.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 NETMOD (NETCONF Data Modeling Language) Working Group"; "IETF Network Modeling (NETMOD) Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/netmod/> "WG Web: <https://datatracker.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org> WG List: <mailto:netmod@ietf.org>
Author: Martin Bjorklund Author: Martin Bjorklund
<mailto:mbj@tail-f.com> <mailto:mbj@tail-f.com>
Author: Juergen Schoenwaelder Author: Juergen Schoenwaelder
skipping to change at page 16, line 14 skipping to change at page 16, line 43
Author: Kent Watsen Author: Kent Watsen
<mailto:kwatsen@juniper.net> <mailto:kwatsen@juniper.net>
Author: Rob Wilton Author: Rob Wilton
<rwilton@cisco.com>"; <rwilton@cisco.com>";
description description
"This YANG module defines two sets of identities for datastores. "This YANG module defines two sets of identities for datastores.
The first identifies the datastores themselves, the second The first identifies the datastores themselves, the second
identifies are for datastore protperties. identifies datastore properties.
Copyright (c) 2017 IETF Trust and the persons identified as Copyright (c) 2017 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
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-04-26 { revision 2017-08-17 {
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 17, line 21 skipping to change at page 18, line 4
base conventional; base conventional;
description description
"The candidate configuration datastore."; "The candidate configuration datastore.";
} }
identity startup { identity startup {
base conventional; base conventional;
description description
"The startup configuration datastore."; "The startup configuration datastore.";
} }
identity intended { identity intended {
base conventional; base conventional;
description description
"The intended configuration datastore."; "The intended configuration datastore.";
} }
identity dynamic { identity dynamic {
base datastore; base datastore;
description description
"Abstract base identity for dynamic datastores."; "Abstract base identity for dynamic configuration datastores.";
} }
identity operational { identity operational {
base datastore; base datastore;
description description
"The operational state datastore."; "The operational state datastore.";
} }
identity property { /*
description * Type definitions
"Abstract base identity for datastore identities."; */
}
identity writable {
base property;
description
"Used on the 'running' datastore to indicate that it can be
written to.";
}
identity auto-persist {
base property;
description
"Used on the 'running' datastore to indicate that writes to
it will be automatically persisted.
If the 'startup' datastore is also supported, clients may
query its contents to ensure its synchronization.
If the 'startup' datastore is not supported, and this
property is not set, then clients must use a mechanism
provided by the protocol to explicitly persist the
'running' datastore's contents.";
}
identity rollback-on-error {
base property;
description
"Used on either the 'running' or 'candidate' datastores to
indicate that clients may request atomic update behavior.";
}
identity confirmed-commit {
base property;
description
"Used on the 'candidate' datastore to indicate that
clients may request confirmed-commit update behavior.";
}
identity validate { typedef datastore-ref {
base property; type identityref {
base datastore;
}
description description
"Used on the 'candidate' datastore to indicate that "A datastore identity reference.";
clients may request datastore validation.";
} }
} }
<CODE ENDS> <CODE ENDS>
<CODE BEGINS> file "ietf-origin@2017-04-26.yang" <CODE BEGINS> file "ietf-origin@2017-08-17.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;
} }
organization organization
"IETF NETMOD (NETCONF Data Modeling Language) Working Group"; "IETF Network Modeling (NETMOD) Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/wg/netmod/> "WG Web: <https://datatracker.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org> WG List: <mailto:netmod@ietf.org>
Author: Martin Bjorklund Author: Martin Bjorklund
<mailto:mbj@tail-f.com> <mailto:mbj@tail-f.com>
Author: Juergen Schoenwaelder Author: Juergen Schoenwaelder
skipping to change at page 19, line 51 skipping to change at page 19, line 43
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-04-26 { revision 2017-08-17 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: Network Management Datastore Architecture"; "RFC XXXX: Network Management Datastore Architecture";
} }
/* /*
* Identities * Identities
*/ */
identity origin { identity origin {
description description
"Abstract base identity for the origin annotation."; "Abstract base identity for the origin annotation.";
} }
identity intended { identity intended {
base origin; base origin;
description description
"Denotes data from the intended configuration datastore"; "Denotes configuration from the intended configuration
datastore";
} }
identity dynamic { identity dynamic {
base origin; base origin;
description description
"Denotes data from a dynamic datastore."; "Denotes configuration from a dynamic configuration
datastore.";
} }
identity system { identity system {
base origin; base origin;
description description
"Denotes data originated by the system itself, including "Denotes configuration originated by the system itself.
both system configuration and system state.
Examples of system configuration include applied configuration Examples of system configuration include applied configuration
for an always existing loopback interface, or interface for an always existing loopback interface, or interface
configuration that is auto-created due to the hardware configuration that is auto-created due to the hardware
currently present in the device."; currently present in the device.";
} }
identity learned { identity learned {
base origin; base origin;
description description
"Denotes configuration learned from protocol interactions with "Denotes configuration learned from protocol interactions with
other devices, instead of via the intended configuration other devices, instead of via either the intended
datastore or any dynamic datastore. configuration datastore or any dynamic configuration
datastore.
Examples of protocols that provide learned configuration Examples of protocols that provide learned configuration
include link-layer negotiations, routing protocols, and include link-layer negotiations, routing protocols, and
DHCP."; DHCP.";
} }
identity default { identity default {
base origin; base origin;
description description
"Denotes data that does not have an configured or learned "Denotes configuration that does not have an configured or
value, but has a default value in use. Covers both values learned value, but has a default value in use. Covers both
defined in a 'default' statement, and values defined via an values defined in a 'default' statement, and values defined
explanation in a 'description' statement."; via an explanation in a 'description' statement.";
} }
identity unknown { identity unknown {
base origin; base origin;
description description
"Denotes data for which the system cannot identify the "Denotes configuration for which the system cannot identify the
origin."; origin.";
} }
/* /*
* Metadata annotations * Type definitions
*/ */
md:annotation origin { typedef origin-ref {
type identityref { type identityref {
base origin; base origin;
} }
description description
"The 'origin' annotation can be present on any node in a "An origin identity reference.";
datastore. It specifies from where the node originated.";
} }
/*
* Metadata annotations
*/
md:annotation origin {
type origin-ref;
description
"The 'origin' annotation can be present on any configuration
data node in the operational datastore. It specifies from
where the node originated. If not specified for a given
configuration data node then the origin is the same as the
origin of its parent node in the data tree. The origin for
any top level configuration data nodes must be specified.";
}
} }
<CODE ENDS> <CODE ENDS>
7. IANA Considerations 7. IANA Considerations
7.1. Updates to the IETF XML Registry 7.1. Updates to the IETF XML Registry
This document registers two URIs in the IETF XML registry [RFC3688]. This document registers two URIs in the IETF XML registry [RFC3688].
Following the format in [RFC3688], the following registrations are Following the format in [RFC3688], the following registrations are
skipping to change at page 22, line 35 skipping to change at page 22, line 35
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
8. Security Considerations 8. Security Considerations
This document discusses an architectural model of datastores for This document discusses an architectural model of datastores for
network management using NETCONF/RESTCONF and YANG. It has no network management using NETCONF/RESTCONF and YANG. It has no
security impact on the Internet. security impact on the Internet.
Although this document specifies several YANG modules, these modules
only define identities and meta-data, hence the "YANG module security
guidelines" do not apply.
9. Acknowledgments 9. Acknowledgments
This document grew out of many discussions that took place since This document grew out of many discussions that took place since
2010. Several Internet-Drafts ([I-D.bjorklund-netmod-operational], 2010. Several Internet-Drafts ([I-D.bjorklund-netmod-operational],
[I-D.wilton-netmod-opstate-yang], [I-D.ietf-netmod-opstate-reqs], [I-D.wilton-netmod-opstate-yang], [I-D.ietf-netmod-opstate-reqs],
[I-D.kwatsen-netmod-opstate], [I-D.openconfig-netmod-opstate]) and [I-D.kwatsen-netmod-opstate], [I-D.openconfig-netmod-opstate]) and
[RFC6244] touched on some of the problems of the original datastore [RFC6244] touched on some of the problems of the original datastore
model. The following people were authors to these Internet-Drafts or model. The following people were authors to these Internet-Drafts or
otherwise actively involved in the discussions that led to this otherwise actively involved in the discussions that led to this
document: document:
skipping to change at page 25, line 11 skipping to change at page 25, line 13
desirable that a subset of all modules can be targeted to the desirable that a subset of all modules can be targeted to the
datastore, then the documentation defining the datastore must datastore, then the documentation defining the datastore must
indicate this. indicate this.
A.2. Define which subset of YANG-modeled data applies A.2. Define which subset of YANG-modeled data applies
By default, the data in a datastore is modeled by all YANG statements By default, the data in a datastore is modeled by all YANG statements
in the available YANG modules. However, it is possible to specify in the available YANG modules. However, it is possible to specify
criteria that YANG statements must satisfy in order to be present in criteria that YANG statements must satisfy in order to be present in
a datastore. For instance, maybe only "config true" nodes are a datastore. For instance, maybe only "config true" nodes are
present, or "config false nodes" that also have a specific YANG present, or "config false" nodes that also have a specific YANG
extension (e.g., "i2rs:ephemeral true") are present in the datastore. extension are present in the datastore.
A.3. Define how data is actualized A.3. Define how data is actualized
The new datastore must specify how it interacts with other The new datastore must specify how it interacts with other
datastores. For example, the diagram in Section 4 depicts dynamic datastores.
For example, the diagram in Section 4 depicts dynamic configuration
datastores feeding into <operational>. How this interaction occurs datastores feeding into <operational>. How this interaction occurs
must be defined by any dynamic datastore. In some cases, it may must be defined by the particular dynamic configuration datastores.
occur implicitly, as soon as the data is put into the dynamic In some cases, it may occur implicitly, as soon as the data is put
datastore while, in other cases, an explicit action (e.g., an RPC) into the dynamic configuration datastore while, in other cases, an
may be required to trigger the application of the datastore's data. explicit action (e.g., an RPC) may be required to trigger the
application of the datastore's data.
A.4. Define which protocols can be used A.4. Define which protocols can be used
By default, it is assumed that both the NETCONF and RESTCONF By default, it is assumed that both the NETCONF and RESTCONF
protocols can be used to interact with a datastore. However, it may protocols can be used to interact with a datastore. However, it may
be that only a specific protocol can be used (e.g., ForCES) or that a be that only a specific protocol can be used (e.g., ForCES) or that a
subset of all protocol operations or capabilities are available subset of all protocol operations or capabilities are available
(e.g., no locking or no XPath-based filtering). (e.g., no locking or no XPath-based filtering).
A.5. Define YANG identities for the datastore A.5. Define YANG identities for the datastore
skipping to change at page 25, line 47 skipping to change at page 26, line 5
protocol operations (e.g., <get-data>). protocol operations (e.g., <get-data>).
The datastore may also be defined with an identity that uses the The datastore may also be defined with an identity that uses the
"or:origin" identity or one its derived identities as its base. This "or:origin" identity or one its derived identities as its base. This
identity is needed if the datastore interacts with <operational> so identity is needed if the datastore interacts with <operational> so
that data originating from the datastore can be identified as such that data originating from the datastore can be identified as such
via the "origin" metadata attribute defined in Section 6. via the "origin" metadata attribute defined in Section 6.
An example of these guidelines in use is provided in Appendix B. An example of these guidelines in use is provided in Appendix B.
Appendix B. Ephemeral Dynamic Datastore Example Appendix B. Ephemeral Dynamic Configuration Datastore Example
The section defines documentation for an example dynamic datastore The section defines documentation for an example dynamic
using the guidelines provided in Appendix A. While this example is configuration datastore using the guidelines provided in Appendix A.
very terse, it is expected to be that a standalone RFC would be While this example is very terse, it is expected to be that a
needed when fully expanded. standalone RFC would be needed when fully expanded.
This example defines a dynamic datastore called "ephemeral", which is This example defines a dynamic configuration datastore called
loosely modeled after the work done in the I2RS working group. "ephemeral", which is loosely modeled after the work done in the I2RS
working group.
1. Name : ephemeral 1. Name : ephemeral
2. YANG modules : all (default) 2. YANG modules : all (default)
3. YANG statements : config false + ephemeral true 3. YANG data nodes : all "config true" data nodes
4. How applied : automatic 4. How applied : automatic
5. Protocols : NC/RC (default) 5. Protocols : NC/RC (default)
6. YANG Module : (see below) 6. YANG Module : (see below)
module example-ds-ephemeral { module example-ds-ephemeral {
yang-version 1.1; yang-version 1.1;
namespace "urn:example:ds-ephemeral"; namespace "urn:example:ds-ephemeral";
prefix eph; prefix eph;
import ietf-datastores { import ietf-datastores {
prefix ds; prefix ds;
} }
import ietf-origin { import ietf-origin {
prefix or; prefix or;
} }
// add datastore identity // datastore identity
identity ds-ephemeral { identity ds-ephemeral {
base ds:datastore; base ds:dynamic;
description description
"The 'ephemeral' datastore."; "The ephemeral dynamic configuration datastore.";
} }
// add origin identity // origin identity
identity or-ephemeral { identity or-ephemeral {
base or:dynamic; base or:dynamic;
description description
"Denotes data from the ephemeral dynamic datastore."; "Denotes data from the ephemeral dynamic configuration
} datastore.";
// define ephemeral extension
extension ephemeral {
argument "value";
description
"This extension is mixed into config false YANG nodes to
indicate that they are writable nodes in the 'ephemeral'
datastore. This statement takes a single argument
representing a boolean having the values 'true' and
'false'. The default value is 'false'.";
} }
} }
Appendix C. Example Data Appendix C. Example Data
The use of datastores is complex, and many of the subtle effects are The use of datastores is complex, and many of the subtle effects are
more easily presented using examples. This section presents a series more easily presented using examples. This section presents a series
of example data models with some sample contents of the various of example data models with some sample contents of the various
datastores. datastores.
skipping to change at page 29, line 10 skipping to change at page 29, line 10
</address> </address>
</interface> </interface>
</system> </system>
The system has detected that the hardware for one of the configured The system has detected that the hardware for one of the configured
interfaces ("eth1") is not yet present, so the configuration for that interfaces ("eth1") is not yet present, so the configuration for that
interface is not applied. Further, the system has received a host interface is not applied. Further, the system has received a host
name and an additional IP address for "eth0" over DHCP. In addition name and an additional IP address for "eth0" over DHCP. In addition
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>: this is reflected in <operational>. Note how the origin metadata
attribute for several "config true" data nodes is inherited from
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:dynamic">bar</hostname>
<interface or:origin="or:intended"> <interface or:origin="or:intended">
<name>eth0</name> <name>eth0</name>
<auto-negotiation> <auto-negotiation>
skipping to change at page 29, line 47 skipping to change at page 29, line 49
<address> <address>
<ip>::1</ip> <ip>::1</ip>
<prefix-length>128</prefix-length> <prefix-length>128</prefix-length>
</address> </address>
</interface> </interface>
</system> </system>
C.2. BGP Example C.2. BGP Example
Consider the following piece of a ersatz BGP module: Consider the following fragment of a fictional BGP module:
container bgp { container bgp {
leaf local-as { leaf local-as {
type uint32; type uint32;
} }
leaf peer-as { leaf peer-as {
type uint32; type uint32;
} }
list peer { list peer {
key name; key name;
skipping to change at page 30, line 51 skipping to change at page 30, line 51
} }
} }
} }
In this example model, both bgp/peer/local-as and bgp/peer/peer-as In this example model, both bgp/peer/local-as and bgp/peer/peer-as
have complex hierarchical values, allowing the user to specify have complex hierarchical values, allowing the user to specify
default values for all peers in a single location. default values for all peers in a single location.
The model also follows the pattern of fully integrating state The model also follows the pattern of fully integrating state
("config false") nodes with configuration ("config true") nodes. ("config false") nodes with configuration ("config true") nodes.
There is not separate "bgp-state" hierarchy, with the accompanying There is no separate "bgp-state" hierarchy, with the accompanying
repetition of containment and naming nodes. This makes the model repetition of containment and naming nodes. This makes the model
simpler and more readable. simpler and more readable.
C.2.1. Datastores C.2.1. Datastores
Each datastore represents differing views of these nodes. <running> Each datastore represents differing views of these nodes. <running>
will hold the configuration provided by the user, for example a will hold the configuration provided by the operator, for example a
single BGP peer. <intended> will conceptually hold the data as single BGP peer. <intended> will conceptually hold the data as
validated, after the removal of data not intended for validation and validated, after the removal of data not intended for validation and
after any local template mechanisms are performed. <operational> after any local template mechanisms are performed. <operational> will
will show data from <intended> as well as any "config false" nodes. show data from <intended> as well as any "config false" nodes.
C.2.2. Adding a Peer C.2.2. Adding a Peer
If the user configures a single BGP peer, then that peer will be If the user configures a single BGP peer, then that peer will be
visible in both <running> and <intended>. It may also appear in visible in both <running> and <intended>. It may also appear in
<candidate>, if the server supports the "candidate" feature. <candidate>, if the server supports the candidate configuration
Retrieving the peer will return only the user-specified values. datastore. Retrieving the peer will return only the user-specified
values.
No time delay should exist between the appearance of the peer in No time delay should exist between the appearance of the peer in
<running> and <intended>. <running> and <intended>.
In this scenario, we've added the following to <running>: In this scenario, we've added the following to <running>:
<bgp> <bgp>
<local-as>64642</local-as> <local-as>64501</local-as>
<peer-as>65000</peer-as> <peer-as>64502</peer-as>
<peer> <peer>
<name>10.1.2.3</name> <name>10.1.2.3</name>
</peer> </peer>
</bgp> </bgp>
C.2.2.1. <operational> C.2.2.1. <operational>
<operational> will contain the fully expanded peer data, including The operational datastore will contain the fully expanded peer data,
"config false" nodes. In our example, this means the "state" node including "config false" nodes. In our example, this means the
will appear. "state" node will appear.
In addition, <operational> will contain the "currently in use" values In addition, <operational> will contain the "currently in use" values
for all nodes. This means that local-as and peer-as will be for all nodes. This means that local-as and peer-as will be
populated even if they are not given values in <intended>. The value populated even if they are not given values in <intended>. The value
of bgp/local-as will be used if bgp/peer/local-as is not provided; of bgp/local-as will be used if bgp/peer/local-as is not provided;
bgp/peer-as and bgp/peer/peer-as will have the same relationship. In bgp/peer-as and bgp/peer/peer-as will have the same relationship. In
the operational view, this means that every peer will have values for the operational view, this means that every peer will have values for
their local-as and peer-as, even if those values are not explicitly their local-as and peer-as, even if those values are not explicitly
configured but are provided by bgp/local-as and bgp/peer-as. configured but are provided by bgp/local-as and bgp/peer-as.
Each BGP peer has a TCP connection associated with it, using the Each BGP peer has a TCP connection associated with it, using the
values of local-port and remote-port from <intended>. If those values of local-port and remote-port from <intended>. If those
values are not supplied, the system will select values. When the values are not supplied, the system will select values. When the
connection is established, <operational> will contain the current connection is established, <operational> will contain the current
values for the local-port and remote-port nodes regardless of the values for the local-port and remote-port nodes regardless of the
origin. If the system has chosen the values, the "origin" attribute origin. If the system has chosen the values, the "origin" attribute
will be set to "system". Before the connection is established, one will be set to "system". Before the connection is established, one
or both of the nodes may not appear, since the system may not yet or both of the nodes may not appear, since the system may not yet
have their values. have their values.
<bgp origin="or:intended" xmlns="urn:example:bgp"> <bgp or:origin="or:intended">
<local-as origin="or:intended">64642</local-as> <local-as>64501</local-as>
<peer-as origin="or:intended">65000</peer-as> <peer-as>64502</peer-as>
<peer origin="or:intended"> <peer>
<name origin="or:intended">10.1.2.3</name> <name>10.1.2.3</name>
<local-as origin="or:default">64642</local-as> <local-as or:origin="or:default">64501</local-as>
<peer-as origin="or:default">65000</peer-as> <peer-as or:origin="or:default">64502</peer-as>
<local-port origin="or:system">60794</local-port> <local-port or:origin="or:system">60794</local-port>
<remote-port origin="or:default">179</remote-port> <remote-port or:origin="or:default">179</remote-port>
<state>established</state>
</peer> </peer>
</bgp> </bgp>
C.2.3. Removing a Peer C.2.3. Removing a Peer
Changes to configuration may take time to percolate through the Changes to configuration may take time to percolate through the
various software components involved. During this period, it is various software components involved. During this period, it is
imperative to continue to give an accurate view of the working of the imperative to continue to give an accurate view of the working of the
device. <operational> will contain nodes for both the previous and device. <operational> will contain nodes for both the previous and
current configuration, as closely as possible tracking the current current configuration, as closely as possible tracking the current
operation of the device. operation of the device.
Consider the scenario where a client removes a BGP peer. When a peer Consider the scenario where a client removes a BGP peer. When a peer
is removed, the operational state will continue to reflect the is removed, the operational state will continue to reflect the
existence of that peer until the peer's resources are released, existence of that peer until the peer's resources are released,
including closing the peer's connection. During this period, the including closing the peer's connection. During this period, the
current data values will continue to be visible in <operational>, current data values will continue to be visible in <operational>,
with the "origin" attribute set to indicate the origin of the with the "origin" attribute set to indicate the origin of the
original data. original data.
<bgp origin="or:intended"> <bgp or:origin="or:intended">
<local-as origin="or:intended">64642</local-as> <local-as>64501</local-as>
<peer-as origin="or:intended">65000</peer-as> <peer-as>64502</peer-as>
<peer origin="or:intended"> <peer>
<name origin="or:intended">10.1.2.3</name> <name>10.1.2.3</name>
<local-as origin="or:default">64642</local-as> <local-as or:origin="or:default">64501</local-as>
<peer-as origin="or:default">65000</peer-as> <peer-as or:origin="or:default">64502</peer-as>
<local-port origin="or:system">60794</local-port> <local-port or:origin="or:system">60794</local-port>
<remote-port origin="or:default">179</remote-port> <remote-port or:origin="or:default">179</remote-port>
<state>closing</state>
</peer> </peer>
</bgp> </bgp>
Once resources are released and the connection is closed, the peer's Once resources are released and the connection is closed, the peer's
data is removed from <operational>. data is removed from <operational>.
C.3. Interface Example C.3. Interface Example
In this section, we'll use this simple interface data model: In this section, we will use this simple interface data model:
container interfaces { container interfaces {
list interface { list interface {
key name; key name;
leaf name { leaf name {
type string; type string;
} }
leaf description { leaf description {
type string; type string;
} }
leaf mtu { leaf mtu {
type uint; type uint16;
} }
leaf ipv4-address { leaf-list ip-address {
type inet:ipv4-address; type inet:ip-address;
} }
} }
} }
C.3.1. Pre-provisioned Interfaces C.3.1. Pre-provisioned Interfaces
One common issue in networking devices is the support of Field One common issue in networking devices is the support of Field
Replaceable Units (FRUs) that can be inserted and removed from the Replaceable Units (FRUs) that can be inserted and removed from the
device without requiring a reboot or interfering with normal device without requiring a reboot or interfering with normal
operation. These FRUs are typically interface cards, and the devices operation. These FRUs are typically interface cards, and the devices
skipping to change at page 34, line 16 skipping to change at page 34, line 20
<interface> <interface>
<name>et-0/0/0</name> <name>et-0/0/0</name>
<description>Test interface</description> <description>Test interface</description>
</interface> </interface>
</interfaces> </interfaces>
Since the interface does not exist, this data does not appear in Since the interface does not exist, this data does not appear in
<operational>. <operational>.
When a FRU containing this interface is inserted, the system will When a FRU containing this interface is inserted, the system will
detect it and process the associated configuration. The detect it and process the associated configuration. <operational>
<operational> will contain the data from <intended>, as well as the will contain the data from <intended>, as well as nodes added by the
"config false" nodes, such as the current value of the interface's system, such as the current value of the interface's MTU.
MTU.
<interfaces origin="or:intended"> <interfaces or:origin="or:intended">
<interface origin="or:intended"> <interface>
<name origin="or:intended">et-0/0/0</name> <name>et-0/0/0</name>
<description origin="or:intended">Test interface</description> <description>Test interface</description>
<mtu origin="or:system">1500</mtu> <mtu or:origin="or:system">1500</mtu>
</interface> </interface>
</interfaces> </interfaces>
If the FRU is removed, the interface data is removed from If the FRU is removed, the interface data is removed from
<operational>. <operational>.
C.3.2. System-provided Interface C.3.2. System-provided Interface
Imagine if the system provides a loopback interface (named "lo0") Imagine if the system provides a loopback interface (named "lo0")
with a default ipv4-address of "127.0.0.1". The system will only with a default ip-address of "127.0.0.1" and a default ip-address of
provide configuration for this interface if there is no data for it "::1". The system will only provide configuration for this interface
in <intended>. if there is no data for it in <intended>.
When no configuration for "lo0" appears in <intended>, then When no configuration for "lo0" appears in <intended>, then
<operational> will show the system-provided data: <operational> will show the system-provided data:
<interfaces origin="or:intended"> <interfaces or:origin="or:intended">
<interface origin="or:system"> <interface or:origin="or:system">
<name origin="or:system">lo0</name> <name>lo0</name>
<ipv4-address origin="or:system">127.0.0.1</ipv4-address> <ip-address>127.0.0.1</ip-address>
<ip-address>::1</ip-address>
</interface> </interface>
</interfaces> </interfaces>
When configuration for "lo0" does appear in <intended>, then When configuration for "lo0" does appear in <intended>, then
<operational> will show that data with the origin set to "intended". <operational> will show that data with the origin set to "intended".
If the "ipv4-address" is not provided, then the system-provided value If the "ip-address" is not provided, then the system-provided value
will appear as follows: will appear as follows:
<interfaces origin="or:intended"> <interfaces or:origin="or:intended">
<interface origin="or:intended"> <interface>
<name origin="or:intended">lo0</name> <name>lo0</name>
<description origin="or:intended">loopback</description> <description>loopback</description>
<ipv4-address origin="or:system">127.0.0.1</ipv4-address> <ip-address or:origin="or:system">127.0.0.1</ip-address>
<ip-address>::1</ip-address>
</interface> </interface>
</interfaces> </interfaces>
Authors' Addresses Authors' Addresses
Martin Bjorklund Martin Bjorklund
Tail-f Systems Tail-f Systems
Email: mbj@tail-f.com Email: mbj@tail-f.com
 End of changes. 87 change blocks. 
230 lines changed or deleted 247 lines changed or added

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