Network Working Group P. Shafer
Internet-Draft Juniper Networks
Intended status: Informational May 26, 2009
Expires: November 27, 2009
An NETCONF- and NETMOD-based Architecture for Network Management
draft-ietf-netmod-arch-01
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
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 November 27, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Shafer Expires November 27, 2009 [Page 1]
Internet-Draft NETMODARCH May 2009
Abstract
NETCONF gives access to native capabilities of the devices within a
network, defining methods for manipulating configuration databases,
retrieving operational data, and invoking specific operations. YANG
provides the means to define the content carried via NETCONF, both
data and operations. Using both technologies, standard modules can
be defined to give interoperability and commonality to devices, while
still allowing devices to express their unique capabilities.
This document describes how NETCONF and YANG help build network
management applications that meet the needs of network operators.
Table of Contents
1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1. Extensibility Model . . . . . . . . . . . . . . . . . 8
3. An Architecture for NETMOD . . . . . . . . . . . . . . . . . . 10
4. YANG and Related Technologies . . . . . . . . . . . . . . . . 13
4.1. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. DSDL (Relax NG) . . . . . . . . . . . . . . . . . . . . . 13
4.3. YANG Types . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Device Developer . . . . . . . . . . . . . . . . . . . . . 15
5.2. Generic Content Support . . . . . . . . . . . . . . . . . 15
5.3. XML "over the wire" Definitions . . . . . . . . . . . . . 15
5.4. Application Developer . . . . . . . . . . . . . . . . . . 15
5.4.1. Hard Coded . . . . . . . . . . . . . . . . . . . . . . 15
5.4.2. Bottom Up . . . . . . . . . . . . . . . . . . . . . . 16
5.4.3. Top Down . . . . . . . . . . . . . . . . . . . . . . . 16
6. Modeling Considerations . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Normative References . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
Shafer Expires November 27, 2009 [Page 2]
Internet-Draft NETMODARCH May 2009
1. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14, [RFC2119].
Shafer Expires November 27, 2009 [Page 3]
Internet-Draft NETMODARCH May 2009
2. Introduction
Networks are increasing in complexity and capacity, as well as the
density of the services deployed upon them. Uptime, reliability, and
predictable latency requirements drive the need for automation.
The problems with network management are not simple. They are
complex and intricate. But these problems must be solved for
networks to meet the stability needs of existing services while
incorporating new services in a world where the growth of the
networks is exhausting the supply of qualified networking engineers.
We need to move from a CLI world into a world of automation, but that
automation must be robust and trustworthy.
This document presents an architecture based on NETCONF ([RFC4741])
and [YANG]. NETCONF and YANG address the problems of network
management with flexibility and expressiveness. NETCONF allows any
manner of configuration and operational data to be carried with few
rules governing the data. YANG allows data models to be defined that
are flexible and extensible in ways that allow the data to be
cohesive and structured, but not rigid.
This approach allows the device to express its native capabilities in
a way that is flexible and extensible. Evolution of devices and data
models are permitted and managed.
2.1. Terminology
The document mirrors terminology from NETCONF. NETCONF uses a simple
RPC-based mechanism to facilitate communication between a client and
a server. The client can be a script or application typically
running as part of a network management system. The server is
typically a network device. The terms "device" and "server" are used
interchangeably in this document, as are "client" and "application".
2.2. NETCONF
NETCONF defines an XML-based RPC mechanism that leverages the
simplicity and availability of high-quality XML parsers. XML gives a
rich, flexible, hierarchical, standard representation of data that
matches the needs of networking devices. NETCONF carries
configuration data and operations encoded in XML using an RPC
mechanism over a connection-oriented transport.
XML's hierarchical data representation allows complex networking data
to be rendered in a natural way. For example, the following
configuration places interfaces in OSPF areas. The <ospf> element
contains a list of <area> elements, each of which contain a list of
Shafer Expires November 27, 2009 [Page 4]
Internet-Draft NETMODARCH May 2009
<interface> elements. The <name> element identifies the specific
area or interface. Additional configuration for each area or
interface appears directly inside the appropriate element.
<ospf xmlns="http://ns.ietf.org/netconf/ospf">
<area>
<name>0.0.0.0</name>
<interface>
<name>ge-0/0/0.0</name>
<!-- The priority for this interface -->
<priority>30</priority>
<metric>100</metric>
<dead-interval>120</dead-interval>
</interface>
<interface>
<name>ge-0/0/1.0</name>
<metric>140</metric>
</interface>
</area>
<area>
<name>10.1.2.0</name>
<interface>
<name>ge-0/0/2.0</name>
<metric>100</metric>
</interface>
<interface>
<name>ge-0/0/3.0</name>
<metric>140</metric>
<dead-interval>120</dead-interval>
</interface>
</area>
</ospf>
NETCONF includes mechanisms for controlling configuration datastores,
fetching state data, receiving notifications, and allows for
additional RPC methods. Configuration operations include the ability
to lock datastores to isolate one application from the actions of
others, the ability to save and restore configuration data sets, and
the ability to discover (via the <hello> message) the capabilities of
the device.
Shafer Expires November 27, 2009 [Page 5]
Internet-Draft NETMODARCH May 2009
2.3. YANG
YANG is the data model language for NETCONF that allows the
description of hierarchies of data model nodes ("nodes") and the
constraints that exist amongst them. YANG defines data models and
how to manipulate those models via NETCONF protocol operations.
Each YANG module defines a data model, uniquely identified by a
namespace URI. These data models are extensible in a manner that
allows tight integration of standard data models and proprietary data
models. Models are built from organizational containers, lists of
data instances and leaf data values.
Shafer Expires November 27, 2009 [Page 6]
Internet-Draft NETMODARCH May 2009
module ietf-ospf {
namespace http://ns.ietf.org/netconf/ospf;
prefix ospf;
import network-types { // Access another module's def'ns
prefix nett;
}
container ospf { // Declare the top-level tag
list area { // Declare a list of "area" nodes
key name; // The key "name" identifies list members
leaf name {
type nett:area-id;
}
list interface {
key name;
leaf name {
type nett:interface-name;
}
leaf priority {
description "Designated router priority";
type uint { // The type and range are
range 0..255; // constraints on valid
} // values for "priority".
}
leaf metric {
type uint {
range 1..65535;
}
}
leaf dead-interval {
units seconds;
type uint {
range 1..65535;
}
}
}
}
}
}
A YANG module defines a data model in terms of the data, its
hierarchical organization, and the constraints on that data. YANG
defines how this data is represented in XML and how that data is used
in NETCONF operations.
Shafer Expires November 27, 2009 [Page 7]
Internet-Draft NETMODARCH May 2009
2.3.1. Extensibility Model
XML includes the concept of namespaces, allowing XML elements from
different sources to be combined in the same hierarchy without
risking collision. YANG modules define content for specific
namespaces, but one module may augment the definition of another
module, introducing elements from that module's namespace into the
first module's hierarchy.
Since one module can augment another module's definition, hierarchies
of definitions are allowed to grow, as definitions from multiple
sources are added to the base hierarchy. These augmentations are
qualified using the namespace of the source module, helping to avoid
issues with name conflicts as the modules change over time.
For example, if the above OSPF configuration were the standard, a
vendor module may augment this with vendor-specific extensions.
module vendorx-ospf {
namespace http://vendorx.example.com/ospf;
prefix vendorx;
import ietf-ospf {
prefix ospf;
}
BL: need leading slash:
augment ospf:ospf/ospf:area/ospf:interfaces {
leaf no-neighbor-down-notification {
type empty;
description "Don't inform other protocols about"
+ " neighbor down events";
}
}
}
The <no-neighbor-down-notification> element is then placed in the
vendorx namespace:
Shafer Expires November 27, 2009 [Page 8]
Internet-Draft NETMODARCH May 2009
<protocols xmlns="http://ietf.org/netconf/protocols"
xmlns:vendorx="http://vendorx.example.com/ospf">
<ospf xmlns="http://ietf.org/netconf/ospf">
<area>
<name>0.0.0.0</name>
<interface>
<name>ge-0/0/0.0</name>
<priority>30</priority>
<vendorx:no-neighbor-down-notification/>
</interface>
</area>
</ospf>
</protocols>
Augmentations are seamlessly integrated with base modules, allowing
them to be fetched, archived, loaded, and deleted within their
natural hierarchy. If a client application asks for the
configuration for a specific OSPF area, it will receive the sub-
hierarchy for that area, complete with any augmentations.
Shafer Expires November 27, 2009 [Page 9]
Internet-Draft NETMODARCH May 2009
3. An Architecture for NETMOD
In the NETMOD architecture, each device vendor implements a set of
data models in their devices. These models are either standard data
models, defined in YANG modules published by a standards body, or
proprietary data models, defined in YANG modules published by
vendors.
Standard data models define content that is independent of the
vendor, allowing client applications to request specific behavior
without concern for the vendor, product line, or installed software
revision. The translation between the standard model and the device
specific behavior is performed by the device, freeing the application
from such concerns.
Proprietary data models allow the vendor to accurately describe the
content and behavior of their devices in explicit detail.
Applications may take advantage of these specifics to give their
users complete control over the device.
When a NETCONF session begins, the namespaces for all supported
modules are announced as capabilities via the device's <hello>
message. The device should also support the schema discovery
mechanism [ref], enabling applications to discover the location from
which the modules may be downloaded.
The schema discovery for standard YANG modules should list a common,
standard location for these modules, presumably one set by the
organization that defined the standard.
When an application connects with a device, it receives the list of
capabilities supported by that device. The application may compare
the set of capabilities announced by the device with the set of
modules the application is aware of. Any new modules or new
revisions of known modules may be downloaded as needed from the
locations given via the schema discovery mechanism.
Once the application has access to the YANG modules, it may
manipulate the device as a "YANG data browser", capable of parsing
the elements sent from the device with an understanding of the
organization of the data. The module describes the syntax of the
data and constraints on that data, allowing the application to create
data that abides by those constraints.
To have a real understanding of a module's content, the application
may need to incorporate logic specific to that module. Semantic
information contained in description statements is not machine
readable, but module-specific custom work can be done to tailor the
Shafer Expires November 27, 2009 [Page 10]
Internet-Draft NETMODARCH May 2009
user interface to the particular semantic needs of a module.
For example, a module could define the "location" of a device using
longitude and latitude, and the application can use the "browser"
style to display this data using input fields in a web form. Custom
logic would be needed to take the value of these fields and place the
device on a map of the world, and additional logic would be needed to
update the data values when the user drags the device from Dallas to
Dulles.
If an application is meant to manage a specific problem, it may model
the data internally in whatever form is most convenient to its
organizational needs. When the application interacts with a device,
it may choose one of two paths. If the device implements a standard
module, the application may generate content for that standard by
translating its internal form into the standard one.
If the device doesn't implement such a standard or no such standard
exists, the application may use a transformation that is particular
to that device's vendor, product model, hardware, or software.
Depending on the application, this transformation may be provided by
the application vendor, the device vendor, a third-party, or the
provider.
For a popular application, the device vendor may wish to provide this
transformation to increase market acceptance of their devices. For
popular devices, the application may provide this transformation as a
means of making the application useful in the maximum number of
provider networks. For problem domains where the mapping from the
application to the device is not straight-forward or requires
tailoring to the specific provider or environment, the provider may
wish to control this transformation. Additionally, other parties may
make such transformations available via open source.
Note that both cases may appear within a single application on an "as
needed" basis. If the device announces the capability for the
standard YANG module, the application may transmit to the device via
NETCONF the content in the standard modules format. If the device
does not announce the appropriate capability, the application may
find a transformation that matches the device, perform the
transformation on the standard data to produce device native
configuration, and transmit via NETCONF that device configuration to
the device.
In both cases, the key is the ability to discover the capabilities of
the specific device, download the YANG modules that support those
capabilities, gain an understanding of those data models and their
constraints, generate appropriate content, and transmit that content
Shafer Expires November 27, 2009 [Page 11]
Internet-Draft NETMODARCH May 2009
to the device.
Shafer Expires November 27, 2009 [Page 12]
Internet-Draft NETMODARCH May 2009
4. YANG and Related Technologies
The YANG data modeling language is the central piece of a group of
related technologies. The YANG language itself, described in [ref],
defines the syntax of the language and its statements, the meaning of
those statements, and how to combine them to build the hierarchy of
nodes that describe a data model.
That document also defines the "on the wire" XML content for NETCONF
operations on data models defined in YANG modules. This includes the
basic mapping between YANG data tree nodes and XML elements, as well
as mechanisms used in <edit-config> content to manipulate that data,
such as arranging the order of nodes within a list.
YANG uses a syntax that is regular and easily described, primarily
designed for human readability. YANG's syntax is friendly to email,
diff, patch, and the constraints of RFC formatting.
4.1. YIN
In some environments, incorporating a YANG parser may not be an
acceptable option. For those scenarios, an XML grammar for YANG is
defined in YIN (YANG Independent Notation) [ref]. YIN allows the use
of XML parsers which are readily available in both open source and
commercial versions. Conversion between YANG and YIN is direct,
loss-less and reversible. YANG statements are converted to XML
elements, preserving the structure and content of YANG, but enabling
the use of off-the-shelf XML parsers rather than requiring the
integration of a YANG parser. YIN maintains complete semantic
equivalence with YANG.
BL: use of xslt is a key use
4.2. DSDL (Relax NG)
Since NETCONF content is encoded in XML, it is natural to use XML
schema languages for their validation. To facilitate this, YANG
offers a standardized mapping of YANG modules into Document Schema
Description Languages (DSDL) [DSDL].
DSDL is considered to be the best choice for the given purpose
because it addresses not only grammar and datatypes of XML documents
but also semantic constraints and rules for modifying information set
of the document.
In addition, DSDL offers formal means for coordinating multiple
independent schemas and specifying how to apply the schemas to the
various parts of the document. This is useful since YANG content is
Shafer Expires November 27, 2009 [Page 13]
Internet-Draft NETMODARCH May 2009
typically composed of multiple vocabularies.
4.3. YANG Types
YANG supports a number of builtin types, and allows additional types
to be derived from those types in an extensible manner. New types
can add additional restrictions to allowable data values.
A standard type library for use by YANG is available [ref]. These
YANG modules define commonly used data types for IETF-related
standards.
Shafer Expires November 27, 2009 [Page 14]
Internet-Draft NETMODARCH May 2009
5. Applicability
The data model in a YANG module yields value in five specific areas.
5.1. Device Developer
The YANG model tells the device developer what data is being modeled.
The developer reads the YANG models, absorbs the zen of the model,
and writes code that supports the model. The model describes the
data hierarchy and associated constraints, and the description and
reference material helps the developer understand how to transform
the models view into the device native implementation.
5.2. Generic Content Support
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
outgoing data. The complete configuration datastore may be validated
in accordance with the constraints described in the data model.
Serializers and deserializers for generating and receiving NETCONF
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
incoming XML elements.
5.3. XML "over the wire" Definitions
The YANG module dictates the XML encoding sent "over the wire",
though actual transmission should be encrypted so as not to appear as
readable text on the physical media. The rules that define the
encoding are fixed, so the YANG module can be used to ascertain
whether a specific NETCONF payload is obeying the rules.
5.4. Application Developer
The YANG module tells the application developer what data can be
modeled. Developers can inspect the modules and take one of three
distinct views. In this section, we will consider them and the
impact of YANG on their design. In the real world, most applications
are a mixture of these approaches.
5.4.1. Hard Coded
An application can be coded against the specific, well-known contents
of YANG modules, implementing their organization, rules, and logic
directly with explicit knowledge. For example, a script could be
written to change the domain name of a set of devices using a
standard YANG module that includes such a leaf node. This script
Shafer Expires November 27, 2009 [Page 15]
Internet-Draft NETMODARCH May 2009
takes the new domain name as an argument and insert it into a string
containing the rest of the XML encoding as required by the YANG
module. This content is then sent via NETCONF to the devices.
This type of application is useful for small, fixed problems where
the cost and complexity of flexibility is overwhelmed by the ease of
hard coding direct knowledge into the application.
5.4.2. Bottom Up
An application may take a generic, bottom up approach to
configuration, concentrating on the device's data directly and
treating that data without specific understanding.
YANG modules may be used to drive the operation of the YANG
equivalent of a "MIB Browser". Such an application manipulates the
device's configuration data based on the data organization contained
in the YANG module. For example, a GUI may present a straight-
forward visualization where elements of the YANG hierarchy are
depicted in a hierarchy of folders or GUI panels. Clicking on a line
expands to the contents of the matching content.
BL: GUI comments don't need to be here
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
configuration data into a set of web pages.
The YANG modules allows the application to enforce a set of
constraints without understanding the semantics of the YANG module.
5.4.3. Top Down
In contrast to the bottom-up approach, the top-down approach allows
the application to take a view of the configuration data which is
distinct from the standard and/or proprietary YANG modules. The
application is free to construct its own model for data organization
and to present this model to the user. When the application needs to
transmit data to a device, the application transforms its data from
the problem-oriented view of the world into the data needed for that
particular device. This transformation is under the control and
maintenance of the application, allowing the transformation to be
changed and updated without affecting the device.
For example, an application could be written that models VPNs in a
network-oriented view. The application would need to transform these
high-level VPN definitions into the configuration data that would be
handed to any particular device within a VPN.
Shafer Expires November 27, 2009 [Page 16]
Internet-Draft NETMODARCH May 2009
6. Modeling Considerations
In developing good data models, there are many conflicting interests
the data modeler must keep in mind. Modelers need to be aware of
four types of behavior in modeled device:
o [strict compliance] behavior that follow the model completely
o [modeled deviations] behavior that follows within deviations
allowed by the model
o [allowable deviations] behavior that falls outside the model, but
can still be handled
o [unacceptable deviations] behavior that is not at all consistent
with the model
Once the model is published, an implementer may decide to make a
particular data model node configurable, where the standard model
describes it a state data. The implementation reports the value
normally and may have an "out of band" mechanism for reporting that
this device behaves in a different manner than the standard.
Applications capable of discovering such behavior can make
allowances, but applications that do not discover such behavior can
continue treating the implementation as if it were compliant.
Rarely, implementations may make decisions that prevent compliance
with the standard. Such occasions are regrettable, but they remain a
part of reality, and modelers and application writers ignore them at
their own risk. An implementation that emits an integer leaf as
"cow" would be difficult to manage, but applications must expect to
encounter such misbehaving devices in the field.
Despite this, both client and server should view the YANG module as a
contract, with both sides agreeing to abide by the terms. The
modeler should be explicit about the terms of such a contract, and
both client and server implementations should strive to faithfully
and accurately implement the data model described in the YANG module.
Shafer Expires November 27, 2009 [Page 17]
Internet-Draft NETMODARCH May 2009
7. Security Considerations
This document defines a language with which to write and read
descriptions of management information. The language itself has no
security impact on the Internet.
Shafer Expires November 27, 2009 [Page 18]
Internet-Draft NETMODARCH May 2009
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006.
[YANG] Bjorklund, M., Ed., "YANG - A data modeling language for
NETCONF", draft-ietf-netmod-yang-05 (work in progress).
Shafer Expires November 27, 2009 [Page 19]
Internet-Draft NETMODARCH May 2009
Author's Address
Phil Shafer
Juniper Networks
Email: phil@juniper.net
Shafer Expires November 27, 2009 [Page 20]
