draft-ietf-netmod-arch-02.txt   draft-ietf-netmod-arch-03.txt 
Network Working Group P. Shafer Network Working Group P. Shafer
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Informational May 27, 2009 Intended status: Informational February 27, 2010
Expires: November 28, 2009 Expires: August 31, 2010
An NETCONF- and NETMOD-based Architecture for Network Management An NETCONF- and NETMOD-based Architecture for Network Management
draft-ietf-netmod-arch-02 draft-ietf-netmod-arch-03
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.
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 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 November 28, 2009. This Internet-Draft will expire on August 31, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
NETCONF gives access to native capabilities of the devices within a described in the Simplified BSD License.
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 This document may contain material from IETF Documents or IETF
management applications that meet the needs of network operators. Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1. Extensibility Model . . . . . . . . . . . . . . . . . 8 2.3.1. Extensibility Model . . . . . . . . . . . . . . . . . 9
3. An Architecture for NETMOD . . . . . . . . . . . . . . . . . . 10 3. An Architecture for NETMOD . . . . . . . . . . . . . . . . . . 11
4. YANG and Related Technologies . . . . . . . . . . . . . . . . 13 4. YANG and Related Technologies . . . . . . . . . . . . . . . . 14
4.1. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. DSDL (Relax NG) . . . . . . . . . . . . . . . . . . . . . 13 4.2. DSDL (Relax NG) . . . . . . . . . . . . . . . . . . . . . 14
4.3. YANG Types . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3. YANG Types . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. Device Developer . . . . . . . . . . . . . . . . . . . . . 15 5.1. Device Developer . . . . . . . . . . . . . . . . . . . . . 16
5.2. Generic Content Support . . . . . . . . . . . . . . . . . 15 5.2. Generic Content Support . . . . . . . . . . . . . . . . . 16
5.3. XML "over the wire" Definitions . . . . . . . . . . . . . 15 5.3. XML "over the wire" Definitions . . . . . . . . . . . . . 16
5.4. Application Developer . . . . . . . . . . . . . . . . . . 15 5.4. Application Developer . . . . . . . . . . . . . . . . . . 16
5.4.1. Hard Coded . . . . . . . . . . . . . . . . . . . . . . 15 5.4.1. Hard Coded . . . . . . . . . . . . . . . . . . . . . . 16
5.4.2. Bottom Up . . . . . . . . . . . . . . . . . . . . . . 16 5.4.2. Bottom Up . . . . . . . . . . . . . . . . . . . . . . 17
5.4.3. Top Down . . . . . . . . . . . . . . . . . . . . . . . 16 5.4.3. Top Down . . . . . . . . . . . . . . . . . . . . . . . 17
6. Modeling Considerations . . . . . . . . . . . . . . . . . . . 17 6. Modeling Considerations . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Data Distinctions . . . . . . . . . . . . . . . . . . . . . . 19
8. Normative References . . . . . . . . . . . . . . . . . . . . . 19 7.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 19
7.2.1. Example 1: IP Routing Table . . . . . . . . . . . . . 20
7.2.2. Example 2: Interfaces . . . . . . . . . . . . . . . . 20
7.2.3. Example 3: Account Information . . . . . . . . . . . . 20
7.3. Implications . . . . . . . . . . . . . . . . . . . . . . . 21
7.3.1. Data Models . . . . . . . . . . . . . . . . . . . . . 21
7.3.2. Additional Operations to Retrieve Operational State . 21
7.3.3. Introduction of an Operational State Datastore . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. Normative References . . . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
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 18, line 5 skipping to change at page 19, line 5
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. Security Considerations 7. Data Distinctions
The distinction between configuration data, operational state data,
and statistics is important to understand for data model writers and
people who plan to extend the NETCONF protocol. This section first
discusses some background and then provides a definition and some
examples.
7.1. Background
During the IAB Network Management Workshop documented in RFC 3535,
operators did formulate the following two requirements:
2. It is necessary to make a clear distinction between
configuration data, data that describes operational state
and statistics. Some devices make it very hard to determine
which parameters were administratively configured and which
were obtained via other mechanisms such as routing
protocols.
3. It is required to be able to fetch separately configuration
data, operational state data, and statistics from devices,
and to be able to compare these between devices.
The NETCONF protocol defined in RFC 4741 distinguishes two types of
data, namely configuration data and state data:
Configuration data is the set of writable data that is
required to transform a system from its initial default state
into its current state.
State data is the additional data on a system that is not
configuration data such as read-only status information and
collected statistics.
NETCONF does not follow the distinction formulated by the operators
between configuration data, operational state data, and statistical
data, since it considers state data to include both statistics and
operational state data.
7.2. Definitions
Below is a definition for configuration data, operational state data,
and statistical data. The definition borrows from previous work.
o Configuration data is the set of writable data that is required to
transform a system from its initial default state into its current
state. [RFC 4741]
o Operational state data is a set of data that has been obtained by
the system at runtime and influences the system's behaviour
similar to configuration data. In contrast to configuration data,
operational state is transient and modified by interactions with
internal components or other systems via specialized protocols.
o Statistical data is the set of read-only data created by a system
itself. It describes the performance of the system and its
components.
The following examples help to clarify the difference between
configuration data, operational state data and statistical data.
7.2.1. Example 1: IP Routing Table
IP routing tables can contain entries that are statically configured
(configuration data) as well as entries obtained from routing
protocols such as OSPF (operational state data). In addition, a
routing engine might collect statistics like how often a particular
routing table entry has been used.
7.2.2. Example 2: Interfaces
Network interfaces usually comes with a large number of attributes
that are specific to the interface type and in some cases specific to
the cable plugged into an interface. Examples are the maximum
transmission unit of an interface or the speed detected by an
Ethernet interface.
In many deployments, systems use the interface attributes detected
when an interface is initialized. As such, these attributes
constitute operational state. However, there are usually provisions
to overwrite the discovered attributes with static configuration
data, like for example configuring the interface MTU to use a
specific value or forcing an Ethernet interface to run at a given
speed.
The system will record statistics (counters) measuring the number of
packets, bytes, and errors received and transmitted on each
interface.
7.2.3. Example 3: Account Information
Systems usually maintain static configuration information about the
accounts on the system. In addition, systems can obtain information
about accounts from other sources (e.g. LDAP, NIS) dynamically,
leading to operational state data. Information about account usage
are examples of statistic data.
Note that configuration data supplied to a system in order to create
a new account might be supplemented with additional configuration
information determined by the system when the account is being
created (such as a unique account id). Even though the system might
create such information, it usually becomes part of the static
configuration of the system since this data is not transient.
7.3. Implications
The primary focus of YANG is configuration data. There is no single
mechanism defined for the separation of operational state data and
statistics since NETCONF treats them both as state data. This
section describes several different options for addressing this
issue.
7.3.1. Data Models
The first option is to have data models that provide explicitly
differentiate between configuration data and operational state data.
This leads to duplication of data structures and might not scale well
from a modeling perspective.
For example, the configured duplex value and the operational duplex
value would be distinct leafs in the data model.
7.3.2. Additional Operations to Retrieve Operational State
The NETCONF protocol can be extended with new protocol operations
that specifically allow the retrieval of all operational state, e.g.
by introducing a <get-ops> operation (and perhaps also a <get-stats>
operation).
7.3.3. Introduction of an Operational State Datastore
Another option could be to introduce a new "configuration" data store
that represents the operational state. A <get-config> operation on
the <operational> data store would then return the operational state
determining the behaviour of the box instead of its static and
explicit configuration state.
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.
8. Normative References 9. 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-05 (work in progress). NETCONF", draft-ietf-netmod-yang-11 (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. 10 change blocks. 
47 lines changed or deleted 211 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/