--- 1/draft-ietf-netmod-arch-09.txt 2010-09-23 21:12:34.000000000 +0200 +++ 2/draft-ietf-netmod-arch-10.txt 2010-09-23 21:12:34.000000000 +0200 @@ -1,48 +1,49 @@ Network Working Group P. Shafer Internet-Draft Juniper Networks -Intended status: Informational September 22, 2010 -Expires: March 26, 2011 +Intended status: Informational September 23, 2010 +Expires: March 27, 2011 An Architecture for Network Management using NETCONF and YANG - draft-ietf-netmod-arch-09 + draft-ietf-netmod-arch-10 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. + The Network Configuration Protocol (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 in full conformance with the provisions of BCP 78 and BCP 79. 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 March 26, 2011. + This Internet-Draft will expire on March 27, 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 @@ -69,27 +70,27 @@ 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 2.3.2. DSDL (Relax NG) . . . . . . . . . . . . . . . . . . . 14 - 2.4. YANG Types . . . . . . . . . . . . . . . . . . . . . . . . 14 + 2.3.2. DSDL (RELAX NG) . . . . . . . . . . . . . . . . . . . 14 + 2.4. YANG Types . . . . . . . . . . . . . . . . . . . . . . . . 15 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. Roles in Building Solutions . . . . . . . . . . . . . . . 20 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 @@ -132,43 +133,45 @@ 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 ([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 ([W3CXSD]) and DSDL ([ISODSDL]) were + languages such as the XML Schema Language (XSD) ([W3CXSD]) and the + Document Schema Definition Languages (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. + 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 + http://www.ietf.org/mail-archive/web/ietf/current/msg51644.html In 2008 and 2009, the NETMOD working group produced a specification for YANG ([RFCYANG]) as a means for defining data models for NETCONF, allowing both standard and proprietary data models to be published in a form that is easily digestible by human readers and satisfies many of the issues raised in the IAB NM workshop. This brings NETCONF to - a point where is can be used to develop standards within the IETF. + a point where is can be used to develop standard data models within + the IETF. YANG allows a modeler to create a data model, to define the organization of the data in that model, and to define constraints on that data. Once published, the YANG module acts as a contract between the client and server, with both parties understanding how their peer will expect them to behave. A client knows how to create valid data for the server, and knows what data will be sent from the server. A server knows the rules that govern the data and how it should behave. @@ -251,21 +254,21 @@ NETCONF defines operations that are invoked as RPCs from the client (the application) to the server (running on the device). The following table lists some of these operations: +---------------+---------------------------------------------------+ | Operation | Description | +---------------+---------------------------------------------------+ | commit | Commits the "candidate" configuration to | | | "running" | | copy-config | Copy one configuration datastore to another | - | delete-config | Delete a portion of a configuration datastore | + | delete-config | Delete 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 @@ -286,23 +289,23 @@ requirements defined in RFC4741, including o connection-oriented operation o authentication o integrity o confidentiality - [RFC4742] defines an mapping for the SSH protocol, which is the - mandatory transport protocol. Others include SOAP ([RFC4743]), BEEP - ([RFC4744]), and TLS ([RFC5539]). + [RFC4742] defines an mapping for the SSH ([RFC4251]) protocol, which + is the mandatory transport protocol. Others include SOAP + ([RFC4743]), BEEP ([RFC4744]), and TLS ([RFC5539]). 2.2. YANG YANG is a data modeling language for NETCONF. It allows the description of hierarchies of data nodes ("nodes") and the constraints that exist among them. YANG defines data models and how to manipulate those models via NETCONF protocol operations. Each YANG module defines a data model, uniquely identified by a namespace URI. These data models are extensible in a manner that @@ -398,23 +401,23 @@ | mandatory | Requires the node appear | | max-elements | Limits the number of instances in a list | | min-elements | Limits the number of instances in a list | | must | XPath expression must be true | | pattern | Regular expression must be satisfied | | range | Value must appear in range | | reference | Value must appear elsewhere in the data | | unique | Value must be unique within the data | | when | Node is only present when XPath expression is true | +--------------+----------------------------------------------------+ - The "must" and "when" statements use XPath expressions to specify - conditions that are semantically evaluated against the data - hierarchy, but neither the client nor the server are required to + The "must" and "when" statements use XPath ([W3CXPATH]) expressions + to specify conditions that are semantically evaluated against the + data hierarchy, but neither the client nor the server are required to implement the XPath specification. Instead they can use any means to ensure these conditions are met. 2.2.2. Flexibility YANG uses the "union" type and the "choice" and "feature" statements to give modelers flexibility in defining their data models. The "union" type allows a single leaf to accept multiple types, like an integer or the word "unbounded": @@ -470,21 +473,22 @@ type empty; description "Don't inform other protocols about" + " neighbor down events"; } } } The element is then placed in the vendorx namespace: - + 0.0.0.0 ge-0/0/0.0 30 @@ -521,26 +526,27 @@ acceptable option. For those scenarios, an XML grammar for YANG is defined as YIN (YANG Independent Notation). 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 integration of a YANG parser. YIN maintains complete semantic equivalence with YANG. -2.3.2. DSDL (Relax NG) +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]). + Description Languages ([RFCYANGDSDL]), of which RELAX NG is a major + component. 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. @@ -686,36 +692,37 @@ 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 access any underlying data directly. o Full coverage: YANG modules can be defined that give full coverage to all the native abilities of the device. Giving this access avoids the need to resort to the command line interface (CLI) - using tools such as Expect. + using tools such as Expect ([SWEXPECT]). o Timeliness: YANG modules can be tied to CLI operations, so all native operations and data are immediately available. o Implementation difficulty: YANG's flexibility enables modules that can be more easily implemented. Adding "features" and replacing "third normal form" with a natural data hierarchy should reduce complexity. o Simple data modeling language: YANG has sufficient power to be usable in other situations. In particular, on-box API and native CLI can be integrated to achieve simplification of the infrastructure. - o Internationalization: YANG uses UTF-8 encoded unicode characters. + o Internationalization: YANG uses UTF-8 ([RFC3629]) encoded unicode + characters. o Event correlation: YANG integrates RPC operations, notification, configuration and state data, enabling internal references. For example, a field in a notification can be tagged as pointing to a BGP peer, and the client application can easily find that peer in the configuration data. o Implementation costs: Significant effort has been made to keep implementation costs as low as possible. @@ -796,27 +803,26 @@ The YANG model can be compiled into a YANG-based engine for either the client or server side. Incoming data can be validated, as can outgoing data. The complete configuration datastore may be validated in accordance with the constraints described in the data model. Serializers and deserializers for generating and receiving NETCONF content can be driven by the meta-data in the model. As data is received, the meta-data is consulted to ensure the validity of incoming XML elements. -3.3.3.2. XML "over the wire" Definitions +3.3.3.2. XML Definitions - The YANG module dictates the XML encoding sent "over the wire", - though actual transmission should be encrypted so as not to appear as - readable text on the physical media. The rules that define the - encoding are fixed, so the YANG module can be used to ascertain - whether a specific NETCONF payload is obeying the rules. + The YANG module dictates the XML encoding for data sent via NETCONF. + The rules that define the encoding are fixed, so the YANG module can + be used to ascertain whether a specific NETCONF payload is obeying + the rules. 3.3.4. Application Developer The YANG module tells the application developer what data can be modeled. Developers can inspect the modules and take one of three distinct views. In this section, we will consider them and the impact of YANG on their design. In the real world, most applications are a mixture of these approaches. 3.3.4.1. Hard Coded @@ -928,21 +934,21 @@ 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 datastore. - The act of setting a leaf to it's default value effectively deletes + The act of setting a leaf to its 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 implementation and deployment costs of YANG-based models. @@ -1196,20 +1202,26 @@ 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. + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) + Protocol Architecture", RFC 4251, January 2006. + [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. [RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access Protocol (SOAP)", RFC 4743, December 2006. @@ -1228,32 +1240,35 @@ 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-06 (work in + NETCONF Content", draft-ietf-netmod-dsdl-map-07 (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-10.txt (work in progress). + [SWEXPECT] + "The Expect Home Page", . + [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.