--- 1/draft-ietf-netmod-arch-00.txt 2009-05-27 18:12:11.000000000 +0200 +++ 2/draft-ietf-netmod-arch-01.txt 2009-05-27 18:12:12.000000000 +0200 @@ -1,18 +1,18 @@ Network Working Group P. Shafer Internet-Draft Juniper Networks -Intended status: Informational March 3, 2009 -Expires: September 4, 2009 +Intended status: Informational May 26, 2009 +Expires: November 27, 2009 - An Architecture for Network Management - draft-ietf-netmod-arch-00 + 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. @@ -21,49 +21,45 @@ 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 September 4, 2009. + 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 - (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. + 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 and YANG are pieces of an ambitious plan to improve network - management. 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 - trafficked 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. + 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 services - providers. + 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 @@ -73,24 +69,23 @@ 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. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 - 9. Normative References . . . . . . . . . . . . . . . . . . . . . 20 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 8. Normative References . . . . . . . . . . . . . . . . . . . . . 19 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 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 @@ -182,26 +177,26 @@ 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 message) the capabilities of the device. 2.3. YANG - YANG is a data model language for NETCONF that allows the description - of hierarchies of nodes and the constraints that exist amongst them. - YANG defines data models and how to manipulate those models via - NETCONF protocol operations. + 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 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 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. module ietf-ospf { namespace http://ns.ietf.org/netconf/ospf; prefix ospf; import network-types { // Access another module's def'ns @@ -239,23 +234,20 @@ } } } } 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. - Open source tools for YANG are available on - http://www.yang-central.org. - 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 @@ -268,20 +260,22 @@ 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 element is then placed in the @@ -330,21 +324,21 @@ 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 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, assumably one set by the + 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 @@ -428,43 +422,49 @@ 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 + 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 + 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 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. 5. Applicability The data model in a YANG module yields value in five specific areas. 5.1. Device Developer @@ -525,20 +525,22 @@ 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 @@ -568,64 +570,54 @@ 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 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 node 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. + 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. -7. Conclusion - - 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 +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. -9. Normative References +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-00 (work in progress). + NETCONF", draft-ietf-netmod-yang-05 (work in progress). Author's Address Phil Shafer Juniper Networks Email: phil@juniper.net