draft-ietf-netmod-arch-00.txt   draft-ietf-netmod-arch-01.txt 
Network Working Group P. Shafer Network Working Group P. Shafer
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Informational March 3, 2009 Intended status: Informational May 26, 2009
Expires: September 4, 2009 Expires: November 27, 2009
An Architecture for Network Management An NETCONF- and NETMOD-based Architecture for Network Management
draft-ietf-netmod-arch-00 draft-ietf-netmod-arch-01
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 to IETF 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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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 4, 2009. This Internet-Draft will expire on November 27, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
NETCONF and YANG are pieces of an ambitious plan to improve network NETCONF gives access to native capabilities of the devices within a
management. NETCONF gives access to native capabilities of the network, defining methods for manipulating configuration databases,
devices within a network, defining methods for manipulating retrieving operational data, and invoking specific operations. YANG
configuration databases, retrieving operational data, and invoking provides the means to define the content carried via NETCONF, both
specific operations. YANG provides the means to define the content data and operations. Using both technologies, standard modules can
trafficked via NETCONF, both data and operations. Using both be defined to give interoperability and commonality to devices, while
technologies, standard modules can be defined to give still allowing devices to express their unique capabilities.
interoperability and commonality to devices, while 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 services management applications that meet the needs of network operators.
providers.
Table of Contents Table of Contents
1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1. Extensibility Model . . . . . . . . . . . . . . . . . 8 2.3.1. Extensibility Model . . . . . . . . . . . . . . . . . 8
3. An Architecture for NETMOD . . . . . . . . . . . . . . . . . . 10 3. An Architecture for NETMOD . . . . . . . . . . . . . . . . . . 10
skipping to change at page 2, line 43 skipping to change at page 2, line 40
4.3. YANG Types . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3. YANG Types . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Device Developer . . . . . . . . . . . . . . . . . . . . . 15 5.1. Device Developer . . . . . . . . . . . . . . . . . . . . . 15
5.2. Generic Content Support . . . . . . . . . . . . . . . . . 15 5.2. Generic Content Support . . . . . . . . . . . . . . . . . 15
5.3. XML "over the wire" Definitions . . . . . . . . . . . . . 15 5.3. XML "over the wire" Definitions . . . . . . . . . . . . . 15
5.4. Application Developer . . . . . . . . . . . . . . . . . . 15 5.4. Application Developer . . . . . . . . . . . . . . . . . . 15
5.4.1. Hard Coded . . . . . . . . . . . . . . . . . . . . . . 15 5.4.1. Hard Coded . . . . . . . . . . . . . . . . . . . . . . 15
5.4.2. Bottom Up . . . . . . . . . . . . . . . . . . . . . . 16 5.4.2. Bottom Up . . . . . . . . . . . . . . . . . . . . . . 16
5.4.3. Top Down . . . . . . . . . . . . . . . . . . . . . . . 16 5.4.3. Top Down . . . . . . . . . . . . . . . . . . . . . . . 16
6. Modeling Considerations . . . . . . . . . . . . . . . . . . . 17 6. Modeling Considerations . . . . . . . . . . . . . . . . . . . 17
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Normative References . . . . . . . . . . . . . . . . . . . . . 19
9. Normative References . . . . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Key Words 1. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14, [RFC2119]. 14, [RFC2119].
2. Introduction 2. Introduction
skipping to change at page 6, line 7 skipping to change at page 6, line 7
NETCONF includes mechanisms for controlling configuration datastores, NETCONF includes mechanisms for controlling configuration datastores,
fetching state data, receiving notifications, and allows for fetching state data, receiving notifications, and allows for
additional RPC methods. Configuration operations include the ability additional RPC methods. Configuration operations include the ability
to lock datastores to isolate one application from the actions of to lock datastores to isolate one application from the actions of
others, the ability to save and restore configuration data sets, and others, the ability to save and restore configuration data sets, and
the ability to discover (via the <hello> message) the capabilities of the ability to discover (via the <hello> message) the capabilities of
the device. the device.
2.3. YANG 2.3. YANG
YANG is a data model language for NETCONF that allows the description YANG is the data model language for NETCONF that allows the
of hierarchies of nodes and the constraints that exist amongst them. description of hierarchies of data model nodes ("nodes") and the
YANG defines data models and how to manipulate those models via constraints that exist amongst them. YANG defines data models and
NETCONF protocol operations. how to manipulate those models via NETCONF protocol operations.
Each yang module define 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 instances and leaf data values.
module ietf-ospf { module ietf-ospf {
namespace http://ns.ietf.org/netconf/ospf; namespace http://ns.ietf.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
skipping to change at page 7, line 51 skipping to change at page 8, line 5
} }
} }
} }
} }
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
defines how this data is represented in XML and how that data is used defines how this data is represented in XML and how that data is used
in NETCONF operations. in NETCONF operations.
Open source tools for YANG are available on
http://www.yang-central.org.
2.3.1. Extensibility Model 2.3.1. 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
skipping to change at page 8, line 31 skipping to change at page 8, line 31
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 ietf-ospf { import ietf-ospf {
prefix ospf; prefix ospf;
} }
BL: need leading slash:
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
skipping to change at page 10, line 32 skipping to change at page 10, line 32
Applications may take advantage of these specifics to give their Applications may take advantage of these specifics to give their
users complete control over the device. users complete control over the device.
When a NETCONF session begins, the namespaces for all supported When a NETCONF session begins, the namespaces for all supported
modules are announced as capabilities via the device's <hello> modules are announced as capabilities via the device's <hello>
message. The device should also support the schema discovery message. The device should also support the schema discovery
mechanism [ref], enabling applications to discover the location from mechanism [ref], enabling applications to discover the location from
which the modules may be downloaded. which the modules may be downloaded.
The schema discovery for standard YANG modules should list a common, The schema discovery for standard YANG modules should list a common,
standard location for these modules, assumably one set by the standard location for these modules, presumably one set by the
organization that defined the standard. organization that defined the standard.
When an application connects with a device, it receives the list of When an application connects with a device, it receives the list of
capabilities supported by that device. The application may compare capabilities supported by that device. The application may compare
the set of capabilities announced by the device with the set of the set of capabilities announced by the device with the set of
modules the application is aware of. Any new modules or new modules the application is aware of. Any new modules or new
revisions of known modules may be downloaded as needed from the revisions of known modules may be downloaded as needed from the
locations given via the schema discovery mechanism. locations given via the schema discovery mechanism.
Once the application has access to the YANG modules, it may Once the application has access to the YANG modules, it may
skipping to change at page 13, line 32 skipping to change at page 13, line 32
4.1. YIN 4.1. YIN
In some environments, incorporating a YANG parser may not be an In some environments, incorporating a YANG parser may not be an
acceptable option. For those scenarios, an XML grammar for YANG is acceptable option. For those scenarios, an XML grammar for YANG is
defined in YIN (YANG Independent Notation) [ref]. YIN allows the use defined in YIN (YANG Independent Notation) [ref]. YIN allows the use
of XML parsers which are readily available in both open source and of XML parsers which are readily available in both open source and
commercial versions. Conversion between YANG and YIN is direct, commercial versions. Conversion between YANG and YIN is direct,
loss-less and reversible. YANG statements are converted to XML loss-less and reversible. YANG statements are converted to XML
elements, preserving the structure and content of YANG, but enabling elements, preserving the structure and content of YANG, but enabling
the use of "off the shelf" XML parsers rather than requiring the the use of off-the-shelf XML parsers rather than requiring the
integration of a YANG parser. YIN maintains complete semantic integration of a YANG parser. YIN maintains complete semantic
equivalence with YANG. equivalence with YANG.
BL: use of xslt is a key use
4.2. DSDL (Relax NG) 4.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].
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.
4.3. YANG Types 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 A standard type library for use by YANG is available [ref]. These
YANG modules define commonly used data types for IETF-related YANG modules define commonly used data types for IETF-related
standards. standards.
5. Applicability 5. Applicability
The data model in a YANG module yields value in five specific areas. The data model in a YANG module yields value in five specific areas.
5.1. Device Developer 5.1. Device Developer
skipping to change at page 16, line 26 skipping to change at page 16, line 26
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 content. 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 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.
5.4.3. Top Down 5.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
skipping to change at page 17, line 23 skipping to change at page 17, line 23
o [modeled deviations] behavior that follows within deviations o [modeled deviations] behavior that follows within deviations
allowed by the model allowed by the model
o [allowable deviations] behavior that falls outside the model, but o [allowable deviations] behavior that falls outside the model, but
can still be handled can still be handled
o [unacceptable deviations] behavior that is not at all consistent o [unacceptable deviations] behavior that is not at all consistent
with the model with the model
Once the model is published, an implementer may decide to make a Once the model is published, an implementer may decide to make a
particular node configurable, where the standard model describes it a particular data model node configurable, where the standard model
state data. The implementation reports the value normally and may describes it a state data. The implementation reports the value
have an "out of band" mechanism for reporting that this node behaves normally and may have an "out of band" mechanism for reporting that
in a different manner than the standard. Applications capable of this device behaves in a different manner than the standard.
discovering such behavior can make allowances, but applications that Applications capable of discovering such behavior can make
do not discover such behavior can continue treating the allowances, but applications that do not discover such behavior can
implementation as if it were compliant. 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 must 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.
7. Conclusion 7. Security Considerations
The YANG design committee and the NETMOD working group have used the
implementation experience of their members to build a data modeling
language for NETCONF that balances simplicity, flexibility, and
extensibility in a harmony unequaled since the dawn of the claw
hammer. The development of multiple YANG implementations has given
us early feedback on technical issues and helped crisp the wording of
many issues in the YANG specification.
8. Security Considerations
This document defines a language with which to write and read This document defines a language with which to write and read
descriptions of management information. The language itself has no descriptions of management information. The language itself has no
security impact on the Internet. security impact on the Internet.
9. Normative References 8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006. December 2006.
[YANG] Bjorklund, M., Ed., "YANG - A data modeling language for [YANG] Bjorklund, M., Ed., "YANG - A data modeling language for
NETCONF", draft-ietf-netmod-yang-00 (work in progress). NETCONF", draft-ietf-netmod-yang-05 (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. 21 change blocks. 
56 lines changed or deleted 48 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/