NETCONF Model for NMDATail-f Systemsmbj@tail-f.comJacobs Universityj.schoenwaelder@jacobs-university.deJuniper Networksphil@juniper.netJuniper Networkskwatsen@juniper.netCisco Systemsrwilton@cisco.com
The "Network Management Datastore Architecture" (NMDA) improves on
NETCONF by adding new features to give more accurate handling of
configuration and operational data. These include ability to inspect
the current operational values of configuration data, allowing clients
to use identical paths for retrieving the configured values and the
operational values. These new features require additional operations
in network management applications such as NETCONF. This draft
details those new operations.
This document provides a YANG model that adds NETCONF ()
support for the "Network Management Datastore Architecture"
(NMDA) . NMDA defines a framework
for datastores, a fundamental concept binding network management data
models to network management protocols, enabling data models to be
written in a network management protocol agnostic way. NETCONF
operations currently refer to the datastores defined in the original
model, so new operations are required to allow references to the new
datastores.
Operations like <copy‑config>, <lock> and <unlock> are augmented to
allow them to target additional datastores.
In addition the original <get> operation is deprecated, since the
information it returns is no longer needed. <get>'s deficiencies were
a major motivation for the NMDA.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14, when, and only when, they appear in all capitals,
as shown here..
This document uses the terminology defined by the NMDA
.
This section describes the changes needed for NMDA support. These
changes are contained in a new YANG () model
"ietf‑netconf‑datastores".
These changes include the use of source and target parameters based on
the "datastore" identity defined in the "ietf‑datastores" from
. The use of identities allows
future expansion in a way that the choice-based strategy from the
original operations (e.g. <get‑config>, <edit‑config>) do not.
Support for the NMDA includes two new operations defined in this
document.
The <get‑data> operation retrieves data from a specific NMDA
datastore. This operation is similar to NETCONF's "get‑config"
operation, but adds flexibility in naming the target datastore.
The "source" parameter indicates the datastore which is the source of
the data to be retrieved. This is a datastore identity.
The <get‑data> operation accepts a content filter parameter, similar
to the "filter" parameter of "get‑config", but using explicit nodes
for subtree filtering and XPath filtering.
Additional filters are defined to retrieve only "config true" nodes or
nodes matching a given "origin" value.
The "get‑data" operation also supports the "with‑defaults" parameter
as defined in . The supported values follow the constraints
given by the "with‑defaults" capability.
The "get‑data" operation adds a new boolean parameter named
"with‑origin", which requests that the server returns the "origin"
information as detailed in the NMDA. This parameter is only valid for
<operational> and any datastores with identities derived from the
"operational" identity.
Data from <operational> can come from multiple sources. The server
should return the most accurate value for the "origin" attribute as
possible, indicating the source of the operational value.
When encoding the origin attribute for a hierarchy of returned nodes,
the origin attribute may be omitted when the value matches that of the
parent node.
The <edit‑data> operation changes the contents of a specific
datastore, similar to the <edit‑config> operation, but with additional
flexibility in naming the target datastore.
The "target" parameter is a datastore identity that indicates the
desired target datastore where changes should be made.
The "edit‑content" parameter from "edit‑config" it is modified to
allow use "type anydata" for configuration content, rather than the
"edit‑config"'s use of "type anyxml".
The "default‑operation" parameter mirrors the parameter of the
"edit‑config" operation.
Several of the operations defined in the base NETCONF data model
(ietf-netconf@2011-06-01.yang) will continue to be used under the
NMDA. The <lock>, <unlock>, and <validate> operations are
augmented with a new "datastore" leaf can indicate a desired
NMDA datastore.
Only writable datastores can be locked.
RPC operations and actions can be defined in YANG modules. The
evaluation context for constraints and references in operation and
actions is <operational>.
RFC Ed.: Update 201X-XX-XX below with correct date.
Support for NMDA requires the server to implement at least revision
201X-XX-XX of the "ietf‑yang‑library" module defined in
. The server MUST advertise the
following capability in the <hello> message (line breaks and
whitespaces are used for formatting reasons only):
The parameter "revision" has the same value as the revision date of
the "ietf‑yang‑library" module implemented by the server. This
parameter MUST be present.
The parameter "checksum" has the same value as the leaf
"/yang‑library/checksum" from "ietf‑yang‑library". This
parameter MUST be present.
With this mechanism, a client can cache the supported modules for a
server and only update the cache if the "checksum" value in the
<hello> message changes.
This document updates , section 5.6.4, to allow servers to
advertise the capability :yang-library:1.1 instead of
:yang-library:1.0, and to implement the subtree "/yang‑library"
instead of "/modules‑state".
<CODE BEGINS> file "ietf-netconf-datastores@2017-08-24.yang"<CODE ENDS>
This document registers one capability identifier URN from the
"Network Configuration Protocol (NETCONF) Capability URNs" registry:
This document registers a URI in the "IETF XML Registry" [RFC3688].
Following the format in RFC 3688, the following registration has been
made.
This document registers a YANG module in the "YANG Module Names"
registry [RFC6020].
This document has no security considerations.
Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Network Configuration Protocol (NETCONF)The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]With-defaults Capability for NETCONFThe Network Configuration Protocol (NETCONF) defines ways to read and edit configuration data from a NETCONF server. In some cases, part of this data may not be set by the NETCONF client, but rather a default value known to the server is used instead. In many situations the NETCONF client has a priori knowledge about default data, so the NETCONF server does not need to save it in a NETCONF configuration datastore or send it to the client in a retrieval operation reply. In other situations the NETCONF client will need this data from the server. Not all server implementations treat this default data the same way. This document defines a capability-based extension to the NETCONF protocol that allows the NETCONF client to identify how defaults are processed by the server, and also defines new mechanisms for client control of server processing of default data. [STANDARDS-TRACK]The YANG 1.1 Data Modeling LanguageYANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Network Management Datastore ArchitectureDatastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as NETCONF and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model.YANG LibraryThis document describes a YANG library that provides information about all the YANG modules used by a network management server (e.g., a Network Configuration Protocol (NETCONF) server). Simple caching mechanisms are provided to allow clients to minimize retrieval of this information.