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/ |