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/