--- 1/draft-ietf-netmod-arch-07.txt 2010-08-21 00:12:34.000000000 +0200 +++ 2/draft-ietf-netmod-arch-08.txt 2010-08-21 00:12:34.000000000 +0200 @@ -1,18 +1,18 @@ Network Working Group P. Shafer Internet-Draft Juniper Networks -Intended status: Informational June 23, 2010 -Expires: December 25, 2010 +Intended status: Informational August 20, 2010 +Expires: February 21, 2011 An Architecture for Network Management using NETCONF and YANG - draft-ietf-netmod-arch-07 + draft-ietf-netmod-arch-08 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. @@ -28,21 +28,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on December 25, 2010. + This Internet-Draft will expire on February 21, 2011. Copyright Notice 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -64,48 +64,49 @@ it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Origins of NETCONF and YANG . . . . . . . . . . . . . . . 4 2. Elements of the Architecture . . . . . . . . . . . . . . . . . 6 2.1. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.1. NETCONF Transport Mappings . . . . . . . . . . . . . . 8 - 2.2. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 2.2.1. Constraints . . . . . . . . . . . . . . . . . . . . . 10 - 2.2.2. Flexibility . . . . . . . . . . . . . . . . . . . . . 11 + 2.2. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 2.2.1. Constraints . . . . . . . . . . . . . . . . . . . . . 11 + 2.2.2. Flexibility . . . . . . . . . . . . . . . . . . . . . 12 2.2.3. Extensibility Model . . . . . . . . . . . . . . . . . 12 2.3. YANG Translations . . . . . . . . . . . . . . . . . . . . 13 - 2.3.1. YIN . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 2.3.1. YIN . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.2. DSDL (Relax NG) . . . . . . . . . . . . . . . . . . . 14 2.4. YANG Types . . . . . . . . . . . . . . . . . . . . . . . . 14 - 2.5. IETF Guidelines . . . . . . . . . . . . . . . . . . . . . 14 - 3. Working with YANG . . . . . . . . . . . . . . . . . . . . . . 15 - 3.1. Building NETCONF- and YANG-based Solutions . . . . . . . . 15 - 3.2. Addressing Operator Requirements . . . . . . . . . . . . . 16 - 3.3. Roles in Building Solutions . . . . . . . . . . . . . . . 18 - 3.3.1. Modeler . . . . . . . . . . . . . . . . . . . . . . . 19 - 3.3.2. Reviewer . . . . . . . . . . . . . . . . . . . . . . . 19 - 3.3.3. Device Developer . . . . . . . . . . . . . . . . . . . 19 - 3.3.4. Application Developer . . . . . . . . . . . . . . . . 20 - 4. Modeling Considerations . . . . . . . . . . . . . . . . . . . 23 - 4.1. Default Values . . . . . . . . . . . . . . . . . . . . . . 23 - 4.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . . 24 - 4.3. Data Distinctions . . . . . . . . . . . . . . . . . . . . 25 - 4.3.1. Background . . . . . . . . . . . . . . . . . . . . . . 25 - 4.3.2. Definitions . . . . . . . . . . . . . . . . . . . . . 26 - 4.3.3. Implications . . . . . . . . . . . . . . . . . . . . . 27 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 29 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 - 7. Normative References . . . . . . . . . . . . . . . . . . . . . 31 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32 + 2.5. IETF Guidelines . . . . . . . . . . . . . . . . . . . . . 15 + 3. Working with YANG . . . . . . . . . . . . . . . . . . . . . . 16 + 3.1. Building NETCONF- and YANG-based Solutions . . . . . . . . 16 + 3.2. Addressing Operator Requirements . . . . . . . . . . . . . 17 + 3.3. Roles in Building Solutions . . . . . . . . . . . . . . . 19 + 3.3.1. Modeler . . . . . . . . . . . . . . . . . . . . . . . 20 + 3.3.2. Reviewer . . . . . . . . . . . . . . . . . . . . . . . 20 + 3.3.3. Device Developer . . . . . . . . . . . . . . . . . . . 20 + 3.3.4. Application Developer . . . . . . . . . . . . . . . . 21 + 4. Modeling Considerations . . . . . . . . . . . . . . . . . . . 24 + 4.1. Default Values . . . . . . . . . . . . . . . . . . . . . . 24 + 4.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . . 25 + 4.3. Data Distinctions . . . . . . . . . . . . . . . . . . . . 26 + 4.3.1. Background . . . . . . . . . . . . . . . . . . . . . . 26 + 4.3.2. Definitions . . . . . . . . . . . . . . . . . . . . . 27 + 4.3.3. Implications . . . . . . . . . . . . . . . . . . . . . 28 + 4.4. Direction . . . . . . . . . . . . . . . . . . . . . . . . 29 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 30 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 + 7. Normative References . . . . . . . . . . . . . . . . . . . . . 32 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34 1. Introduction 1.1. Origins of NETCONF and YANG 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 @@ -126,32 +127,35 @@ to save and restore the device's configuration data. Many of the observations give insight into the problems operators were having with existing network management solutions, such as the lack of full coverage of device capabilities and the ability to distinguish between configuration data and other types of data. Based on these directions, the NETCONF working group was formed and the Network Configuration (NETCONF) protocol was created. This protocol defines a simple mechanism where network management applications, acting as clients, can invoke operations on the - devices, which act as servers. The NETCONF specification defines a - small set of operations, but goes out of its way to avoid making any - requirements on the data carried in those operations, preferring to - allow the protocol to carry any data. This "data model agnostic" - approach allows data models to be defined independently. + devices, which act as servers. The NETCONF specification ([RFC4741]) + defines a small set of operations, but goes out of its way to avoid + making any requirements on the data carried in those operations, + preferring to allow the protocol to carry any data. This "data model + agnostic" approach allows data models to be defined independently. But lacking a means of defining data models, the NETCONF protocol was not usable for standards-based work. Existing data modeling - languages such as XSD and Relax NG were considered, but were rejected - because the problem domains have little natural overlap. Defining a - protocol which is encoded in XML is a distinct problem from defining - an XML document. + languages such as XSD ([W3CXSD]) and DSDL ([ISODSDL]) were + considered, but were rejected because the problem domains have little + natural overlap. Defining a data model or protocol that is encoded + in XML is a distinct problem from defining an XML document. The use + of NETCONF operations place requirements on the data content that are + not shared with the static document problem domain addressed by + schema languages like XSD or Relax NG. In 2007 and 2008, the issue of a data modeling language for NETCONF was discussed in the OPS and APPS areas of IETF 70 and 71, and a design team was tasked with creating a requirements document (expired I-D draft-presuhn-rcdml-03.txt). After discussing the available options at the CANMOD BoF at IETF71, the community wrote a charter for the NETMOD working group. An excellent description of this time period is available at http://www.mail-archive.com/ietf@ietf.org/msg37006.html @@ -240,34 +244,36 @@ NETCONF includes mechanisms for controlling configuration datastores. Each datastore is a specific collection of configuration data that can be used as source or target of the configuration-related operations. The device can indicate whether it has a distinct "startup" configuration datastore, whether the current or "running" datastore is directly writable, or whether there is a "candidate" configuration datastore where configuration changes can be made that will not affect the device until a "commit-configuration" operation is invoked. - NETCONF defined operations that are invoked as RPCs from the client + NETCONF defines operations that are invoked as RPCs from the client (the application) to the server (running on the device). The - following table lists these operations: + following table lists some of these operations: - +-------------+----------------------------------------------------+ + +---------------+---------------------------------------------------+ | Operation | Description | - +-------------+----------------------------------------------------+ - | commit | Commits the "candidate" configuration to "running" | + +---------------+---------------------------------------------------+ + | commit | Commits the "candidate" configuration to | + | | "running" | | copy-config | Copy one configuration datastore to another | - | edit-config | Change the contents of a configuration database | + | delete-config | Delete a portion of a configuration datastore | + | edit-config | Change the contents of a configuration datastore | | get-config | Retrieve all or part of a configuration datastore | | lock | Prevent changes to a datastore from another party | | unlock | Release a lock on a datastore | - +-------------+----------------------------------------------------+ + +---------------+---------------------------------------------------+ NETCONF's "capability" mechanism allows the device to announce the set of capabilities that the device supports, including protocol operations, datastores, data models, and other abilities. These are announced during session establishment as part of the message. A client can inspect the hello message to determine what the device is capable of and how to interact with the device to perform the desired tasks. NETCONF also defines a means of sending asynchronous notifications @@ -526,24 +531,24 @@ integration of a YANG parser. YIN maintains complete semantic equivalence with YANG. 2.3.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 ([RFCYANGDSDL]). - 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. + DSDL is considered to be the best choice as a standard schema + language because it addresses not only grammar and datatypes of XML + documents but also semantic constraints and rules for modifying the + 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. 2.4. 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 @@ -601,40 +606,40 @@ | | base | |component||| | | +--------+ +---------+|| | | +---------+| | | +---------+ | +----------------------------+ To use YANG, YANG modules must be defined to model the specific problem domain. These modules are then loaded, compiled, or coded into the server. - The sequence of events for the typical client/server interaction is - as follows: + The sequence of events for the typical client/server interaction may + be as follows: o A client application ([C]) opens a NETCONF session to the server (device) ([S]) o [C] and [S] exchange messages containing the list of capabilities supported by each side, allowing [C] to learn the modules supported by [S] o [C] builds and sends an operation defined in the YANG module, encoded in XML, within NETCONF's element o [S] receives and parses the element o [S] verifies the contents of the request against the data model defined in the YANG module o [S] performs the requested operation, possibly changing the - configuration database + configuration datastore o [S] builds the response, containing the response, any requested data, and any errors o [S] sends the response, encoded in XML, within NETCONF's element o [C] receives and parses the element o [C] inspects the response and processes it as needed @@ -642,42 +647,47 @@ Note that there is no requirement for the client or server to process the YANG modules in this way. The server may hard code the contents of the data model, rather than handle the content via a generic engine. Or the client may be targeted at the specific YANG model, rather than being driven generically. Such a client might be a simple shell script that stuffs arguments into an XML payload template and sends it to the server. 3.2. Addressing Operator Requirements - YANG addresses many of the issues raised in the IAB NM workshop. + NETCONF and YANG address many of the issues raised in the IAB NM + workshop. o Ease of use: YANG is designed to be human friendly, simple and readable. Many tricky issues remain due to the complexity of the problem domain, but YANG strives to make them more visible and easier to deal with. o Configuration and state data: YANG clearly divides configuration data from other types of data. o Transactions: NETCONF provides a simple transaction mechanism. o Generation of deltas: A YANG module gives enough information to generate the delta needed to change between two configuration data sets. o Dump and restore: NETCONF gives the ability to save and restore configuration data. This can also performed for a specific YANG module. o Network-wide configuration: NETCONF supports robust network-wide - configuration transactions via the confirmed-commit capability. + configuration transactions via the commit and confirmed-commit + capability. When a change is attempted that affects multiple + devices, these capabilities simplifies the management of failure + scenarios, resulting in the ability to have transactions that will + dependably succeed or fail atomically. o Text-friendly: YANG modules are very text friendly, as is the data they define. o Configuration handling: NETCONF addresses the ability to distinguish between distributing configuration data and activating it. o Task-oriented: A YANG module can define specific tasks as RPC operations. A client can choose to invoke the RPC operation or to @@ -711,21 +721,22 @@ o Implementation costs: Significant effort has been made to keep implementation costs as low as possible. o Human friendly syntax: YANG's syntax is optimized for the reader, specifically the reviewer on the basis that this is the most common human interaction. o Post-processing: Use of XML will maximize the opportunities for post-processing of data, possibly using XML-based technologies - like XPath, XQuery, and XSLT. + like XPath ([W3CXPATH], XQuery ([W3CXQUERY]), and XSLT + ([W3CXSLT]). o Semantic mismatch: Richer, more descriptive data models will reduce the possibility of semantic mismatch. With the ability to define new primitives, YANG modules will be more specific in content, allowing more enforcement of rules and constraints. o Security: NETCONF runs over transport protocols secured by SSH or TLS, allowing secure communications and authentication using well- trusted technology. The secure transport can use existing key and credential management infrastructure, reducing deployment costs. @@ -919,21 +930,21 @@ data tree with the default value as its value". This gives the device implementation choices in how default values are handled. One choice is to view the configuration as a set of instructions for how the device should be configured. If a data value that is given as part of those instructions is the default value, then it should be retained as part of the configuration, but if it is not explicitly given, then the value is not considered to be part of configuration. Another choice is to trim values that are identical to the default - values, implicitly removing them from the configuration database. + values, implicitly removing them from the configuration datastore. The act of setting a leaf to it's default value effectively deletes that leaf. The device could also choose to report all default values, regardless of whether they were explicitly set. This choice eases the work of a client that needs default values, but may significantly increase the size of the configuration data. These choices reflect the default handling schemes of widely deployed networking devices and supporting them allows YANG to reduce @@ -1149,31 +1160,56 @@ operation). 4.3.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. +4.4. Direction + + At this time, the only viable solution is to distinctly model the + configuration and operational values. The configuration leaf would + indicate the desired value, as given by the user, and the operational + leaf would indicate the current value, as observed on the device. + + In the duplex example, this would result in two distinct leafs being + defined, "duplex" and "op-duplex", one with "config true" and one + with "config false". + + In some cases, distinct leafs would be used, but in others, distinct + lists might be used. Distinct lists allows the list to be organized + in different ways, with different constraints. Keys, sorting, and + constraint statements like must, unique, or when may differ between + configuration data and operational data. + + For example, configured static routes might be a distinct list from + the operational routing table, since the use of keys and sorting + might differ. + 5. Security Considerations This document discusses an architecture for network management using NETCONF and YANG. It has no security impact on the Internet. 6. IANA Considerations This document has no actions for IANA. 7. Normative References + [ISODSDL] International Organization for Standardization, "Document + Schema Definition Languages (DSDL) - Part 1: Overview", + ISO/IEC 19757-1, November 2004. + [RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network Management Workshop", RFC 3535, May 2003. [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. [RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Secure SHell (SSH)", RFC 4742, December 2006. @@ -1185,38 +1221,58 @@ December 2006. [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008. [RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", RFC 5539, May 2009. [RFCWITHDEFAULTS] Bierman, A. and B. Lengyel, "With-defaults capability for - NETCONF", draft-ietf-netconf-with-defaults-09.txt (work in + NETCONF", draft-ietf-netconf-with-defaults-11.txt (work in progress). [RFCYANG] Bjorklund, M., Ed., "YANG - A data modeling language for the Network Configuration Protocol (NETCONF)", draft-ietf-netmod-yang-13 (work in progress). [RFCYANGDSDL] Lhotka, L., Mahy, R., and S. Chishom, "Mapping YANG to Document Schema Definition Languages and Validating - NETCONF Content", draft-ietf-netmod-dsdl-map-05 (work in + NETCONF Content", draft-ietf-netmod-dsdl-map-06 (work in progress). [RFCYANGTYPES] Schoenwaelder, J., "Common YANG Data Types", draft-ietf-netmod-yang-types-09.txt (work in progress). [RFCYANGUSAGE] Bierman, A., "Guidelines for Authors and Reviewers of YANG - Data Model Documents", draft-ietf-netmod-yang-usage-05.txt + Data Model Documents", draft-ietf-netmod-yang-usage-10.txt (work in progress). + [W3CXPATH] + DeRose, S. and J. Clark, "XML Path Language (XPath) + Version 1.0", World Wide Web Consortium + Recommendation REC-xpath-19991116, November 1999, + . + + [W3CXQUERY] + Boag, S., "XQuery 1.0: An XML Query Language", W3C WD WD- + xquery-20050915, September 2005. + + [W3CXSD] Walmsley, P. and D. Fallside, "XML Schema Part 0: Primer + Second Edition", World Wide Web Consortium + Recommendation REC-xmlschema-0-20041028, October 2004, + . + + [W3CXSLT] Clark, J., "XSL Transformations (XSLT) Version 1.0", World + Wide Web Consortium Recommendation REC-xslt-19991116, + November 1999, + . + Author's Address Phil Shafer Juniper Networks Email: phil@juniper.net