draft-ietf-netmod-arch-04.txt   draft-ietf-netmod-arch-05.txt 
Network Working Group P. Shafer Network Working Group P. Shafer
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Informational March 8, 2010 Intended status: Informational April 16, 2010
Expires: September 9, 2010 Expires: October 18, 2010
An NETCONF- and NETMOD-based Architecture for Network Management An NETCONF- and NETMOD-based Architecture for Network Management
draft-ietf-netmod-arch-04 draft-ietf-netmod-arch-05
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.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 9, 2010. 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 19 skipping to change at page 3, line 19
2.1. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Constraints . . . . . . . . . . . . . . . . . . . . . 10 2.2.1. Constraints . . . . . . . . . . . . . . . . . . . . . 10
2.2.2. Flexibility . . . . . . . . . . . . . . . . . . . . . 11 2.2.2. Flexibility . . . . . . . . . . . . . . . . . . . . . 11
2.2.3. Extensibility Model . . . . . . . . . . . . . . . . . 11 2.2.3. Extensibility Model . . . . . . . . . . . . . . . . . 11
2.3. YANG Technologies . . . . . . . . . . . . . . . . . . . . 13 2.3. YANG Technologies . . . . . . . . . . . . . . . . . . . . 13
2.3.1. YIN . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.1. YIN . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2. DSDL (Relax NG) . . . . . . . . . . . . . . . . . . . 13 2.3.2. DSDL (Relax NG) . . . . . . . . . . . . . . . . . . . 13
2.4. YANG Types . . . . . . . . . . . . . . . . . . . . . . . . 14 2.4. YANG Types . . . . . . . . . . . . . . . . . . . . . . . . 14
3. Working with YANG . . . . . . . . . . . . . . . . . . . . . . 15 3. Working with YANG . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Addressing Operator Problems . . . . . . . . . . . . . . . 15 3.1. Building YANG-based Solutions . . . . . . . . . . . . . . 15
3.2. Building YANG-based Solutions . . . . . . . . . . . . . . 17 3.2. Addressing Operator Problems . . . . . . . . . . . . . . . 16
3.3. Modeler . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.3. Building YANG-based Solutions . . . . . . . . . . . . . . 18
3.4. Reviewer . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.4. Modeler . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5. Device Developer . . . . . . . . . . . . . . . . . . . . . 17 3.5. Reviewer . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5.1. Generic Content Support . . . . . . . . . . . . . . . 17 3.6. Device Developer . . . . . . . . . . . . . . . . . . . . . 19
3.5.2. XML "over the wire" Definitions . . . . . . . . . . . 18 3.6.1. Generic Content Support . . . . . . . . . . . . . . . 19
3.6. Application Developer . . . . . . . . . . . . . . . . . . 18 3.6.2. XML "over the wire" Definitions . . . . . . . . . . . 20
3.6.1. Hard Coded . . . . . . . . . . . . . . . . . . . . . . 18 3.7. Application Developer . . . . . . . . . . . . . . . . . . 20
3.6.2. Bottom Up . . . . . . . . . . . . . . . . . . . . . . 18 3.7.1. Hard Coded . . . . . . . . . . . . . . . . . . . . . . 20
3.6.3. Top Down . . . . . . . . . . . . . . . . . . . . . . . 19 3.7.2. Bottom Up . . . . . . . . . . . . . . . . . . . . . . 20
4. Modeling Considerations . . . . . . . . . . . . . . . . . . . 21 3.7.3. Top Down . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Default Values . . . . . . . . . . . . . . . . . . . . . . 21 4. Modeling Considerations . . . . . . . . . . . . . . . . . . . 23
4.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . . 21 4.1. Default Values . . . . . . . . . . . . . . . . . . . . . . 23
4.3. Data Distinctions . . . . . . . . . . . . . . . . . . . . 22 4.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.1. Background . . . . . . . . . . . . . . . . . . . . . . 22 4.3. Data Distinctions . . . . . . . . . . . . . . . . . . . . 24
4.3.2. Definitions . . . . . . . . . . . . . . . . . . . . . 22 4.3.1. Background . . . . . . . . . . . . . . . . . . . . . . 25
4.3.3. Implications . . . . . . . . . . . . . . . . . . . . . 24 4.3.2. Definitions . . . . . . . . . . . . . . . . . . . . . 25
5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 4.3.3. Implications . . . . . . . . . . . . . . . . . . . . . 27
6. Normative References . . . . . . . . . . . . . . . . . . . . . 26 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27 6. Normative References . . . . . . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Origins of YANG 1. Origins of 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
skipping to change at page 4, line 34 skipping to change at page 4, line 34
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 NETCONF protocol was created. This protocol defines a simple
RPC-based mechanism where network management applications, acting as mechanism where network management applications, acting as clients,
clients, can invoke operations on the devices, which act as servers. can invoke operations on the devices, which act as servers. The
The NETCONF specification defines a small set of operations, but goes NETCONF specification defines a small set of operations, but goes out
out of its way to avoid making any requirements on the data carried of its way to avoid making any requirements on the data carried in
in those operations, preferring to allow the protocol to carry any those operations, preferring to allow the protocol to carry any data.
data. This "data model agnostic" approach allows data models to be This "data model agnostic" approach allows data models to be defined
defined independently. 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 an because the problem domains have little natural overlap. Defining a
RPC which is encoded in XML is a distinct problem from defining an protocol which is encoded in XML is a distinct problem from defining
XML document. an XML document.
In early 2005, the NETMOD working group embraced YANG ([RFCYANG]) as In 2007 and 2008, the issue of a data modeling language for NETCONF
a means for defining data models for NETCONF, allowing both standard was discussed in the OPS and APPS areas of IETF 70 and 71, and a
and proprietary data models to be published in a form that easily design team was tasked with creating a requirements document (expired
digestible by human readers and satisfies many of the issues raised I-D draft-presuhn-rcdml-03.txt). After discussing the available
in the IAB NM workshop. This brings NETCONF to a point where is can options at the CANMOD BoF at IETF71, the community wrote a charter
be used to develop standards within the IETF. for the NETMOD working group. An excellent description of this time
period is available at
http://www.mail-archive.com/ietf@ietf.org/msg37006.html
In 2008 and 2009, the NETMOD working group produced a specification
for YANG ([RFCYANG]) as a means for defining data models for NETCONF,
allowing both standard and proprietary data models to be published in
a form that easily digestible by human readers and satisfies many of
the issues raised in the IAB NM workshop. This brings NETCONF to 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 12 skipping to change at page 6, line 12
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 YANG
2.1. NETCONF 2.1. NETCONF
YANG is focused on creating data models for NETCONF, and any YANG is focused on creating data models for NETCONF, and any
understanding of the former must begin with the latter. understanding of the former must begin with the latter.
NETCONF defines an XML-based RPC mechanism that leverages the NETCONF defines an XML-based remote procedure call (RPC) mechanism
simplicity and availability of high-quality XML parsers. XML gives a that leverages the simplicity and availability of high-quality XML
rich, flexible, hierarchical, standard representation of data that parsers. XML gives a rich, flexible, hierarchical, standard
matches the needs of networking devices. NETCONF carries representation of data that matches the needs of networking devices.
configuration data and operations encoded in XML using an RPC NETCONF carries configuration data and operations as requests and
mechanism over a connection-oriented transport. replies using RPCs encoded in XML over a connection-oriented
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
configuration places interfaces in OSPF areas. The <ospf> element configuration places interfaces in OSPF areas. The <ospf> element
contains a list of <area> elements, each of which contain a list of contains a list of <area> elements, each of which contain a list of
<interface> elements. The <name> element identifies the specific <interface> elements. The <name> element identifies the specific
area or interface. Additional configuration for each area or area or interface. Additional configuration for each area or
interface appears directly inside the appropriate element. interface appears directly inside the appropriate element.
<ospf xmlns="http://example.org/netconf/ospf"> <ospf xmlns="http://example.org/netconf/ospf">
skipping to change at page 9, line 26 skipping to change at page 9, line 26
leaf name { leaf name {
type nett:area-id; type nett:area-id;
} }
list interface { list interface {
key name; key name;
leaf name { leaf name {
type nett:interface-name; type nett:interface-name;
} }
leaf priority { leaf priority {
description "Designated router priority"; description "Designated router priority";
type uint { // The type and range are type uint8; // The type is a constraint on
range 0..255; // constraints on valid // valid values for "priority".
} // values for "priority".
} }
leaf metric { leaf metric {
type uint { type uint16 {
range 1..65535; range 1..65535;
} }
} }
leaf dead-interval { leaf dead-interval {
units seconds; units seconds;
type uint { type uint16 {
range 1..65535; range 1..65535;
} }
} }
} }
} }
} }
} }
A YANG module defines a data model in terms of the data, its A YANG module defines a data model in terms of the data, its
hierarchical organization, and the constraints on that data. YANG hierarchical organization, and the constraints on that data. YANG
skipping to change at page 13, line 41 skipping to change at page 13, line 41
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) [DSDL]. Description Languages ([DSDL]).
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 7 skipping to change at page 15, line 7
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.
3. Working with YANG 3. Working with YANG
3.1. Addressing Operator Problems 3.1. Building YANG-based Solutions
In the typical YANG-based solution, the client and server are driven
by the content of YANG modules. The server includes the definitions
of the modules as meta-data that is available to the NETCONF engine.
This engine processes incoming requests, uses the meta-data to parse
and verify the request, performs the requested operation, and returns
the results to the client.
+----------------------------+
|Server (device) |
| +--------------------+ |
| | configuration | |
+----+ | | ---------------| |
|YANG|+ | | m d state data | |
|mods||+ | | e a ---------------| |
+----+|| -----> | t t notifications | |
+----+| | | a a ---------------| |
+----+ | | operations | |
| +--------------------+ |
| ^ |
| | |
| v |
+------+ | +-------------+ |
| | -------------> | | |
|Client| <rpc> | | NETCONF | |
| (app)| | | engine | |
| | <------------ | | |
+------+ <rpc-reply> +-------------+ |
| / \ |
| / \ |
| / \ |
| +--------+ +---------+ |
| | config | |system |+ |
| | data- | |software ||+ |
| | base | |component||| |
| +--------+ +---------+|| |
| +---------+| |
| +---------+ |
+----------------------------+
To use YANG, YANG modules must be defined to model the specific
problem domain. These modules are then loaded, compiled, or coded
into the server.
The sequence of events for the typical client/server interaction is
as follows:
o A client application ([C]) opens a NETCONF session to the server
(device) ([S])
o [C] and [S] exchange <hello> messages containing the list of
capabilities supported by each side, allowing [C] to learn the
modules supported by [S]
o [C] builds and sends an operation defined in the YANG module,
encoded in XML, within NETCONF's <rpc> element
o [S] receives and parses the <rpc> element
o [S] verifies the contents of the request against the data defined
in the YANG module
o [S] performs the requested operation, possibly changing the
configuration database
o [S] builds the response, containing the response, any requested
data, and any errors
o [S] sends the response, encoded in XML, within NETCONF's
<rpc-reply> element
o [C] receives and parses the <rpc-reply> element
o [C] inspects the response and processes it as needed
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
of the data model, rather than handle the content via a generic
engine. Or the client may be targeted at the specific YANG model,
rather than being driven generically. Such a client might be a
simple shell script that stuffs arguments into an XML payload and
sends it to the server.
3.2. Addressing Operator Problems
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 Operational data: YANG clearly divides
configuration data from other types of data. configuration data from other types of data.
skipping to change at page 17, line 5 skipping to change at page 18, line 41
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 NETCONF RPCs 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. RPC's input and output data are also defined in the YANG module.
3.2. Building YANG-based Solutions 3.3. Building YANG-based Solutions
Building YANG-based solutions requires interacting with many distinct Building YANG-based solutions requires interacting with many distinct
groups. Modelers must understand how to build useful models that groups. Modelers must understand how to build useful models that
give structure and meaning to data while maximizing the flexibility give structure and meaning to data while maximizing the flexibility
of that data to "future proof" their work. Reviewers need to quickly of that data to "future proof" their work. Reviewers need to quickly
determine if that structure is accurate. Device developers need to determine if that structure is accurate. Device developers need to
code that data model into their devices, and application developers code that data model into their devices, and application developers
need to code their applications to take advantage of that data model. need to code their applications to take advantage of that data model.
There are a variety of strategies for performing each piece of this There are a variety of strategies for performing each piece of this
work. This section discusses some of those strategies. work. This section discusses some of those strategies.
3.3. Modeler 3.4. Modeler
(No clue what needs said here; lots to say, but what's important?) The modeler's role constructing a model based on their in-depth
knowledge of the problem domain being modeled. This model should be
as simple as possible, but should balance complexity with
expressiveness. The organization of the model should target not only
the current model, but should allow for extensibility from other
modules and for adaptability to future changes.
Additional modeling issues are discussed in Section 4. Additional modeling issues are discussed in Section 4.
3.4. Reviewer 3.5. Reviewer
The reviewer role is perhaps the more important and the time The reviewer role is perhaps the more 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 In addition, reviewers can encode review policies in scripts, such as
XSLT. A policy that leaf names can't have underscores can be coded XSLT. A policy that leaf names can't have underscores can be coded
as: as:
<xsl:template match="leaf[contains(@name, '_')]"> <xsl:template match="leaf[contains(@name, '_')]">
Error: leaf name contains underscore Error: leaf name contains underscore
</xsl:template> </xsl:template>
3.5. Device Developer 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, absorbs the zen of the model,
and writes code that supports the model. The model describes the and writes code that supports the model. The model describes the
data hierarchy and associated constraints, and the description and data hierarchy and associated constraints, and the description and
reference material helps the developer understand how to transform reference material helps the developer understand how to transform
the models view into the device's native implementation. the models view into the device's native implementation.
3.5.1. Generic Content Support 3.6.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.5.2. XML "over the wire" Definitions 3.6.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.6. Application Developer 3.7. 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.6.1. Hard Coded 3.7.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.6.2. Bottom Up 3.7.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 allows 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.6.3. Top Down 3.7.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
changed and updated without affecting the device. changed and updated without affecting the device.
For example, an application could be written that models VPNs in a For example, an application could be written that models VPNs in a
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. 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,
and a list of classifiers.
list vpn { list ietf-bgpvpn {
key name; key name;
leaf name { ... } leaf name { ... }
leaf type { leaf protocol {
type enumeration { type enumeration {
enum bgpvpn; enum bgpvpn;
enum l2vpn; enum l2vpn;
} }
} }
leaf topology { leaf topology {
type enumeration { type enumeration {
enum hub-n-spoke; enum hub-n-spoke;
enum mesh; enum mesh;
} }
skipping to change at page 20, line 33 skipping to change at page 22, line 33
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 uses either a
standard device model (e.g. bgp.yang) or by transforming that standard device model (e.g. ietf-bgpvpn.yang) or by transforming that
standard device content into some proprietary format for devices that standard device content into some proprietary format for devices that
do not support that standard. 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
(With all the discussion on this point, it needs to be mentioned The concept of default values is simple, but their details,
here.) representation, and interaction with configuration data can be
difficult issues. NETCONF leaves default values as a data model
issue, and YANG gives flexibility to the device implementation in
terms of how default values are handled. The requirement is that the
device "MUST operationally behave as is if the leaf was present in
the data tree with the default value as its value". This gives the
device implementation choices in how default values are handled.
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
part of those instructions is the default value, then it should be
retained as part of the configuration, but if it not explicitly
given, then the value is not considered to be part of configuration.
Another choice is to trim values that are identical to the default
values, implicitly removing them from the configuration database.
The act of setting a leaf to it's default value effectively deletes
that leaf.
The device could also choose to report all default values, regardless
of whether they were explicitly set. This choice eases the work of a
client that needs default values, but may significantly increase the
size of the configuration data.
These choices reflect the default handling schemes of widely deployed
networking devices and supporting them allows YANG to reduce
implementation and deployment costs of YANG-based models.
When the client retrieves data from the device, it must be prepared
to handle the absence of leaf nodes with the default value, since the
server is not required to send such leaf elements. This permits the
device to implement either of the first two default handling schemes
given above.
Regardless of the implementation choice, the device can support the
"with-defaults" capability ([RFCWITHDEFAULTS]) and give the client
the ability to select the desired handling of default values.
When evaluating the XPath expressions for constraints like "must" and
"when", the evaluation context for the expressions will include any
appropriate default values, so the modeler can depend on consistent
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: four types of behavior in modeled device:
o [strict compliance] behavior that follow the model completely o [strict compliance] behavior that follow the model completely
o [modeled deviations] behavior that follows within deviations o [modeled deviations] behavior that follows within deviations
skipping to change at page 26, line 7 skipping to change at page 29, line 7
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 data modeling using YANG, and has no security
impact on the Internet. impact on the Internet.
6. Normative References 6. Normative References
[DSDL] International Organization for Standardization, "DSDL Part
0 - Overview", ISO DSDL, December 2001.
[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.
[RFCWITHDEFAULTS]
Bierman, A. and B. Lengyel, "With-defaults capability for
NETCONF", draft-ietf-netconf-with-defaults-05.txt (work in
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). NETCONF", draft-ietf-netmod-yang-11 (work in progress).
[RFCYANGTYPES] [RFCYANGTYPES]
Schoenwaelder, J., Ed., "Common YANG Data Types", Schoenwaelder, J., Ed., "Common YANG Data Types",
draft-ietf-netmod-yang-types-07.txt (work in progress). draft-ietf-netmod-yang-types-07.txt (work in progress).
Author's Address Author's Address
Phil Shafer Phil Shafer
 End of changes. 31 change blocks. 
71 lines changed or deleted 221 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/