draft-ietf-netmod-arch-05.txt | draft-ietf-netmod-arch-06.txt | |||
---|---|---|---|---|
Network Working Group P. Shafer | Network Working Group P. Shafer | |||
Internet-Draft Juniper Networks | Internet-Draft Juniper Networks | |||
Intended status: Informational April 16, 2010 | Intended status: Informational June 16, 2010 | |||
Expires: October 18, 2010 | Expires: December 18, 2010 | |||
An NETCONF- and NETMOD-based Architecture for Network Management | An Architecture for Network Management using NETCONF and YANG | |||
draft-ietf-netmod-arch-05 | draft-ietf-netmod-arch-06 | |||
Abstract | Abstract | |||
NETCONF gives access to native capabilities of the devices within a | NETCONF gives access to native capabilities of the devices within a | |||
network, defining methods for manipulating configuration databases, | network, defining methods for manipulating configuration databases, | |||
retrieving operational data, and invoking specific operations. YANG | retrieving operational data, and invoking specific operations. YANG | |||
provides the means to define the content carried via NETCONF, both | provides the means to define the content carried via NETCONF, both | |||
data and operations. Using both technologies, standard modules can | data and operations. Using both technologies, standard modules can | |||
be defined to give interoperability and commonality to devices, while | be defined to give interoperability and commonality to devices, while | |||
still allowing devices to express their unique capabilities. | still allowing 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 to IETF in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF). Note that other groups may also distribute | |||
other groups may also distribute working documents as Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | This Internet-Draft will expire on December 18, 2010. | |||
http://www.ietf.org/ietf/1id-abstracts.txt. | ||||
The list of Internet-Draft Shadow Directories can be accessed at | ||||
http://www.ietf.org/shadow.html. | ||||
This Internet-Draft will expire on October 18, 2010. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2010 IETF Trust and the persons identified as the | Copyright (c) 2010 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 3, line 7 | skipping to change at page 3, line 7 | |||
modifications of such material outside the IETF Standards Process. | modifications of such material outside the IETF Standards Process. | |||
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 YANG . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2. Elements of YANG . . . . . . . . . . . . . . . . . . . . . . . 6 | 1.1. Origins of NETCONF and YANG . . . . . . . . . . . . . . . 4 | |||
2. Elements of the Architecture . . . . . . . . . . . . . . . . . 6 | ||||
2.1. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 2.1. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
2.2. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 2.1.1. NETCONF Transport Mappings . . . . . . . . . . . . . . 8 | |||
2.2.1. Constraints . . . . . . . . . . . . . . . . . . . . . 10 | 2.2. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
2.2.2. Flexibility . . . . . . . . . . . . . . . . . . . . . 11 | 2.2.1. Constraints . . . . . . . . . . . . . . . . . . . . . 11 | |||
2.2.3. Extensibility Model . . . . . . . . . . . . . . . . . 11 | 2.2.2. Flexibility . . . . . . . . . . . . . . . . . . . . . 12 | |||
2.3. YANG Technologies . . . . . . . . . . . . . . . . . . . . 13 | 2.2.3. Extensibility Model . . . . . . . . . . . . . . . . . 12 | |||
2.3.1. YIN . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 2.3. YANG Translations . . . . . . . . . . . . . . . . . . . . 13 | |||
2.3.2. DSDL (Relax NG) . . . . . . . . . . . . . . . . . . . 13 | 2.3.1. YIN . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
2.3.2. DSDL (Relax NG) . . . . . . . . . . . . . . . . . . . 14 | ||||
2.4. YANG Types . . . . . . . . . . . . . . . . . . . . . . . . 14 | 2.4. YANG Types . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
3. Working with YANG . . . . . . . . . . . . . . . . . . . . . . 15 | 2.5. IETF Guidelines . . . . . . . . . . . . . . . . . . . . . 15 | |||
3.1. Building YANG-based Solutions . . . . . . . . . . . . . . 15 | 3. Working with YANG . . . . . . . . . . . . . . . . . . . . . . 16 | |||
3.2. Addressing Operator Problems . . . . . . . . . . . . . . . 16 | 3.1. Building NETCONF- and YANG-based Solutions . . . . . . . . 16 | |||
3.3. Building YANG-based Solutions . . . . . . . . . . . . . . 18 | 3.2. Addressing Operator Requirements . . . . . . . . . . . . . 17 | |||
3.4. Modeler . . . . . . . . . . . . . . . . . . . . . . . . . 19 | 3.3. Roles in Building Solutions . . . . . . . . . . . . . . . 19 | |||
3.5. Reviewer . . . . . . . . . . . . . . . . . . . . . . . . . 19 | 3.3.1. Modeler . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
3.6. Device Developer . . . . . . . . . . . . . . . . . . . . . 19 | 3.3.2. Reviewer . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
3.6.1. Generic Content Support . . . . . . . . . . . . . . . 19 | 3.3.3. Device Developer . . . . . . . . . . . . . . . . . . . 20 | |||
3.6.2. XML "over the wire" Definitions . . . . . . . . . . . 20 | 3.3.4. Application Developer . . . . . . . . . . . . . . . . 21 | |||
3.7. Application Developer . . . . . . . . . . . . . . . . . . 20 | 4. Modeling Considerations . . . . . . . . . . . . . . . . . . . 24 | |||
3.7.1. Hard Coded . . . . . . . . . . . . . . . . . . . . . . 20 | 4.1. Default Values . . . . . . . . . . . . . . . . . . . . . . 24 | |||
3.7.2. Bottom Up . . . . . . . . . . . . . . . . . . . . . . 20 | 4.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
3.7.3. Top Down . . . . . . . . . . . . . . . . . . . . . . . 21 | 4.3. Data Distinctions . . . . . . . . . . . . . . . . . . . . 26 | |||
4. Modeling Considerations . . . . . . . . . . . . . . . . . . . 23 | 4.3.1. Background . . . . . . . . . . . . . . . . . . . . . . 26 | |||
4.1. Default Values . . . . . . . . . . . . . . . . . . . . . . 23 | 4.3.2. Definitions . . . . . . . . . . . . . . . . . . . . . 27 | |||
4.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . . 24 | 4.3.3. Implications . . . . . . . . . . . . . . . . . . . . . 28 | |||
4.3. Data Distinctions . . . . . . . . . . . . . . . . . . . . 24 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 30 | |||
4.3.1. Background . . . . . . . . . . . . . . . . . . . . . . 25 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 | |||
4.3.2. Definitions . . . . . . . . . . . . . . . . . . . . . 25 | 7. Normative References . . . . . . . . . . . . . . . . . . . . . 32 | |||
4.3.3. Implications . . . . . . . . . . . . . . . . . . . . . 27 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 28 | ||||
6. Normative References . . . . . . . . . . . . . . . . . . . . . 29 | ||||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30 | ||||
1. Origins of YANG | 1. Introduction | |||
1.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. | |||
skipping to change at page 4, line 33 | skipping to change at page 4, line 35 | |||
The output of this workshop was focused on current problems. The | The output of this workshop was focused on current problems. The | |||
operator's needs were reasonable and straight forward, including the | operator's needs were reasonable and straight forward, including the | |||
need for transactions, rollback, low implementation costs, and the | need for transactions, rollback, low implementation costs, and the | |||
ability to save and restore the device's configuration data. Many of | ability to save and restore the device's configuration data. Many of | |||
the observations give insight into the problems operators were having | the 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 NETCONF protocol was created. This protocol defines a simple | the Network Configuration (NETCONF) protocol was created. This | |||
mechanism where network management applications, acting as clients, | protocol defines a simple mechanism where network management | |||
can invoke operations on the devices, which act as servers. The | applications, acting as clients, can invoke operations on the | |||
NETCONF specification defines a small set of operations, but goes out | devices, which act as servers. The NETCONF specification defines a | |||
of its way to avoid making any requirements on the data carried in | small set of operations, but goes out of its way to avoid making any | |||
those operations, preferring to allow the protocol to carry any data. | requirements on the data carried in those operations, preferring to | |||
This "data model agnostic" approach allows data models to be defined | allow the protocol to carry any data. This "data model agnostic" | |||
independently. | 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 XSD and Relax NG were considered, but were rejected | languages such as XSD and Relax NG were considered, but were rejected | |||
because the problem domains have little natural overlap. Defining a | because the problem domains have little natural overlap. Defining a | |||
protocol which is encoded in XML is a distinct problem from defining | protocol which is encoded in XML is a distinct problem from defining | |||
an XML document. | an XML document. | |||
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 APPS 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 (expired | |||
I-D draft-presuhn-rcdml-03.txt). After discussing the available | I-D draft-presuhn-rcdml-03.txt). After discussing the available | |||
options at the CANMOD BoF at IETF71, the community wrote a charter | options at the CANMOD BoF at IETF71, the community wrote a charter | |||
for the NETMOD working group. An excellent description of this time | for the NETMOD working group. An excellent description of this time | |||
period is available at | period is available at | |||
http://www.mail-archive.com/ietf@ietf.org/msg37006.html | http://www.mail-archive.com/ietf@ietf.org/msg37006.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 ([RFCYANG]) 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 easily digestible by human readers and satisfies many of | a form that is easily digestible by human readers and satisfies many | |||
the issues raised in the IAB NM workshop. This brings NETCONF to a | of the issues raised in the IAB NM workshop. This brings NETCONF to | |||
point where is can be used to develop standards within the IETF. | a point where is can be used to develop standards within 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 | |||
their peer will expect them to behave. A client knows how to create | their peer will expect them to behave. A client knows how to create | |||
valid data for the server, and knows what data will be sent from the | valid data for the server, and knows what data will be sent from the | |||
server. A server knows the rules that govern the data and how it | server. A server knows the rules that govern the data and how it | |||
should behave. | should behave. | |||
skipping to change at page 6, line 5 | skipping to change at page 6, line 5 | |||
present in other model languages. New modules can augment the data | present in other model languages. New modules can augment the data | |||
hierarchies defined in other modules, seemlessly adding data at | hierarchies defined in other modules, seemlessly adding data at | |||
appropriate places in the existing data organization. YANG also | appropriate places in the existing data organization. YANG also | |||
allows new statements to be defined, allowing the language itself to | allows new statements to be defined, allowing the language itself to | |||
be expanded in a consistent way. | be expanded in a consistent way. | |||
This document presents an architecture for YANG, describing how YANG- | This document presents an architecture for YANG, describing how YANG- | |||
related technologies work and how solutions built on them can address | related technologies work and how solutions built on them can address | |||
the network management problem domain. | the network management problem domain. | |||
2. Elements of YANG | 2. Elements of the Architecture | |||
2.1. NETCONF | 2.1. NETCONF | |||
YANG is focused on creating data models for NETCONF, and any | ||||
understanding of the former must begin with the latter. | ||||
NETCONF defines an XML-based remote procedure call (RPC) mechanism | NETCONF defines an XML-based remote procedure call (RPC) mechanism | |||
that leverages the simplicity and availability of high-quality XML | that leverages the simplicity and availability of high-quality XML | |||
parsers. XML gives a rich, flexible, hierarchical, standard | parsers. XML gives a rich, flexible, hierarchical, standard | |||
representation of data that matches the needs of networking devices. | representation of data that matches the needs of networking devices. | |||
NETCONF carries configuration data and operations as requests and | NETCONF carries configuration data and operations as requests and | |||
replies using RPCs encoded in XML over a connection-oriented | replies using RPCs encoded in XML over a connection-oriented | |||
transport. | transport. | |||
XML's hierarchical data representation allows complex networking data | XML's hierarchical data representation allows complex networking data | |||
to be rendered in a natural way. For example, the following | to be rendered in a natural way. For example, the following | |||
skipping to change at page 7, line 40 | skipping to change at page 7, line 40 | |||
</interface> | </interface> | |||
<interface> | <interface> | |||
<name>ge-0/0/3.0</name> | <name>ge-0/0/3.0</name> | |||
<metric>140</metric> | <metric>140</metric> | |||
<dead-interval>120</dead-interval> | <dead-interval>120</dead-interval> | |||
</interface> | </interface> | |||
</area> | </area> | |||
</ospf> | </ospf> | |||
NETCONF includes mechanisms for controlling configuration datastores, | NETCONF includes mechanisms for controlling configuration datastores. | |||
fetching state data, and receiving notifications, and permits | Each datastore is a specific collection of configuration data that | |||
additional RPC methods. Configuration operations include the ability | can be used as source or target of the configuration-related | |||
to lock datastores to isolate one application from the actions of | operations. The device can indicate whether it has a distinct | |||
others, the ability to save and restore configuration data sets, and | "startup" configuration datastore, whether the current or "running" | |||
the ability to discover (via the <hello> message) the capabilities of | datastore is directly writable, or whether there is a "candidate" | |||
the device. | configuration datastore where configuration changes can be made that | |||
will not affect the device until a "commit-configuration" operation | ||||
is invoked. | ||||
More information about NETCONF can be found in [RFC4741]. | NETCONF defined operations that are invoked as RPCs from the client | |||
(the application) to the server (running on the device). The | ||||
following table lists these operations: | ||||
+----------------------+--------------------------------------------+ | ||||
| Operation | Description | | ||||
+----------------------+--------------------------------------------+ | ||||
| commit-configuration | Commits the "candidate" configuration to | | ||||
| | "running" | | ||||
| copy-configuration | Copy one configuration datastore to | | ||||
| | another | | ||||
| edit-configuration | Change the contents of a configuration | | ||||
| | database | | ||||
| get-configuration | Retrieve all or part of a configuration | | ||||
| | datastore | | ||||
| lock-configuration | Prevent changes to a datastore from | | ||||
| | another party | | ||||
| unlock-configuration | Release a lock on a datastore | | ||||
+----------------------+--------------------------------------------+ | ||||
NETCONF's "capability" mechanism allows the device to announce the | ||||
set of capabilities that the device supports, including protocol | ||||
operations, datastores, data models, and other abilities. These are | ||||
announced during session establishment as part of the <hello> | ||||
message. A client can inspect the hello message to determine what | ||||
the device is capable of and how to interact with the device to | ||||
perform the desired tasks. | ||||
NETCONF also defines a means of sending asynchronous notifications | ||||
from the server to the client, described in [RFC5277]. | ||||
In addition, NETCONF can fetch state data, receive notifications, and | ||||
invoke additional RPC methods defined as part of a capability. | ||||
Complete information about NETCONF can be found in [RFC4741]. | ||||
2.1.1. NETCONF Transport Mappings | ||||
NETCONF can run over any transport protocol that meets the | ||||
requirements defined in RFC4741, including | ||||
o connection-oriented operation | ||||
o authentication | ||||
o integrity | ||||
o confidentiality | ||||
[RFC4742] defines an mapping for the SSH protocol, which is the | ||||
mandatory transport protocol. Others include SOAP ([RFC4743]), BEEP | ||||
([RFC4744]), and 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 model 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 instances and leaf data values. | 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 | |||
list area { // Declare a list of "area" nodes | list area { // Declare a list of "area" nodes | |||
key name; // The key "name" identifies list members | key name; // The key "name" identifies list members | |||
leaf name { | leaf name { | |||
skipping to change at page 10, line 14 | skipping to change at page 11, line 14 | |||
+--------------+----------------------------------------------------+ | +--------------+----------------------------------------------------+ | |||
| 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 are optional | | |||
| grouping | Groups data definitions into reusable sets | | | grouping | Groups data definitions into reusable sets | | |||
| key | Defines the keys 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 as multiple times | | | leaf-list | A leaf node that can appear multiple times | | |||
| list | A layer of hierarchy that can appear multiple | | | list | A hierarchy that can appear multiple times | | |||
| | times | | | notification | Defines notification | | |||
| notification | Define an notification | | | rpc | Defines input and output parameters for an RPC | | |||
| rpc | Define an RPC operation | | | | operation | | |||
| typedef | Define a new type | | | typedef | Defines a new type | | |||
| uses | Incorporate the contents of a "grouping" | | | uses | Incorporates the contents of a "grouping" | | |||
+--------------+----------------------------------------------------+ | +--------------+----------------------------------------------------+ | |||
2.2.1. Constraints | 2.2.1. Constraints | |||
YANG allows the modeler to add constraints to the data model to | YANG allows the modeler to add constraints to the data model to | |||
prevent impossible or illogical data. These constraints give clients | prevent impossible or illogical data. These constraints give clients | |||
information about the data being sent from the device, and also allow | information about the data being sent from the device, and also allow | |||
the client to know as much as possible about the data the device will | the client to know as much as possible about the data the device will | |||
accept, so the client can send correct data. These constraints apply | accept, so the client can send correct data. These constraints apply | |||
to configuration data, but can also be used for rpc and notification | to configuration data, but can also be used for rpc and notification | |||
skipping to change at page 11, line 24 | skipping to change at page 12, line 24 | |||
"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"; | |||
} | } | |||
} | } | |||
A choice gives a set of mutually exclusive nodes, so a valid | The "choice" statement lists a set of mutually exclusive nodes, so a | |||
configuration can choose any one node (or case). The "feature" | valid configuration can choose any one node (or case). The "feature" | |||
allows the modeler to identify parts of the model which can be | statement allows the modeler to identify parts of the model which can | |||
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" give some flexibility to the device, allowing it to | The "deviation" statement allows the device, to indicate parts of a | |||
define parts of a YANG module which the device does not faithfully | YANG module which the device does not faithfully implement. While | |||
implement. While devices are encouraged to fully abide according to | devices are encouraged to fully abide according to the contract | |||
the contract presented in the YANG module, real world situations may | presented in the YANG module, real world situations may force the | |||
force the device to break the contract. Deviations give a means of | device to break the contract. Deviations give a means of declaring | |||
declaring this problem, rather than ignoring it. | this limitation, rather than leaving it to be discovered via run-time | |||
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 | |||
module, introducing elements from that module's namespace into the | module, introducing elements from that module's namespace into the | |||
first module's hierarchy. | first module's hierarchy. | |||
Since one module can augment another module's definition, hierarchies | Since one module can augment another module's definition, hierarchies | |||
of definitions are allowed to grow, as definitions from multiple | of definitions are allowed to grow, as definitions from multiple | |||
sources are added to the base hierarchy. These augmentations are | sources are added to the base hierarchy. These augmentations are | |||
qualified using the namespace of the source module, helping to avoid | qualified using the namespace of the source module, helping to avoid | |||
issues with name conflicts as the modules change over time. | issues with name conflicts as the modules change over time. | |||
For example, if the above OSPF configuration were the standard, a | For example, if the above OSPF configuration were the standard, a | |||
vendor module may augment this with vendor-specific extensions. | vendor module may augment this with vendor-specific extensions. | |||
module vendorx-ospf { | module vendorx-ospf { | |||
namespace http://vendorx.example.com/ospf; | namespace "http://vendorx.example.com/ospf"; | |||
prefix vendorx; | prefix vendorx; | |||
import example-ospf { | import example-ospf { | |||
prefix ospf; | prefix ospf; | |||
} | } | |||
augment /ospf:ospf/ospf:area/ospf:interfaces { | augment /ospf:ospf/ospf:area/ospf:interfaces { | |||
leaf no-neighbor-down-notification { | leaf no-neighbor-down-notification { | |||
type empty; | type empty; | |||
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: | |||
<protocols xmlns="http://example.org/netconf/protocols" | <ospf xmlns="http://example.org/netconf/ospf"> | |||
xmlns:vendorx="http://vendorx.example.com/ospf"> | ||||
<ospf xmlns="http://example.org/netconf/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> | |||
</area> | </area> | |||
</ospf> | </ospf> | |||
</protocols> | ||||
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 augmentated data. | hierarchy for that area, complete with any augmentated data. | |||
2.3. YANG Technologies | 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 | |||
[RFCYANG], 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 | |||
skipping to change at page 13, line 41 | skipping to change at page 14, line 35 | |||
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 ([DSDL]). | Description Languages ([RFCYANGDSDL]). | |||
DSDL is considered to be the best choice for the given purpose | DSDL is considered to be the best choice for the given purpose | |||
because it addresses not only grammar and datatypes of XML documents | because it addresses not only grammar and datatypes of XML documents | |||
but also semantic constraints and rules for modifying information set | but also semantic constraints and rules for modifying information set | |||
of the document. | 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. | |||
skipping to change at page 15, line 5 | skipping to change at page 15, line 9 | |||
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 [RFCYANGTYPES]. | |||
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 | ||||
A set of additional guidelines are defined that indicate desirable | ||||
usage for authors and reviewers of standards track specifications | ||||
containing YANG data model modules ([RFCYANGUSAGE]). These | ||||
guidelines should be used as a basis for reviews of other YANG data | ||||
model documents. | ||||
3. Working with YANG | 3. Working with YANG | |||
3.1. Building 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 16, line 18 | skipping to change at page 17, line 18 | |||
o [C] and [S] exchange <hello> messages containing the list of | o [C] and [S] exchange <hello> messages containing the list of | |||
capabilities supported by each side, allowing [C] to learn the | capabilities supported by each side, allowing [C] to learn the | |||
modules supported by [S] | modules supported by [S] | |||
o [C] builds and sends an operation defined in the YANG module, | o [C] builds and sends an operation defined in the YANG module, | |||
encoded in XML, within NETCONF's <rpc> element | encoded in XML, within NETCONF's <rpc> element | |||
o [S] receives and parses the <rpc> element | o [S] receives and parses the <rpc> element | |||
o [S] verifies the contents of the request against the data defined | o [S] verifies the contents of the request against the data model | |||
in the YANG module | defined in the YANG module | |||
o [S] performs the requested operation, possibly changing the | o [S] performs the requested operation, possibly changing the | |||
configuration database | configuration database | |||
o [S] builds the response, containing the response, any requested | o [S] builds the response, containing the response, any requested | |||
data, and any errors | data, and any errors | |||
o [S] sends the response, encoded in XML, within NETCONF's | o [S] sends the response, encoded in XML, within NETCONF's | |||
<rpc-reply> element | <rpc-reply> element | |||
o [C] receives and parses the <rpc-reply> element | o [C] receives and parses the <rpc-reply> element | |||
o [C] inspects the response and processes it as needed | o [C] inspects the response and processes it as needed | |||
Note that there is no requirement for the client or server to process | Note that there is no requirement for the client or server to process | |||
the YANG modules in this way. The server may hard code the contents | the YANG modules in this way. The server may hard code the contents | |||
of the data model, rather than handle the content via a generic | of the data model, rather than handle the content via a generic | |||
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 and | simple shell script that stuffs arguments into an XML payload | |||
sends it to the server. | template and sends it to the server. | |||
3.2. Addressing Operator Problems | 3.2. Addressing Operator Requirements | |||
YANG addresses many of the issues raised in the IAB NM workshop. | YANG addresses many of the issues raised in the IAB NM 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 Operational data: YANG clearly divides | o Configuration and state data: YANG clearly divides configuration | |||
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 a the delta needed to change between two configuration | generate the delta needed to change between two configuration data | |||
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 performed for a specific YANG | |||
module. | module. | |||
o Network-wide configuration: A standard YANG module can be | o Network-wide configuration: NETCONF supports robust network-wide | |||
implemented in all devices, giving a common view of configuration | configuration transactions via the confirmed-commit capability. | |||
data. | ||||
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 | |||
methods. A client can choose to invoke the rpc or to access any | operations. A client can choose to invoke the RPC operation or to | |||
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 CLI/Expect access. | avoids the need to resort to the command line interface (CLI) | |||
using tools such as Expect. | ||||
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 should allow simpler | o Implementation difficulty: YANG's flexibility enables modules that | |||
modules that can be more easily implemented. Adding "features" | can be more easily implemented. Adding "features" and replacing | |||
and replacing "third normal form" with a natural data hierarchy | "third normal form" with a natural data hierarchy should reduce | |||
should reduce complexity. | complexity. | |||
o Simple DDL: YANG has sufficient power to be usable in other | o Simple data modeling language: YANG has sufficient power to be | |||
situations. In particular, on-box API and native CLI can be | usable in other situations. In particular, on-box API and native | |||
integrated to achieve simplification of the infrastructure. | CLI can be integrated to achieve simplification of the | |||
infrastructure. | ||||
o Internationalization: YANG uses UTF-8 data. | o Internationalization: YANG uses UTF-8 encoded unicode characters. | |||
o Event correlation: YANG integrated rpc, notification, operational, | o Event correlation: YANG integrates RPC operations, notification, | |||
and configuration data, allowing the data to make internal | configuration and state data, enabling internal references. For | |||
references. For example, a field in a notification can be tagged | example, a field in a notification can be tagged as pointing to a | |||
as pointing to a BGP peer, and the client application can easily | BGP peer, and the client application can easily find that peer in | |||
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, XQuery, and XSLT. | like XPath, XQuery, and XSLT. | |||
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 as an ssh service, allowing secure | o Security: NETCONF runs over transport protocols secured by SSH or | |||
communications and authentication using well-trusted technology. | TLS, allowing secure communications and authentication using well- | |||
This uses the existing key and credential management | trusted technology. The secure transport can use existing key and | |||
infrastructure, reducing deployment costs. | credential management infrastructure, reducing deployment costs. | |||
o Reliable: NETCONF and YANG are solid and reliable technologies. | o Reliable: NETCONF and YANG are solid and reliable technologies. | |||
NETCONF is connection based, and includes automatic recovery | NETCONF is connection based, and includes automatic recovery | |||
mechanisms when the connection is lost. | mechanisms when the connection is lost. | |||
o Delta friendly: YANG-based models support operations that are | o Delta friendly: YANG-based models support operations that are | |||
delta friendly. Add, change, insert, and delete operations are | delta friendly. Add, change, insert, and delete operations are | |||
all well defined. | all well defined. | |||
o Method-oriented: YANG allows new NETCONF RPCs to be defined, | o Method-oriented: YANG allows new RPC operations to be defined, | |||
including an operation name, which is essentially a method. The | including an operation name, which is essentially a method. The | |||
RPC's input and output data are also defined in the YANG module. | input and output parameters of the RPC operations are also defined | |||
in the YANG module. | ||||
3.3. Building YANG-based Solutions | 3.3. Roles in Building Solutions | |||
Building YANG-based solutions requires interacting with many distinct | Building NETCONF- and YANG-based solutions requires interacting with | |||
groups. Modelers must understand how to build useful models that | many distinct groups. Modelers must understand how to build useful | |||
give structure and meaning to data while maximizing the flexibility | models that give structure and meaning to data while maximizing the | |||
of that data to "future proof" their work. Reviewers need to quickly | flexibility of that data to "future proof" their work. Reviewers | |||
determine if that structure is accurate. Device developers need to | need to quickly determine if that structure is accurate. Device | |||
code that data model into their devices, and application developers | developers need to code that data model into their devices, and | |||
need to code their applications to take advantage of that data model. | application developers need to code their applications to take | |||
There are a variety of strategies for performing each piece of this | advantage of that data model. There are a variety of strategies for | |||
work. This section discusses some of those strategies. | performing each piece of this work. This section discusses some of | |||
those strategies. | ||||
3.4. Modeler | 3.3.1. Modeler | |||
The modeler's role constructing a model based on their in-depth | The modeler defines a data model based on their in-depth knowledge of | |||
knowledge of the problem domain being modeled. This model should be | the problem domain being modeled. This model should be as simple as | |||
as simple as possible, but should balance complexity with | possible, but should balance complexity with expressiveness. The | |||
expressiveness. The organization of the model should target not only | organization of the model should target not only the current model, | |||
the current model, but should allow for extensibility from other | but should allow for extensibility from other modules and for | |||
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.5. Reviewer | 3.3.2. Reviewer | |||
The reviewer role is perhaps the more 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. | |||
In addition, reviewers can encode review policies in scripts, such as | 3.3.3. Device Developer | |||
XSLT. A policy that leaf names can't have underscores can be coded | ||||
as: | ||||
<xsl:template match="leaf[contains(@name, '_')]"> | ||||
Error: leaf name contains underscore | ||||
</xsl:template> | ||||
3.6. 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, absorbs the zen of the model, | The developer reads the YANG models and writes code that supports the | |||
and writes code that supports the model. The model describes the | model. The model describes the data hierarchy and associated | |||
data hierarchy and associated constraints, and the description and | constraints, and the description and reference material helps the | |||
reference material helps the developer understand how to transform | developer understand how to transform the models view into the | |||
the models view into the device's native implementation. | device's native implementation. | |||
3.6.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 deserializers 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.6.2. XML "over the wire" Definitions | 3.3.3.2. XML "over the wire" Definitions | |||
The YANG module dictates the XML encoding sent "over the wire", | The YANG module dictates the XML encoding sent "over the wire", | |||
though actual transmission should be encrypted so as not to appear as | though actual transmission should be encrypted so as not to appear as | |||
readable text on the physical media. The rules that define the | readable text on the physical media. The rules that define the | |||
encoding are fixed, so the YANG module can be used to ascertain | encoding are fixed, so the YANG module can be used to ascertain | |||
whether a specific NETCONF payload is obeying the rules. | whether a specific NETCONF payload is obeying the rules. | |||
3.7. Application Developer | 3.3.4. Application Developer | |||
The YANG module tells the application developer what data can be | The YANG module tells the application developer what data can be | |||
modeled. Developers can inspect the modules and take one of three | modeled. Developers can inspect the modules and take one of three | |||
distinct views. In this section, we will consider them and the | distinct views. In this section, we will consider them and the | |||
impact of YANG on their design. In the real world, most applications | impact of YANG on their design. In the real world, most applications | |||
are a mixture of these approaches. | are a mixture of these approaches. | |||
3.7.1. Hard Coded | 3.3.4.1. Hard Coded | |||
An application can be coded against the specific, well-known contents | An application can be coded against the specific, well-known contents | |||
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 is overwhelmed by the ease of | |||
hard coding direct knowledge into the application. | hard coding direct knowledge into the application. | |||
3.7.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 straight- | |||
forward visualization where elements of the YANG hierarchy are | forward visualization where elements of the YANG hierarchy are | |||
depicted in a hierarchy of folders or GUI panels. Clicking on a line | depicted in a hierarchy of folders or GUI panels. Clicking on a line | |||
expands to the contents of the matching XML hierarchy. | expands to 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 allows 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.7.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 which 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 | |||
skipping to change at page 22, line 5 | skipping to change at page 22, line 28 | |||
For example, an application could be written that models VPNs in a | For example, an application could be written that models VPNs in a | |||
network-oriented view. The application would need to transform these | network-oriented view. The application would need to transform these | |||
high-level VPN definitions into the configuration data that would be | high-level VPN definitions into the configuration data that would be | |||
handed to any particular device within a VPN. | handed to any particular device within a VPN. | |||
Even in this approach, YANG is useful since it can be used to model | Even in this approach, YANG is useful since it can be used to model | |||
the VPN. For example, the following VPN straw-man models a list of | the VPN. For example, the following VPN straw-man models a list of | |||
VPNs, each with a protocol, a topology, a list of member interfaces, | VPNs, each with a protocol, a topology, a list of member interfaces, | |||
and a list of classifiers. | and a list of classifiers. | |||
list ietf-bgpvpn { | list example-bgpvpn { | |||
key name; | key name; | |||
leaf name { ... } | leaf name { ... } | |||
leaf protocol { | leaf protocol { | |||
type enumeration { | type enumeration { | |||
enum bgpvpn; | enum bgpvpn; | |||
enum l2vpn; | enum l2vpn; | |||
} | } | |||
} | } | |||
leaf topology { | leaf topology { | |||
type enumeration { | type enumeration { | |||
skipping to change at page 22, line 32 | skipping to change at page 23, 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 uses either a | configuration for those VPNs to individual devices using either a | |||
standard device model (e.g. ietf-bgpvpn.yang) or by transforming that | standard device model (e.g. example-bgpvpn.yang) or by transforming | |||
standard device content into some proprietary format for devices that | that standard device content into some proprietary format for devices | |||
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 | |||
The concept of default values is simple, but their details, | The concept of default values is simple, but their details, | |||
representation, and interaction with configuration data can be | representation, and interaction with configuration data can be | |||
difficult issues. NETCONF leaves default values as a data model | difficult issues. NETCONF leaves default values as a data model | |||
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 is if the leaf was present in | device "MUST operationally behave as if the leaf was present in the | |||
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 is given as | how the device should be configured. If a data value that is given | |||
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 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 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 database. | values, implicitly removing them from the configuration database. | |||
The act of setting a leaf to it's default value effectively deletes | The act of setting a leaf to it's 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 | |||
skipping to change at page 24, line 11 | skipping to change at page 25, line 11 | |||
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 | |||
four types of behavior in modeled device: | five issues with models and devices: | |||
o [strict compliance] behavior that follow the model completely | o usefulness | |||
o [modeled deviations] behavior that follows within deviations | o compliance | |||
allowed by the model | ||||
o [allowable deviations] behavior that falls outside the model, but | o flexibility | |||
can still be handled | ||||
o [unacceptable deviations] behavior that is not at all consistent | o extensibility | |||
with the model | ||||
Once the model is published, an implementer may decide to make a | o deviations | |||
particular data model node configurable, where the standard model | ||||
describes it a state data. The implementation reports the value | For a model to be interesting, it must be useful, solving a problem | |||
normally and may declare a deviation that this device behaves in a | in a more direct or more powerful way than can be accomplished | |||
different manner than the standard. Applications capable of | without the model. The model should maximize the usefulness of the | |||
discovering this deviation can make allowances, but applications that | model with in the problem domain. | |||
do not discover the deviation can continue treating the | ||||
implementation as if it were compliant. | Modelers should build models that maximize the number of devices that | |||
can faithfully implement the model. If the model is drawn too | ||||
narrowly, or includes too many assumptions about the device, then the | ||||
difficulty and cost of accurately implementing the model will lead to | ||||
low quality implementations, interoperability issues, and will reduce | ||||
the value of the model. | ||||
Modelers can use the "feature" statement in their models to give the | ||||
device some flexibility by partitioning their model and allowing the | ||||
device to indicate which portions of the model are implemented on the | ||||
device. For example, if the model includes some a "logging" feature | ||||
, a device with no storage facilities for the log can tell the client | ||||
that it does not support this feature of the model. | ||||
Models can be extended via the "augment" statement, and the modeler | ||||
should consider how their model is likely to be extended. These | ||||
augmentations can be defined by vendors, applications, or standards | ||||
bodies. | ||||
Deviations are a means of allowing the devices to indicate where its | ||||
implementation is not in full compliance with the model. For | ||||
example, once a model is published, an implementer may decide to make | ||||
a particular node configurable, where the standard model describes it | ||||
as state data. The implementation reports the value normally and may | ||||
declare a deviation that this device behaves in a different manner | ||||
than the standard. Applications capable of discovering this | ||||
deviation can make allowances, but applications that do not discover | ||||
the deviation can continue treating the implementation as if it were | ||||
compliant. | ||||
Rarely, implementations may make decisions that prevent compliance | Rarely, implementations may make decisions that prevent compliance | |||
with the standard. Such occasions are regrettable, but they remain a | with the standard. Such occasions are regrettable, but they remain a | |||
part of reality, and modelers and application writers ignore them at | part of reality, and modelers and application writers ignore them at | |||
their own risk. An implementation that emits an integer leaf as | their own risk. An implementation that emits an integer leaf as | |||
"cow" would be difficult to manage, but applications must expect to | "cow" would be difficult to manage, but applications should expect to | |||
encounter such misbehaving devices in the field. | encounter such misbehaving devices in the field. | |||
Despite this, both client and server should view the YANG module as a | Despite this, both client and server should view the YANG module as a | |||
contract, with both sides agreeing to abide by the terms. The | contract, with both sides agreeing to abide by the terms. The | |||
modeler should be explicit about the terms of such a contract, and | modeler should be explicit about the terms of such a contract, and | |||
both client and server implementations should strive to faithfully | both client and server implementations should strive to faithfully | |||
and accurately implement the data model described in the YANG module. | and accurately implement the data model described in the YANG module. | |||
4.3. Data Distinctions | 4.3. Data Distinctions | |||
skipping to change at page 25, line 45 | skipping to change at page 27, line 25 | |||
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. [RFC 4741] | 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 behaviour | |||
similar to configuration data. In contrast to configuration data, | similar 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. | |||
skipping to change at page 26, line 22 | skipping to change at page 27, line 50 | |||
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 | |||
Network interfaces usually comes with a large number of attributes | Network interfaces usually come with a large number of attributes | |||
that are specific to the interface type and in some cases specific to | that are specific to the interface type and in some cases specific to | |||
the cable plugged into an interface. Examples are the maximum | the cable plugged into an interface. Examples are the maximum | |||
transmission unit of an interface or the speed detected by an | transmission unit of an interface or the speed detected by an | |||
Ethernet interface. | Ethernet interface. | |||
In many deployments, systems use the interface attributes detected | In many deployments, systems use the interface attributes detected | |||
when an interface is initialized. As such, these attributes | when an interface is initialized. As such, these attributes | |||
constitute operational state. However, there are usually provisions | constitute operational state. However, there are usually provisions | |||
to overwrite the discovered attributes with static configuration | to overwrite the discovered attributes with static configuration | |||
data, like for example configuring the interface MTU to use a | data, like for example configuring the interface MTU to use a | |||
skipping to change at page 27, line 16 | skipping to change at page 28, line 44 | |||
4.3.3. Implications | 4.3.3. Implications | |||
The primary focus of YANG is configuration data. There is no single | The primary focus of YANG is configuration data. There is no single | |||
mechanism defined for the separation of operational state data and | mechanism defined for the separation of operational state data and | |||
statistics since NETCONF treats them both as state data. This | statistics since NETCONF treats them both as state data. This | |||
section describes several different options for addressing this | section describes several different options for addressing this | |||
issue. | issue. | |||
4.3.3.1. Data Models | 4.3.3.1. Data Models | |||
The first option is to have data models that provide explicitly | The first option is to have data models that explicitly differentiate | |||
differentiate between configuration data and operational state data. | between configuration data and operational state data. This leads to | |||
This leads to duplication of data structures and might not scale well | duplication of data structures and might not scale well from a | |||
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). | |||
skipping to change at page 28, line 7 | skipping to change at page 30, line 7 | |||
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 behaviour of the box instead of its static and | |||
explicit configuration state. | explicit configuration state. | |||
5. Security Considerations | 5. Security Considerations | |||
This document discusses data modeling using YANG, and has no security | This document discusses an architecture for network management using | |||
impact on the Internet. | NETCONF and YANG. It has no security impact on the Internet. | |||
6. Normative References | 6. IANA Considerations | |||
[DSDL] International Organization for Standardization, "DSDL Part | This document has no actions for IANA. | |||
0 - Overview", ISO DSDL, December 2001. | ||||
7. Normative References | ||||
[RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network | [RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network | |||
Management Workshop", RFC 3535, May 2003. | Management Workshop", RFC 3535, May 2003. | |||
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, | [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, | |||
December 2006. | December 2006. | |||
[RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF | ||||
Configuration Protocol over Secure SHell (SSH)", RFC 4742, | ||||
December 2006. | ||||
[RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access | ||||
Protocol (SOAP)", RFC 4743, December 2006. | ||||
[RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol over | ||||
the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744, | ||||
December 2006. | ||||
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event | ||||
Notifications", RFC 5277, July 2008. | ||||
[RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", | ||||
RFC 5539, May 2009. | ||||
[RFCWITHDEFAULTS] | [RFCWITHDEFAULTS] | |||
Bierman, A. and B. Lengyel, "With-defaults capability for | Bierman, A. and B. Lengyel, "With-defaults capability for | |||
NETCONF", draft-ietf-netconf-with-defaults-05.txt (work in | NETCONF", draft-ietf-netconf-with-defaults-09.txt (work in | |||
progress). | progress). | |||
[RFCYANG] Bjorklund, M., Ed., "YANG - A data modeling language for | [RFCYANG] Bjorklund, M., Ed., "YANG - A data modeling language for | |||
NETCONF", draft-ietf-netmod-yang-11 (work in progress). | the Network Configuration Protocol (NETCONF)", | |||
draft-ietf-netmod-yang-13 (work in progress). | ||||
[RFCYANGDSDL] | ||||
Lhotka, L., Mahy, R., and S. Chishom, "Mapping YANG to | ||||
Document Schema Definition Languages and Validating | ||||
NETCONF Content", draft-ietf-netmod-dsdl-map-05 (work in | ||||
progress). | ||||
[RFCYANGTYPES] | [RFCYANGTYPES] | |||
Schoenwaelder, J., Ed., "Common YANG Data Types", | Schoenwaelder, J., "Common YANG Data Types", | |||
draft-ietf-netmod-yang-types-07.txt (work in progress). | draft-ietf-netmod-yang-types-09.txt (work in progress). | |||
[RFCYANGUSAGE] | ||||
Bierman, A., "Guidelines for Authors and Reviewers of YANG | ||||
Data Model Documents", draft-ietf-netmod-yang-usage-05.txt | ||||
(work in progress). | ||||
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. 82 change blocks. | ||||
226 lines changed or deleted | 326 lines changed or added | |||
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |