--- 1/draft-ietf-netmod-arch-02.txt 2010-02-28 06:11:11.000000000 +0100 +++ 2/draft-ietf-netmod-arch-03.txt 2010-02-28 06:11:11.000000000 +0100 @@ -1,18 +1,31 @@ Network Working Group P. Shafer Internet-Draft Juniper Networks -Intended status: Informational May 27, 2009 -Expires: November 28, 2009 +Intended status: Informational February 27, 2010 +Expires: August 31, 2010 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 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. @@ -21,71 +34,84 @@ 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 28, 2009. + This Internet-Draft will expire on August 31, 2010. 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. 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. - -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. + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. - This document describes how NETCONF and YANG help build network - management applications that meet the needs of network operators. + This document may contain material from IETF Documents or IETF + 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 - 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 + 1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.2. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.3. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.3.1. Extensibility Model . . . . . . . . . . . . . . . . . 9 + 3. An Architecture for NETMOD . . . . . . . . . . . . . . . . . . 11 + 4. YANG and Related Technologies . . . . . . . . . . . . . . . . 14 + 4.1. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 4.2. DSDL (Relax NG) . . . . . . . . . . . . . . . . . . . . . 14 + 4.3. YANG Types . . . . . . . . . . . . . . . . . . . . . . . . 15 + 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 16 + 5.1. Device Developer . . . . . . . . . . . . . . . . . . . . . 16 + 5.2. Generic Content Support . . . . . . . . . . . . . . . . . 16 + 5.3. XML "over the wire" Definitions . . . . . . . . . . . . . 16 + 5.4. Application Developer . . . . . . . . . . . . . . . . . . 16 + 5.4.1. Hard Coded . . . . . . . . . . . . . . . . . . . . . . 16 + 5.4.2. Bottom Up . . . . . . . . . . . . . . . . . . . . . . 17 + 5.4.3. Top Down . . . . . . . . . . . . . . . . . . . . . . . 17 + 6. Modeling Considerations . . . . . . . . . . . . . . . . . . . 18 + 7. Data Distinctions . . . . . . . . . . . . . . . . . . . . . . 19 + 7.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 19 + 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 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]. 2. Introduction @@ -585,33 +611,171 @@ 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. -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 operation (and perhaps also a + 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 operation on + the 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 descriptions of management information. The language itself has no security impact on the Internet. -8. Normative References +9. 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). + NETCONF", draft-ietf-netmod-yang-11 (work in progress). Author's Address Phil Shafer Juniper Networks Email: phil@juniper.net