draft-ietf-netmod-arch-10.txt   rfc6244.txt 
Network Working Group P. Shafer Internet Engineering Task Force (IETF) P. Shafer
Internet-Draft Juniper Networks Request for Comments: 6244 Juniper Networks
Intended status: Informational September 23, 2010 Category: Informational June 2011
Expires: March 27, 2011 ISSN: 2070-1721
An Architecture for Network Management using NETCONF and YANG An Architecture for Network Management Using NETCONF and YANG
draft-ietf-netmod-arch-10
Abstract Abstract
The Network Configuration Protocol (NETCONF) gives access to native The Network Configuration Protocol (NETCONF) gives access to native
capabilities of the devices within a network, defining methods for capabilities of the devices within a network, defining methods for
manipulating configuration databases, retrieving operational data, manipulating configuration databases, retrieving operational data,
and invoking specific operations. YANG provides the means to define and invoking specific operations. YANG provides the means to define
the content carried via NETCONF, both data and operations. Using the content carried via NETCONF, both data and operations. Using
both technologies, standard modules can be defined to give both technologies, standard modules can be defined to give
interoperability and commonality to devices, while still allowing interoperability and commonality to devices, while still allowing
devices to express their unique capabilities. devices to express their unique capabilities.
This document describes how NETCONF and YANG help build network This document describes how NETCONF and YANG help build network
management applications that meet the needs of network operators. management applications that meet the needs of network operators.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on March 27, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6244.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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
skipping to change at page 3, line 8 skipping to change at page 3, line 8
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Origins of NETCONF and YANG . . . . . . . . . . . . . . . . . 4 1. Origins of NETCONF and YANG . . . . . . . . . . . . . . . . . 4
2. Elements of the Architecture . . . . . . . . . . . . . . . . . 6 2. Elements of the Architecture . . . . . . . . . . . . . . . . . 5
2.1. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. NETCONF Transport Mappings . . . . . . . . . . . . . . 8 2.1.1. NETCONF Transport Mappings . . . . . . . . . . . . . . 7
2.2. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Constraints . . . . . . . . . . . . . . . . . . . . . 11 2.2.1. Constraints . . . . . . . . . . . . . . . . . . . . . 10
2.2.2. Flexibility . . . . . . . . . . . . . . . . . . . . . 12 2.2.2. Flexibility . . . . . . . . . . . . . . . . . . . . . 11
2.2.3. Extensibility Model . . . . . . . . . . . . . . . . . 12 2.2.3. Extensibility Model . . . . . . . . . . . . . . . . . 12
2.3. YANG Translations . . . . . . . . . . . . . . . . . . . . 13 2.3. YANG Translations . . . . . . . . . . . . . . . . . . . . 13
2.3.1. YIN . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.1. YIN . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2. DSDL (RELAX NG) . . . . . . . . . . . . . . . . . . . 14 2.3.2. DSDL (RELAX NG) . . . . . . . . . . . . . . . . . . . 14
2.4. YANG Types . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4. YANG Types . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5. IETF Guidelines . . . . . . . . . . . . . . . . . . . . . 15 2.5. IETF Guidelines . . . . . . . . . . . . . . . . . . . . . 14
3. Working with YANG . . . . . . . . . . . . . . . . . . . . . . 16 3. Working with YANG . . . . . . . . . . . . . . . . . . . . . . 14
3.1. Building NETCONF- and YANG-based Solutions . . . . . . . . 16 3.1. Building NETCONF- and YANG-Based Solutions . . . . . . . . 14
3.2. Addressing Operator Requirements . . . . . . . . . . . . . 17 3.2. Addressing Operator Requirements . . . . . . . . . . . . . 16
3.3. Roles in Building Solutions . . . . . . . . . . . . . . . 20 3.3. Roles in Building Solutions . . . . . . . . . . . . . . . 18
3.3.1. Modeler . . . . . . . . . . . . . . . . . . . . . . . 20 3.3.1. Modeler . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.2. Reviewer . . . . . . . . . . . . . . . . . . . . . . . 20 3.3.2. Reviewer . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.3. Device Developer . . . . . . . . . . . . . . . . . . . 20 3.3.3. Device Developer . . . . . . . . . . . . . . . . . . . 19
3.3.4. Application Developer . . . . . . . . . . . . . . . . 21 3.3.4. Application Developer . . . . . . . . . . . . . . . . 20
4. Modeling Considerations . . . . . . . . . . . . . . . . . . . 24 4. Modeling Considerations . . . . . . . . . . . . . . . . . . . 22
4.1. Default Values . . . . . . . . . . . . . . . . . . . . . . 24 4.1. Default Values . . . . . . . . . . . . . . . . . . . . . . 22
4.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . . 25 4.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3. Data Distinctions . . . . . . . . . . . . . . . . . . . . 26 4.3. Data Distinctions . . . . . . . . . . . . . . . . . . . . 24
4.3.1. Background . . . . . . . . . . . . . . . . . . . . . . 26 4.3.1. Background . . . . . . . . . . . . . . . . . . . . . . 24
4.3.2. Definitions . . . . . . . . . . . . . . . . . . . . . 27 4.3.2. Definitions . . . . . . . . . . . . . . . . . . . . . 25
4.3.3. Implications . . . . . . . . . . . . . . . . . . . . . 28 4.3.3. Implications . . . . . . . . . . . . . . . . . . . . . 27
4.4. Direction . . . . . . . . . . . . . . . . . . . . . . . . 29 4.4. Direction . . . . . . . . . . . . . . . . . . . . . . . . 27
5. Security Considerations . . . . . . . . . . . . . . . . . . . 30 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7. Normative References . . . . . . . . . . . . . . . . . . . . . 32 6.1. Normative References . . . . . . . . . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34 6.2. Informative References . . . . . . . . . . . . . . . . . . 29
1. Origins of NETCONF and YANG 1. Origins of NETCONF and YANG
Networks are increasing in complexity and capacity, as well as the Networks are increasing in complexity and capacity, as well as the
density of the services deployed upon them. Uptime, reliability, and density of the services deployed upon them. Uptime, reliability, and
predictable latency requirements drive the need for automation. The predictable latency requirements drive the need for automation. The
problems with network management are not simple. They are complex problems with network management are not simple. They are complex
and intricate. But these problems must be solved for networks to and intricate. But these problems must be solved for networks to
meet the stability needs of existing services while incorporating new meet the stability needs of existing services while incorporating new
services in a world where the growth of networks is exhausting the services in a world where the growth of networks is exhausting the
supply of qualified networking engineers. supply of qualified networking engineers.
In June of 2002, Internet Architecture Board (IAB) held a workshop on In June of 2002, the Internet Architecture Board (IAB) held a
Network Management ([RFC3535]). The members of this workshop made a workshop on Network Management [RFC3535]. The members of this
number of observations and recommendations for the IETF's workshop made a number of observations and recommendations for the
consideration concerning the issues operators were facing in their IETF's consideration concerning the issues operators were facing in
network management-related work as well as issues they were having their network management-related work as well as issues they were
with the direction of the IETF activities in this area. having with the direction of the IETF activities in this area.
The output of this workshop was focused on current problems. The The output of this workshop was focused on current problems. The
observations were reasonable and straight forward, including the need observations were reasonable and straightforward, including the need
for transactions, rollback, low implementation costs, and the ability for transactions, rollback, low implementation costs, and the ability
to save and restore the device's configuration data. Many of the to save and restore the device's configuration data. Many of the
observations give insight into the problems operators were having observations give insight into the problems operators were having
with existing network management solutions, such as the lack of full with existing network management solutions, such as the lack of full
coverage of device capabilities and the ability to distinguish coverage of device capabilities and the ability to distinguish
between configuration data and other types of data. between configuration data and other types of data.
Based on these directions, the NETCONF working group was formed and Based on these directions, the NETCONF working group was formed and
the Network Configuration (NETCONF) protocol was created. This the Network Configuration (NETCONF) protocol was created. This
protocol defines a simple mechanism where network management protocol defines a simple mechanism where network management
applications, acting as clients, can invoke operations on the applications, acting as clients, can invoke operations on the
devices, which act as servers. The NETCONF specification ([RFC4741]) devices, which act as servers. The NETCONF specification [RFC4741]
defines a small set of operations, but goes out of its way to avoid defines a small set of operations, but goes out of its way to avoid
making any requirements on the data carried in those operations, making any requirements on the data carried in those operations,
preferring to allow the protocol to carry any data. This "data model preferring to allow the protocol to carry any data. This "data model
agnostic" approach allows data models to be defined independently. agnostic" approach allows data models to be defined independently.
But lacking a means of defining data models, the NETCONF protocol was But lacking a means of defining data models, the NETCONF protocol was
not usable for standards-based work. Existing data modeling not usable for standards-based work. Existing data modeling
languages such as the XML Schema Language (XSD) ([W3CXSD]) and the languages such as the XML Schema Definition (XSD) [W3CXSD] and the
Document Schema Definition Languages (DSDL) ([ISODSDL]) were Document Schema Definition Languages (DSDL) [ISODSDL] were
considered, but were rejected because the problem domains have little considered, but were rejected because of the problem that domains
natural overlap. Defining a data model or protocol that is encoded have little natural overlap. Defining a data model or protocol that
in XML is a distinct problem from defining an XML document. The use is encoded in XML is a distinct problem from defining an XML
of NETCONF operations place requirements on the data content that are document. The use of NETCONF operations places requirements on the
not shared with the static document problem domain addressed by data content that are not shared with the static document problem
schema languages like XSD or RELAX NG. domain addressed by schema languages like XSD or RELAX NG.
In 2007 and 2008, the issue of a data modeling language for NETCONF In 2007 and 2008, the issue of a data modeling language for NETCONF
was discussed in the OPS and APPS areas of IETF 70 and 71, and a was discussed in the OPS and APP areas of IETF 70 and 71, and a
design team was tasked with creating a requirements document (expired design team was tasked with creating a requirements document [RCDML].
I-D draft-presuhn-rcdml-03.txt). After discussing the available After discussing the available options at the CANMOD BoF at IETF 71,
options at the CANMOD BoF at IETF71, the community wrote a charter the community wrote a charter for the NETMOD working group. An
for the NETMOD working group. An excellent description of this time excellent description of this time period is available at
period is available at <http://www.ietf.org/mail-archive/web/ietf/current/msg51644.html>.
http://www.ietf.org/mail-archive/web/ietf/current/msg51644.html
In 2008 and 2009, the NETMOD working group produced a specification In 2008 and 2009, the NETMOD working group produced a specification
for YANG ([RFCYANG]) as a means for defining data models for NETCONF, for YANG [RFC6020] as a means for defining data models for NETCONF,
allowing both standard and proprietary data models to be published in allowing both standard and proprietary data models to be published in
a form that is easily digestible by human readers and satisfies many a form that is easily digestible by human readers and satisfies many
of the issues raised in the IAB NM workshop. This brings NETCONF to of the issues raised in the IAB NM workshop. This brings NETCONF to
a point where is can be used to develop standard data models within a point where is can be used to develop standard data models within
the IETF. the IETF.
YANG allows a modeler to create a data model, to define the YANG allows a modeler to create a data model, to define the
organization of the data in that model, and to define constraints on organization of the data in that model, and to define constraints on
that data. Once published, the YANG module acts as a contract that data. Once published, the YANG module acts as a contract
between the client and server, with both parties understanding how between the client and server, with both parties understanding how
skipping to change at page 8, line 8 skipping to change at page 7, line 16
will not affect the device until a "commit-configuration" operation will not affect the device until a "commit-configuration" operation
is invoked. is invoked.
NETCONF defines operations that are invoked as RPCs from the client NETCONF defines operations that are invoked as RPCs from the client
(the application) to the server (running on the device). The (the application) to the server (running on the device). The
following table lists some of these operations: following table lists some of these operations:
+---------------+---------------------------------------------------+ +---------------+---------------------------------------------------+
| Operation | Description | | Operation | Description |
+---------------+---------------------------------------------------+ +---------------+---------------------------------------------------+
| commit | Commits the "candidate" configuration to | | commit | Commit the "candidate" configuration to "running" |
| | "running" |
| copy-config | Copy one configuration datastore to another | | copy-config | Copy one configuration datastore to another |
| delete-config | Delete a configuration datastore | | delete-config | Delete a configuration datastore |
| edit-config | Change the contents of a configuration datastore | | edit-config | Change the contents of a configuration datastore |
| get-config | Retrieve all or part of a configuration datastore | | get-config | Retrieve all or part of a configuration datastore |
| lock | Prevent changes to a datastore from another party | | lock | Prevent changes to a datastore from another party |
| unlock | Release a lock on a datastore | | unlock | Release a lock on a datastore |
+---------------+---------------------------------------------------+ +---------------+---------------------------------------------------+
NETCONF's "capability" mechanism allows the device to announce the NETCONF's "capability" mechanism allows the device to announce the
set of capabilities that the device supports, including protocol set of capabilities that the device supports, including protocol
skipping to change at page 8, line 36 skipping to change at page 7, line 43
NETCONF also defines a means of sending asynchronous notifications NETCONF also defines a means of sending asynchronous notifications
from the server to the client, described in [RFC5277]. from the server to the client, described in [RFC5277].
In addition, NETCONF can fetch state data, receive notifications, and In addition, NETCONF can fetch state data, receive notifications, and
invoke additional RPC methods defined as part of a capability. invoke additional RPC methods defined as part of a capability.
Complete information about NETCONF can be found in [RFC4741]. Complete information about NETCONF can be found in [RFC4741].
2.1.1. NETCONF Transport Mappings 2.1.1. NETCONF Transport Mappings
NETCONF can run over any transport protocol that meets the NETCONF can run over any transport protocol that meets the
requirements defined in RFC4741, including requirements defined in RFC 4741, including
o connection-oriented operation o connection-oriented operation
o authentication o authentication
o integrity o integrity
o confidentiality o confidentiality
[RFC4742] defines an mapping for the SSH ([RFC4251]) protocol, which [RFC4742] defines a mapping for the Secure Shell (SSH) [RFC4251]
is the mandatory transport protocol. Others include SOAP protocol, which is the mandatory transport protocol. Others include
([RFC4743]), BEEP ([RFC4744]), and TLS ([RFC5539]). SOAP [RFC4743], the Blocks Extensible Exchange Protocol (BEEP)
[RFC4744], and Transport Layer Security (TLS) [RFC5539].
2.2. YANG 2.2. YANG
YANG is a data modeling language for NETCONF. It allows the YANG is a data modeling language for NETCONF. It allows the
description of hierarchies of data nodes ("nodes") and the description of hierarchies of data nodes ("nodes") and the
constraints that exist among them. YANG defines data models and how constraints that exist among them. YANG defines data models and how
to manipulate those models via NETCONF protocol operations. to manipulate those models via NETCONF protocol operations.
Each YANG module defines a data model, uniquely identified by a Each YANG module defines a data model, uniquely identified by a
namespace URI. These data models are extensible in a manner that namespace URI. These data models are extensible in a manner that
allows tight integration of standard data models and proprietary data allows tight integration of standard data models and proprietary data
models. Models are built from organizational containers, lists of models. Models are built from organizational containers, lists of
data nodes and data node forming leafs of the data tree. data nodes, and data-node-forming leafs of the data tree.
module example-ospf { module example-ospf {
namespace "http://example.org/netconf/ospf"; namespace "http://example.org/netconf/ospf";
prefix ospf; prefix ospf;
import network-types { // Access another module's def'ns import network-types { // Access another module's def'ns
prefix nett; prefix nett;
} }
container ospf { // Declare the top-level tag container ospf { // Declare the top-level tag
skipping to change at page 11, line 12 skipping to change at page 10, line 14
The following table briefly describes some common YANG statements: The following table briefly describes some common YANG statements:
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Statement | Description | | Statement | Description |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| augment | Extends existing data hierarchies | | augment | Extends existing data hierarchies |
| choice | Defines mutually exclusive alternatives | | choice | Defines mutually exclusive alternatives |
| container | Defines a layer of the data hierarchy | | container | Defines a layer of the data hierarchy |
| extension | Allows new statements to be added to YANG | | extension | Allows new statements to be added to YANG |
| feature | Indicates parts of the model are optional | | feature | Indicates parts of the model that are optional |
| grouping | Groups data definitions into reusable sets | | grouping | Groups data definitions into reusable sets |
| key | Defines the key leafs for lists | | key | Defines the key leafs for lists |
| leaf | Defines a leaf node in the data hierarchy | | leaf | Defines a leaf node in the data hierarchy |
| leaf-list | A leaf node that can appear multiple times | | leaf-list | A leaf node that can appear multiple times |
| list | A hierarchy that can appear multiple times | | list | A hierarchy that can appear multiple times |
| notification | Defines notification | | notification | Defines notification |
| rpc | Defines input and output parameters for an RPC | | rpc | Defines input and output parameters for an RPC |
| | operation | | | operation |
| typedef | Defines a new type | | typedef | Defines a new type |
| uses | Incorporates the contents of a "grouping" | | uses | Incorporates the contents of a "grouping" |
skipping to change at page 12, line 4 skipping to change at page 11, line 19
| mandatory | Requires the node appear | | mandatory | Requires the node appear |
| max-elements | Limits the number of instances in a list | | max-elements | Limits the number of instances in a list |
| min-elements | Limits the number of instances in a list | | min-elements | Limits the number of instances in a list |
| must | XPath expression must be true | | must | XPath expression must be true |
| pattern | Regular expression must be satisfied | | pattern | Regular expression must be satisfied |
| range | Value must appear in range | | range | Value must appear in range |
| reference | Value must appear elsewhere in the data | | reference | Value must appear elsewhere in the data |
| unique | Value must be unique within the data | | unique | Value must be unique within the data |
| when | Node is only present when XPath expression is true | | when | Node is only present when XPath expression is true |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
The "must" and "when" statements use XPath ([W3CXPATH]) expressions
to specify conditions that are semantically evaluated against the The "must" and "when" statements use XPath [W3CXPATH] expressions to
data hierarchy, but neither the client nor the server are required to specify conditions that are semantically evaluated against the data
hierarchy, but neither the client nor the server are required to
implement the XPath specification. Instead they can use any means to implement the XPath specification. Instead they can use any means to
ensure these conditions are met. ensure these conditions are met.
2.2.2. Flexibility 2.2.2. Flexibility
YANG uses the "union" type and the "choice" and "feature" statements YANG uses the "union" type and the "choice" and "feature" statements
to give modelers flexibility in defining their data models. The to give modelers flexibility in defining their data models. The
"union" type allows a single leaf to accept multiple types, like an "union" type allows a single leaf to accept multiple types, like an
integer or the word "unbounded": integer or the word "unbounded":
type union { type union {
type int32; type int32;
type enumeration { type enumeration {
enum "unbounded"; enum "unbounded";
} }
} }
The "choice" statement lists a set of mutually exclusive nodes, so a The "choice" statement lists a set of mutually exclusive nodes, so a
valid configuration can choose any one node (or case). The "feature" valid configuration can choose any one node (or case). The "feature"
statement allows the modeler to identify parts of the model which can statement allows the modeler to identify parts of the model that can
be optional, and allows the device to indicate whether it implements be optional, and allows the device to indicate whether it implements
these optional portions. these optional portions.
The "deviation" statement allows the device, to indicate parts of a The "deviation" statement allows the device to indicate parts of a
YANG module which the device does not faithfully implement. While YANG module that the device does not faithfully implement. While
devices are encouraged to fully abide according to the contract devices are encouraged to fully abide according to the contract
presented in the YANG module, real world situations may force the presented in the YANG module, real-world situations may force the
device to break the contract. Deviations give a means of declaring device to break the contract. Deviations give a means of declaring
this limitation, rather than leaving it to be discovered via run-time this limitation, rather than leaving it to be discovered via run-time
errors. errors.
2.2.3. Extensibility Model 2.2.3. Extensibility Model
XML includes the concept of namespaces, allowing XML elements from XML includes the concept of namespaces, allowing XML elements from
different sources to be combined in the same hierarchy without different sources to be combined in the same hierarchy without
risking collision. YANG modules define content for specific risking collision. YANG modules define content for specific
namespaces, but one module may augment the definition of another namespaces, but one module may augment the definition of another
skipping to change at page 13, line 29 skipping to change at page 13, line 6
description "Don't inform other protocols about" description "Don't inform other protocols about"
+ " neighbor down events"; + " neighbor down events";
} }
} }
} }
The <no-neighbor-down-notification> element is then placed in the The <no-neighbor-down-notification> element is then placed in the
vendorx namespace: vendorx namespace:
<ospf xmlns="http://example.org/netconf/ospf" <ospf xmlns="http://example.org/netconf/ospf"
xmlns:vendorx=""http://vendorx.example.com/ospf"> xmlns:vendorx="http://vendorx.example.com/ospf">
<area> <area>
<name>0.0.0.0</name> <name>0.0.0.0</name>
<interface> <interface>
<name>ge-0/0/0.0</name> <name>ge-0/0/0.0</name>
<priority>30</priority> <priority>30</priority>
<vendorx:no-neighbor-down-notification/> <vendorx:no-neighbor-down-notification/>
</interface> </interface>
skipping to change at page 14, line 4 skipping to change at page 13, line 30
Augmentations are seamlessly integrated with base modules, allowing Augmentations are seamlessly integrated with base modules, allowing
them to be fetched, archived, loaded, and deleted within their them to be fetched, archived, loaded, and deleted within their
natural hierarchy. If a client application asks for the natural hierarchy. If a client application asks for the
configuration for a specific OSPF area, it will receive the sub- configuration for a specific OSPF area, it will receive the sub-
hierarchy for that area, complete with any augmented data. hierarchy for that area, complete with any augmented data.
2.3. YANG Translations 2.3. YANG Translations
The YANG data modeling language is the central piece of a group of The YANG data modeling language is the central piece of a group of
related technologies. The YANG language itself, described in related technologies. The YANG language itself, described in
[RFC6020], defines the syntax of the language and its statements, the
[RFCYANG], defines the syntax of the language and its statements, the
meaning of those statements, and how to combine them to build the meaning of those statements, and how to combine them to build the
hierarchy of nodes that describe a data model. hierarchy of nodes that describe a data model.
That document also defines the "on the wire" XML content for NETCONF That document also defines the "on the wire" XML content for NETCONF
operations on data models defined in YANG modules. This includes the operations on data models defined in YANG modules. This includes the
basic mapping between YANG data tree nodes and XML elements, as well basic mapping between YANG data tree nodes and XML elements, as well
as mechanisms used in <edit-config> content to manipulate that data, as mechanisms used in <edit-config> content to manipulate that data,
such as arranging the order of nodes within a list. such as arranging the order of nodes within a list.
YANG uses a syntax that is regular and easily described, primarily YANG uses a syntax that is regular and easily described, primarily
designed for human readability. YANG's syntax is friendly to email, designed for human readability. YANG's syntax is friendly to email,
diff, patch, and the constraints of RFC formatting. diff, patch, and the constraints of RFC formatting.
2.3.1. YIN 2.3.1. YIN
In some environments, incorporating a YANG parser may not be an In some environments, incorporating a YANG parser may not be an
acceptable option. For those scenarios, an XML grammar for YANG is acceptable option. For those scenarios, an XML grammar for YANG is
defined as YIN (YANG Independent Notation). YIN allows the use of defined as YIN (YANG Independent Notation). YIN allows the use of
XML parsers which are readily available in both open source and XML parsers that are readily available in both open source and
commercial versions. Conversion between YANG and YIN is direct, commercial versions. Conversion between YANG and YIN is direct,
loss-less and reversible. YANG statements are converted to XML loss-less, and reversible. YANG statements are converted to XML
elements, preserving the structure and content of YANG, but enabling elements, preserving the structure and content of YANG, but enabling
the use of off-the-shelf XML parsers rather than requiring the the use of off-the-shelf XML parsers rather than requiring the
integration of a YANG parser. YIN maintains complete semantic integration of a YANG parser. YIN maintains complete semantic
equivalence with YANG. equivalence with YANG.
2.3.2. DSDL (RELAX NG) 2.3.2. DSDL (RELAX NG)
Since NETCONF content is encoded in XML, it is natural to use XML Since NETCONF content is encoded in XML, it is natural to use XML
schema languages for their validation. To facilitate this, YANG schema languages for their validation. To facilitate this, YANG
offers a standardized mapping of YANG modules into Document Schema offers a standardized mapping of YANG modules into Document Schema
Description Languages ([RFCYANGDSDL]), of which RELAX NG is a major Definition Languages [RFC6110], of which RELAX NG is a major
component. component.
DSDL is considered to be the best choice as a standard schema DSDL is considered to be the best choice as a standard schema
language because it addresses not only grammar and datatypes of XML language because it addresses not only grammar and datatypes of XML
documents but also semantic constraints and rules for modifying the documents but also semantic constraints and rules for modifying the
information set of the document. information set of the document.
In addition, DSDL offers formal means for coordinating multiple In addition, DSDL offers formal means for coordinating multiple
independent schemas and specifying how to apply the schemas to the independent schemas and specifying how to apply the schemas to the
various parts of the document. This is useful since YANG content is various parts of the document. This is useful since YANG content is
typically composed of multiple vocabularies. typically composed of multiple vocabularies.
2.4. YANG Types 2.4. YANG Types
YANG supports a number of builtin types, and allows additional types YANG supports a number of builtin types, and allows additional types
to be derived from those types in an extensible manner. New types to be derived from those types in an extensible manner. New types
can add additional restrictions to allowable data values. can add additional restrictions to allowable data values.
A standard type library for use by YANG is available [RFCYANGTYPES]. A standard type library for use by YANG is available [RFC6021].
These YANG modules define commonly used data types for IETF-related These YANG modules define commonly used data types for IETF-related
standards. standards.
2.5. IETF Guidelines 2.5. IETF Guidelines
A set of additional guidelines are defined that indicate desirable A set of additional guidelines is defined that indicate desirable
usage for authors and reviewers of standards track specifications usage for authors and reviewers of Standards-Track specifications
containing YANG data model modules ([RFCYANGUSAGE]). These containing YANG data model modules [RFC6087]. These guidelines
guidelines should be used as a basis for reviews of other YANG data should be used as a basis for reviews of other YANG data model
model documents. documents.
3. Working with YANG 3. Working with YANG
3.1. Building NETCONF- and YANG-based Solutions 3.1. Building NETCONF- and YANG-Based Solutions
In the typical YANG-based solution, the client and server are driven In the typical YANG-based solution, the client and server are driven
by the content of YANG modules. The server includes the definitions by the content of YANG modules. The server includes the definitions
of the modules as meta-data that is available to the NETCONF engine. of the modules as meta-data that is available to the NETCONF engine.
This engine processes incoming requests, uses the meta-data to parse This engine processes incoming requests, uses the meta-data to parse
and verify the request, performs the requested operation, and returns and verify the request, performs the requested operation, and returns
the results to the client. the results to the client.
+----------------------------+ +----------------------------+
|Server (device) | |Server (device) |
skipping to change at page 17, line 47 skipping to change at page 16, line 39
engine. Or the client may be targeted at the specific YANG model, engine. Or the client may be targeted at the specific YANG model,
rather than being driven generically. Such a client might be a rather than being driven generically. Such a client might be a
simple shell script that stuffs arguments into an XML payload simple shell script that stuffs arguments into an XML payload
template and sends it to the server. template and sends it to the server.
3.2. Addressing Operator Requirements 3.2. Addressing Operator Requirements
NETCONF and YANG address many of the issues raised in the IAB NM NETCONF and YANG address many of the issues raised in the IAB NM
workshop. workshop.
o Ease of use: YANG is designed to be human friendly, simple and o Ease of use: YANG is designed to be human friendly, simple, and
readable. Many tricky issues remain due to the complexity of the readable. Many tricky issues remain due to the complexity of the
problem domain, but YANG strives to make them more visible and problem domain, but YANG strives to make them more visible and
easier to deal with. easier to deal with.
o Configuration and state data: YANG clearly divides configuration o Configuration and state data: YANG clearly divides configuration
data from other types of data. data from other types of data.
o Transactions: NETCONF provides a simple transaction mechanism. o Transactions: NETCONF provides a simple transaction mechanism.
o Generation of deltas: A YANG module gives enough information to o Generation of deltas: A YANG module gives enough information to
generate the delta needed to change between two configuration data generate the delta needed to change between two configuration data
sets. sets.
o Dump and restore: NETCONF gives the ability to save and restore o Dump and restore: NETCONF gives the ability to save and restore
configuration data. This can also performed for a specific YANG configuration data. This can also be performed for a specific
module. YANG module.
o Network-wide configuration: NETCONF supports robust network-wide o Network-wide configuration: NETCONF supports robust network-wide
configuration transactions via the commit and confirmed-commit configuration transactions via the commit and confirmed-commit
capability. When a change is attempted that affects multiple capabilities. When a change is attempted that affects multiple
devices, these capabilities simplifies the management of failure devices, these capabilities simplify the management of failure
scenarios, resulting in the ability to have transactions that will scenarios, resulting in the ability to have transactions that will
dependably succeed or fail atomically. dependably succeed or fail atomically.
o Text-friendly: YANG modules are very text friendly, as is the data o Text-friendly: YANG modules are very text friendly, as is the data
they define. they define.
o Configuration handling: NETCONF addresses the ability to o Configuration handling: NETCONF addresses the ability to
distinguish between distributing configuration data and activating distinguish between distributing configuration data and activating
it. it.
o Task-oriented: A YANG module can define specific tasks as RPC o Task-oriented: A YANG module can define specific tasks as RPC
operations. A client can choose to invoke the RPC operation or to operations. A client can choose to invoke the RPC operation or to
access any underlying data directly. access any underlying data directly.
o Full coverage: YANG modules can be defined that give full coverage o Full coverage: YANG modules can be defined that give full coverage
to all the native abilities of the device. Giving this access to all the native abilities of the device. Giving this access
avoids the need to resort to the command line interface (CLI) avoids the need to resort to the command line interface (CLI)
using tools such as Expect ([SWEXPECT]). using tools such as Expect [SWEXPECT].
o Timeliness: YANG modules can be tied to CLI operations, so all o Timeliness: YANG modules can be tied to CLI operations, so all
native operations and data are immediately available. native operations and data are immediately available.
o Implementation difficulty: YANG's flexibility enables modules that o Implementation difficulty: YANG's flexibility enables modules that
can be more easily implemented. Adding "features" and replacing can be more easily implemented. Adding "features" and replacing
"third normal form" with a natural data hierarchy should reduce "third normal form" with a natural data hierarchy should reduce
complexity. complexity.
o Simple data modeling language: YANG has sufficient power to be o Simple data modeling language: YANG has sufficient power to be
usable in other situations. In particular, on-box API and native usable in other situations. In particular, on-box API and native
CLI can be integrated to achieve simplification of the CLI can be integrated to achieve simplification of the
infrastructure. infrastructure.
o Internationalization: YANG uses UTF-8 ([RFC3629]) encoded unicode o Internationalization: YANG uses UTF-8 [RFC3629] encoded Unicode
characters. characters.
o Event correlation: YANG integrates RPC operations, notification, o Event correlation: YANG integrates RPC operations, notification,
configuration and state data, enabling internal references. For configuration, and state data, enabling internal references. For
example, a field in a notification can be tagged as pointing to a example, a field in a notification can be tagged as pointing to a
BGP peer, and the client application can easily find that peer in BGP peer, and the client application can easily find that peer in
the configuration data. the configuration data.
o Implementation costs: Significant effort has been made to keep o Implementation costs: Significant effort has been made to keep
implementation costs as low as possible. implementation costs as low as possible.
o Human friendly syntax: YANG's syntax is optimized for the reader, o Human-friendly syntax: YANG's syntax is optimized for the reader,
specifically the reviewer on the basis that this is the most specifically the reviewer on the basis that this is the most
common human interaction. common human interaction.
o Post-processing: Use of XML will maximize the opportunities for o Post-processing: Use of XML will maximize the opportunities for
post-processing of data, possibly using XML-based technologies post-processing of data, possibly using XML-based technologies
like XPath ([W3CXPATH], XQuery ([W3CXQUERY]), and XSLT like XPath [W3CXPATH], XQuery [W3CXQUERY], and XSLT [W3CXSLT].
([W3CXSLT]).
o Semantic mismatch: Richer, more descriptive data models will o Semantic mismatch: Richer, more descriptive data models will
reduce the possibility of semantic mismatch. With the ability to reduce the possibility of semantic mismatch. With the ability to
define new primitives, YANG modules will be more specific in define new primitives, YANG modules will be more specific in
content, allowing more enforcement of rules and constraints. content, allowing more enforcement of rules and constraints.
o Security: NETCONF runs over transport protocols secured by SSH or o Security: NETCONF runs over transport protocols secured by SSH or
TLS, allowing secure communications and authentication using well- TLS, allowing secure communications and authentication using well-
trusted technology. The secure transport can use existing key and trusted technology. The secure transport can use existing key and
credential management infrastructure, reducing deployment costs. credential management infrastructure, reducing deployment costs.
skipping to change at page 20, line 23 skipping to change at page 19, line 10
application developers need to code their applications to take application developers need to code their applications to take
advantage of that data model. There are a variety of strategies for advantage of that data model. There are a variety of strategies for
performing each piece of this work. This section discusses some of performing each piece of this work. This section discusses some of
those strategies. those strategies.
3.3.1. Modeler 3.3.1. Modeler
The modeler defines a data model based on their in-depth knowledge of The modeler defines a data model based on their in-depth knowledge of
the problem domain being modeled. This model should be as simple as the problem domain being modeled. This model should be as simple as
possible, but should balance complexity with expressiveness. The possible, but should balance complexity with expressiveness. The
organization of the model should target not only the current model, organization of the model not only should target the current model
but should allow for extensibility from other modules and for but also should allow for extensibility from other modules and for
adaptability to future changes. adaptability to future changes.
Additional modeling issues are discussed in Section 4. Additional modeling issues are discussed in Section 4.
3.3.2. Reviewer 3.3.2. Reviewer
The reviewer role is perhaps the most important and the time The reviewer role is perhaps the most important and the time
reviewers are willing to give is precious. To help the reviewer, reviewers are willing to give is precious. To help the reviewer,
YANG stresses readability, with a human-friendly syntax, natural data YANG stresses readability, with a human-friendly syntax, natural data
hierarchy, and simple, concise statements. hierarchy, and simple, concise statements.
3.3.3. Device Developer 3.3.3. Device Developer
The YANG model tells the device developer what data is being modeled. The YANG model tells the device developer what data is being modeled.
The developer reads the YANG models and writes code that supports the The developer reads the YANG models and writes code that supports the
model. The model describes the data hierarchy and associated model. The model describes the data hierarchy and associated
constraints, and the description and reference material helps the constraints, and the description and reference material helps the
developer understand how to transform the models view into the developer understand how to transform the model's view into the
device's native implementation. device's native implementation.
3.3.3.1. Generic Content Support 3.3.3.1. Generic Content Support
The YANG model can be compiled into a YANG-based engine for either The YANG model can be compiled into a YANG-based engine for either
the client or server side. Incoming data can be validated, as can the client or server side. Incoming data can be validated, as can
outgoing data. The complete configuration datastore may be validated outgoing data. The complete configuration datastore may be validated
in accordance with the constraints described in the data model. in accordance with the constraints described in the data model.
Serializers and deserializers for generating and receiving NETCONF Serializers and de-serializers for generating and receiving NETCONF
content can be driven by the meta-data in the model. As data is content can be driven by the meta-data in the model. As data is
received, the meta-data is consulted to ensure the validity of received, the meta-data is consulted to ensure the validity of
incoming XML elements. incoming XML elements.
3.3.3.2. XML Definitions 3.3.3.2. XML Definitions
The YANG module dictates the XML encoding for data sent via NETCONF. The YANG module dictates the XML encoding for data sent via NETCONF.
The rules that define the encoding are fixed, so the YANG module can The rules that define the encoding are fixed, so the YANG module can
be used to ascertain whether a specific NETCONF payload is obeying be used to ascertain whether a specific NETCONF payload is obeying
the rules. the rules.
skipping to change at page 21, line 36 skipping to change at page 20, line 26
of YANG modules, implementing their organization, rules, and logic of YANG modules, implementing their organization, rules, and logic
directly with explicit knowledge. For example, a script could be directly with explicit knowledge. For example, a script could be
written to change the domain name of a set of devices using a written to change the domain name of a set of devices using a
standard YANG module that includes such a leaf node. This script standard YANG module that includes such a leaf node. This script
takes the new domain name as an argument and inserts it into a string takes the new domain name as an argument and inserts it into a string
containing the rest of the XML encoding as required by the YANG containing the rest of the XML encoding as required by the YANG
module. This content is then sent via NETCONF to each of the module. This content is then sent via NETCONF to each of the
devices. devices.
This type of application is useful for small, fixed problems where This type of application is useful for small, fixed problems where
the cost and complexity of flexibility is overwhelmed by the ease of the cost and complexity of flexibility are overwhelmed by the ease of
hard coding direct knowledge into the application. hard coding direct knowledge into the application.
3.3.4.2. Bottom Up 3.3.4.2. Bottom Up
An application may take a generic, bottom up approach to An application may take a generic, bottom-up approach to
configuration, concentrating on the device's data directly and configuration, concentrating on the device's data directly and
treating that data without specific understanding. treating that data without specific understanding.
YANG modules may be used to drive the operation of the YANG YANG modules may be used to drive the operation of the YANG
equivalent of a "MIB Browser". Such an application manipulates the equivalent of a "MIB browser". Such an application manipulates the
device's configuration data based on the data organization contained device's configuration data based on the data organization contained
in the YANG module. For example, a GUI may present a straight- in the YANG module. For example, a GUI may present a straightforward
forward visualization where elements of the YANG hierarchy are visualization where elements of the YANG hierarchy are depicted in a
depicted in a hierarchy of folders or GUI panels. Clicking on a line hierarchy of folders or GUI panels. Clicking on a line expands to
expands to the contents of the matching XML hierarchy. the contents of the matching XML hierarchy.
This type of GUI can easily be built by generating XSLT stylesheets This type of GUI can easily be built by generating XSLT stylesheets
from the YANG data models. An XSLT engine can then be used to turn from the YANG data models. An XSLT engine can then be used to turn
configuration data into a set of web pages. configuration data into a set of web pages.
The YANG modules allow the application to enforce a set of The YANG modules allow the application to enforce a set of
constraints without understanding the semantics of the YANG module. constraints without understanding the semantics of the YANG module.
3.3.4.3. Top Down 3.3.4.3. Top Down
In contrast to the bottom-up approach, the top-down approach allows In contrast to the bottom-up approach, the top-down approach allows
the application to take a view of the configuration data which is the application to take a view of the configuration data that is
distinct from the standard and/or proprietary YANG modules. The distinct from the standard and/or proprietary YANG modules. The
application is free to construct its own model for data organization application is free to construct its own model for data organization
and to present this model to the user. When the application needs to and to present this model to the user. When the application needs to
transmit data to a device, the application transforms its data from transmit data to a device, the application transforms its data from
the problem-oriented view of the world into the data needed for that the problem-oriented view of the world into the data needed for that
particular device. This transformation is under the control and particular device. This transformation is under the control and
maintenance of the application, allowing the transformation to be maintenance of the application, allowing the transformation to be
changed and updated without affecting the device. changed and updated without affecting the device.
For example, an application could be written that models VPNs in a For example, an application could be written that models VPNs in a
skipping to change at page 23, line 32 skipping to change at page 22, line 7
leaf device { ... } leaf device { ... }
leaf interface { ... } leaf interface { ... }
} }
list classifiers { list classifiers {
... ...
} }
} }
The application can use such a YANG module to drive its operation, The application can use such a YANG module to drive its operation,
building VPN instances in a database and then pushing the building VPN instances in a database and then pushing the
configuration for those VPNs to individual devices using either a configuration for those VPNs to individual devices either using a
standard device model (e.g. example-bgpvpn.yang) or by transforming standard device model (e.g., example-bgpvpn.yang) or by transforming
that standard device content into some proprietary format for devices that standard device content into some proprietary format for devices
that do not support that standard. that do not support that standard.
4. Modeling Considerations 4. Modeling Considerations
This section discusses considerations the modeler should be aware of This section discusses considerations the modeler should be aware of
while developing models in YANG. while developing models in YANG.
4.1. Default Values 4.1. Default Values
skipping to change at page 24, line 25 skipping to change at page 22, line 32
issue, and YANG gives flexibility to the device implementation in issue, and YANG gives flexibility to the device implementation in
terms of how default values are handled. The requirement is that the terms of how default values are handled. The requirement is that the
device "MUST operationally behave as if the leaf was present in the device "MUST operationally behave as if the leaf was present in the
data tree with the default value as its value". This gives the data tree with the default value as its value". This gives the
device implementation choices in how default values are handled. device implementation choices in how default values are handled.
One choice is to view the configuration as a set of instructions for One choice is to view the configuration as a set of instructions for
how the device should be configured. If a data value that is given how the device should be configured. If a data value that is given
as part of those instructions is the default value, then it should be as part of those instructions is the default value, then it should be
retained as part of the configuration, but if it is not explicitly retained as part of the configuration, but if it is not explicitly
given, then the value is not considered to be part of configuration. given, then the value is not considered to be part of the
configuration.
Another choice is to trim values that are identical to the default Another choice is to trim values that are identical to the default
values, implicitly removing them from the configuration datastore. values, implicitly removing them from the configuration datastore.
The act of setting a leaf to its default value effectively deletes The act of setting a leaf to its default value effectively deletes
that leaf. that leaf.
The device could also choose to report all default values, regardless The device could also choose to report all default values, regardless
of whether they were explicitly set. This choice eases the work of a of whether they were explicitly set. This choice eases the work of a
client that needs default values, but may significantly increase the client that needs default values, but may significantly increase the
size of the configuration data. size of the configuration data.
skipping to change at page 24, line 48 skipping to change at page 23, line 12
networking devices and supporting them allows YANG to reduce networking devices and supporting them allows YANG to reduce
implementation and deployment costs of YANG-based models. implementation and deployment costs of YANG-based models.
When the client retrieves data from the device, it must be prepared When the client retrieves data from the device, it must be prepared
to handle the absence of leaf nodes with the default value, since the to handle the absence of leaf nodes with the default value, since the
server is not required to send such leaf elements. This permits the server is not required to send such leaf elements. This permits the
device to implement either of the first two default handling schemes device to implement either of the first two default handling schemes
given above. given above.
Regardless of the implementation choice, the device can support the Regardless of the implementation choice, the device can support the
"with-defaults" capability ([RFCWITHDEFAULTS]) and give the client "with-defaults" capability [RFC6243] and give the client the ability
the ability to select the desired handling of default values. to select the desired handling of default values.
When evaluating the XPath expressions for constraints like "must" and When evaluating the XPath expressions for constraints like "must" and
"when", the evaluation context for the expressions will include any "when", the evaluation context for the expressions will include any
appropriate default values, so the modeler can depend on consistent appropriate default values, so the modeler can depend on consistent
behavior from all devices. behavior from all devices.
4.2. Compliance 4.2. Compliance
In developing good data models, there are many conflicting interests In developing good data models, there are many conflicting interests
the data modeler must keep in mind. Modelers need to be aware of the data modeler must keep in mind. Modelers need to be aware of
skipping to change at page 25, line 26 skipping to change at page 23, line 39
o flexibility o flexibility
o extensibility o extensibility
o deviations o deviations
For a model to be interesting, it must be useful, solving a problem For a model to be interesting, it must be useful, solving a problem
in a more direct or more powerful way than can be accomplished in a more direct or more powerful way than can be accomplished
without the model. The model should maximize the usefulness of the without the model. The model should maximize the usefulness of the
model with in the problem domain. model within the problem domain.
Modelers should build models that maximize the number of devices that Modelers should build models that maximize the number of devices that
can faithfully implement the model. If the model is drawn too can faithfully implement the model. If the model is drawn too
narrowly, or includes too many assumptions about the device, then the narrowly, or includes too many assumptions about the device, then the
difficulty and cost of accurately implementing the model will lead to difficulty and cost of accurately implementing the model will lead to
low quality implementations, interoperability issues, and will reduce low-quality implementations and interoperability issues, and will
the value of the model. reduce the value of the model.
Modelers can use the "feature" statement in their models to give the Modelers can use the "feature" statement in their models to give the
device some flexibility by partitioning their model and allowing the device some flexibility by partitioning their model and allowing the
device to indicate which portions of the model are implemented on the device to indicate which portions of the model are implemented on the
device. For example, if the model includes some a "logging" feature device. For example, if the model includes some "logging" feature, a
, a device with no storage facilities for the log can tell the client device with no storage facilities for the log can tell the client
that it does not support this feature of the model. that it does not support this feature of the model.
Models can be extended via the "augment" statement, and the modeler Models can be extended via the "augment" statement, and the modeler
should consider how their model is likely to be extended. These should consider how their model is likely to be extended. These
augmentations can be defined by vendors, applications, or standards augmentations can be defined by vendors, applications, or standards
bodies. bodies.
Deviations are a means of allowing the devices to indicate where its Deviations are a means of allowing the devices to indicate where its
implementation is not in full compliance with the model. For implementation is not in full compliance with the model. For
example, once a model is published, an implementer may decide to make example, once a model is published, an implementer may decide to make
skipping to change at page 26, line 34 skipping to change at page 24, line 48
The distinction between configuration data, operational state data, The distinction between configuration data, operational state data,
and statistics is important to understand for data model writers and and statistics is important to understand for data model writers and
people who plan to extend the NETCONF protocol. This section first people who plan to extend the NETCONF protocol. This section first
discusses some background and then provides a definition and some discusses some background and then provides a definition and some
examples. examples.
4.3.1. Background 4.3.1. Background
During the IAB NM workshop, operators did formulate the following two During the IAB NM workshop, operators did formulate the following two
requirements: requirements, as listed in [RFC3535]:
2. It is necessary to make a clear distinction between 2. It is necessary to make a clear distinction between
configuration data, data that describes operational state configuration data, data that describes operational state,
and statistics. Some devices make it very hard to determine and statistics. Some devices make it very hard to determine
which parameters were administratively configured and which which parameters were administratively configured and which
were obtained via other mechanisms such as routing were obtained via other mechanisms such as routing
protocols. protocols.
3. It is required to be able to fetch separately configuration 3. It is required to be able to fetch separately configuration
data, operational state data, and statistics from devices, data, operational state data, and statistics from devices,
and to be able to compare these between devices. and to be able to compare these between devices.
The NETCONF protocol defined in RFC 4741 distinguishes two types of The NETCONF protocol defined in RFC 4741 distinguishes two types of
data, namely configuration data and state data: data -- namely, configuration data and state data:
Configuration data is the set of writable data that is Configuration data is the set of writable data that is
required to transform a system from its initial default state required to transform a system from its initial default state
into its current state. into its current state.
State data is the additional data on a system that is not State data is the additional data on a system that is not
configuration data such as read-only status information and configuration data such as read-only status information and
collected statistics. collected statistics.
NETCONF does not follow the distinction formulated by the operators NETCONF does not follow the distinction formulated by the operators
skipping to change at page 27, line 25 skipping to change at page 25, line 39
data, since it considers state data to include both statistics and data, since it considers state data to include both statistics and
operational state data. operational state data.
4.3.2. Definitions 4.3.2. Definitions
Below is a definition for configuration data, operational state data, Below is a definition for configuration data, operational state data,
and statistical data. The definition borrows from previous work. and statistical data. The definition borrows from previous work.
o Configuration data is the set of writable data that is required to o Configuration data is the set of writable data that is required to
transform a system from its initial default state into its current transform a system from its initial default state into its current
state. [RFC4741] state [RFC4741].
o Operational state data is a set of data that has been obtained by o Operational state data is a set of data that has been obtained by
the system at runtime and influences the system's behaviour the system at runtime and influences the system's behavior similar
similar to configuration data. In contrast to configuration data, to configuration data. In contrast to configuration data,
operational state is transient and modified by interactions with operational state is transient and modified by interactions with
internal components or other systems via specialized protocols. internal components or other systems via specialized protocols.
o Statistical data is the set of read-only data created by a system o Statistical data is the set of read-only data created by a system
itself. It describes the performance of the system and its itself. It describes the performance of the system and its
components. components.
The following examples help to clarify the difference between The following examples help to clarify the difference between
configuration data, operational state data and statistical data. configuration data, operational state data, and statistical data.
4.3.2.1. Example 1: IP Routing Table 4.3.2.1. Example 1: IP Routing Table
IP routing tables can contain entries that are statically configured IP routing tables can contain entries that are statically configured
(configuration data) as well as entries obtained from routing (configuration data) as well as entries obtained from routing
protocols such as OSPF (operational state data). In addition, a protocols such as OSPF (operational state data). In addition, a
routing engine might collect statistics like how often a particular routing engine might collect statistics like how often a particular
routing table entry has been used. routing table entry has been used.
4.3.2.2. Example 2: Interfaces 4.3.2.2. Example 2: Interfaces
skipping to change at page 28, line 23 skipping to change at page 26, line 37
speed. speed.
The system will record statistics (counters) measuring the number of The system will record statistics (counters) measuring the number of
packets, bytes, and errors received and transmitted on each packets, bytes, and errors received and transmitted on each
interface. interface.
4.3.2.3. Example 3: Account Information 4.3.2.3. Example 3: Account Information
Systems usually maintain static configuration information about the Systems usually maintain static configuration information about the
accounts on the system. In addition, systems can obtain information accounts on the system. In addition, systems can obtain information
about accounts from other sources (e.g. LDAP, NIS) dynamically, about accounts from other sources (e.g., Lightweight Directory Access
Protocol (LDAP), Network Information Service (NIS)) dynamically,
leading to operational state data. Information about account usage leading to operational state data. Information about account usage
are examples of statistic data. is an example of statistical data.
Note that configuration data supplied to a system in order to create Note that configuration data supplied to a system in order to create
a new account might be supplemented with additional configuration a new account might be supplemented with additional configuration
information determined by the system when the account is being information determined by the system when the account is being
created (such as a unique account id). Even though the system might created (such as a unique account id). Even though the system might
create such information, it usually becomes part of the static create such information, it usually becomes part of the static
configuration of the system since this data is not transient. configuration of the system since this data is not transient.
4.3.3. Implications 4.3.3. Implications
skipping to change at page 29, line 8 skipping to change at page 27, line 26
between configuration data and operational state data. This leads to between configuration data and operational state data. This leads to
duplication of data structures and might not scale well from a duplication of data structures and might not scale well from a
modeling perspective. modeling perspective.
For example, the configured duplex value and the operational duplex For example, the configured duplex value and the operational duplex
value would be distinct leafs in the data model. value would be distinct leafs in the data model.
4.3.3.2. Additional Operations to Retrieve Operational State 4.3.3.2. Additional Operations to Retrieve Operational State
The NETCONF protocol can be extended with new protocol operations The NETCONF protocol can be extended with new protocol operations
that specifically allow the retrieval of all operational state, e.g. that specifically allow the retrieval of all operational state, e.g.,
by introducing a <get-ops> operation (and perhaps also a <get-stats> by introducing a <get-ops> operation (and perhaps also a <get-stats>
operation). operation).
4.3.3.3. Introduction of an Operational State Datastore 4.3.3.3. Introduction of an Operational State Datastore
Another option could be to introduce a new "configuration" data store Another option could be to introduce a new "configuration" data store
that represents the operational state. A <get-config> operation on that represents the operational state. A <get-config> operation on
the <operational> data store would then return the operational state the <operational> data store would then return the operational state
determining the behaviour of the box instead of its static and determining the behavior of the box instead of its static and
explicit configuration state. explicit configuration state.
4.4. Direction 4.4. Direction
At this time, the only viable solution is to distinctly model the At this time, the only viable solution is to distinctly model the
configuration and operational values. The configuration leaf would configuration and operational values. The configuration leaf would
indicate the desired value, as given by the user, and the operational indicate the desired value, as given by the user, and the operational
leaf would indicate the current value, as observed on the device. leaf would indicate the current value, as observed on the device.
In the duplex example, this would result in two distinct leafs being In the duplex example, this would result in two distinct leafs being
skipping to change at page 31, line 5 skipping to change at page 28, line 20
For example, configured static routes might be a distinct list from For example, configured static routes might be a distinct list from
the operational routing table, since the use of keys and sorting the operational routing table, since the use of keys and sorting
might differ. might differ.
5. Security Considerations 5. Security Considerations
This document discusses an architecture for network management using This document discusses an architecture for network management using
NETCONF and YANG. It has no security impact on the Internet. NETCONF and YANG. It has no security impact on the Internet.
6. IANA Considerations 6. References
This document has no actions for IANA. 6.1. Normative References
7. Normative References [ISODSDL] International Organization for Standardization,
"Document Schema Definition Languages (DSDL) - Part 1:
Overview", ISO/IEC 19757-1, November 2004.
[ISODSDL] International Organization for Standardization, "Document [RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network
Schema Definition Languages (DSDL) - Part 1: Overview", Management Workshop", RFC 3535, May 2003.
ISO/IEC 19757-1, November 2004.
[RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
Management Workshop", RFC 3535, May 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
10646", STD 63, RFC 3629, November 2003. Protocol Architecture", RFC 4251, January 2006.
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
Protocol Architecture", RFC 4251, January 2006. December 2006.
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, [RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF
December 2006. Configuration Protocol over Secure SHell (SSH)",
RFC 4742, December 2006.
[RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF [RFC4743] Goddard, T., "Using NETCONF over the Simple Object
Configuration Protocol over Secure SHell (SSH)", RFC 4742, Access Protocol (SOAP)", RFC 4743, December 2006.
December 2006.
[RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access [RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol
Protocol (SOAP)", RFC 4743, December 2006. over the Blocks Extensible Exchange Protocol (BEEP)",
RFC 4744, December 2006.
[RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol over [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744, Notifications", RFC 5277, July 2008.
December 2006.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event [RFC5539] Badra, M., "NETCONF over Transport Layer Security
Notifications", RFC 5277, July 2008. (TLS)", RFC 5539, May 2009.
[RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
RFC 5539, May 2009. Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010.
[RFCWITHDEFAULTS] [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021,
Bierman, A. and B. Lengyel, "With-defaults capability for October 2010.
NETCONF", draft-ietf-netconf-with-defaults-11.txt (work in
progress).
[RFCYANG] Bjorklund, M., Ed., "YANG - A data modeling language for [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of
the Network Configuration Protocol (NETCONF)", YANG Data Model Documents", RFC 6087, January 2011.
draft-ietf-netmod-yang-13 (work in progress).
[RFCYANGDSDL] [RFC6110] Lhotka, L., "Mapping YANG to Document Schema Definition
Lhotka, L., Mahy, R., and S. Chishom, "Mapping YANG to Languages and Validating NETCONF Content", RFC 6110,
Document Schema Definition Languages and Validating February 2011.
NETCONF Content", draft-ietf-netmod-dsdl-map-07 (work in
progress).
[RFCYANGTYPES] [RFC6243] Bierman, A. and B. Lengyel, "With-defaults Capability
Schoenwaelder, J., "Common YANG Data Types", for NETCONF", RFC 6243, June 2011.
draft-ietf-netmod-yang-types-09.txt (work in progress).
[RFCYANGUSAGE] [SWEXPECT] "The Expect Home Page",
Bierman, A., "Guidelines for Authors and Reviewers of YANG <http://expect.sourceforge.net/>.
Data Model Documents", draft-ietf-netmod-yang-usage-10.txt
(work in progress).
[SWEXPECT] [W3CXPATH] DeRose, S. and J. Clark, "XML Path Language (XPath)
"The Expect Home Page", <http://expect.sourceforge.net/>. Version 1.0", World Wide Web Consortium
Recommendation REC-xpath-19991116, November 1999,
<http://www.w3.org/TR/1999/REC-xpath-19991116>.
[W3CXPATH] [W3CXQUERY] Boag, S., "XQuery 1.0: An XML Query Language", W3C
DeRose, S. and J. Clark, "XML Path Language (XPath) WD WD-xquery-20050915, September 2005.
Version 1.0", World Wide Web Consortium
Recommendation REC-xpath-19991116, November 1999,
<http://www.w3.org/TR/1999/REC-xpath-19991116>.
[W3CXQUERY] [W3CXSD] Walmsley, P. and D. Fallside, "XML Schema Part 0: Primer
Boag, S., "XQuery 1.0: An XML Query Language", W3C WD WD- Second Edition", World Wide Web Consortium
xquery-20050915, September 2005. Recommendation REC-xmlschema-0-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-0-20041028>.
[W3CXSD] Walmsley, P. and D. Fallside, "XML Schema Part 0: Primer [W3CXSLT] Clark, J., "XSL Transformations (XSLT) Version 1.0",
Second Edition", World Wide Web Consortium World Wide Web Consortium Recommendation REC-xslt-
Recommendation REC-xmlschema-0-20041028, October 2004, 19991116, November 1999,
<http://www.w3.org/TR/2004/REC-xmlschema-0-20041028>. <http://www.w3.org/TR/1999/REC-xslt-19991116>.
[W3CXSLT] Clark, J., "XSL Transformations (XSLT) Version 1.0", World 6.2. Informative References
Wide Web Consortium Recommendation REC-xslt-19991116,
November 1999, [RCDML] Presuhn, R., Ed., "Requirements for a Configuration Data
<http://www.w3.org/TR/1999/REC-xslt-19991116>. Modeling Language", Work in Progress, February 2008.
Author's Address Author's Address
Phil Shafer Phil Shafer
Juniper Networks Juniper Networks
Email: phil@juniper.net EMail: phil@juniper.net
 End of changes. 89 change blocks. 
208 lines changed or deleted 200 lines changed or added

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