--- 1/draft-ietf-netmod-arch-04.txt 2010-04-19 10:11:15.000000000 +0200 +++ 2/draft-ietf-netmod-arch-05.txt 2010-04-19 10:11:15.000000000 +0200 @@ -1,18 +1,18 @@ Network Working Group P. Shafer Internet-Draft Juniper Networks -Intended status: Informational March 8, 2010 -Expires: September 9, 2010 +Intended status: Informational April 16, 2010 +Expires: October 18, 2010 An NETCONF- and NETMOD-based Architecture for Network Management - draft-ietf-netmod-arch-04 + draft-ietf-netmod-arch-05 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. @@ -34,21 +34,21 @@ 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 9, 2010. + This Internet-Draft will expire on October 18, 2010. 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 @@ -77,41 +77,42 @@ 2.1. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2.1. Constraints . . . . . . . . . . . . . . . . . . . . . 10 2.2.2. Flexibility . . . . . . . . . . . . . . . . . . . . . 11 2.2.3. Extensibility Model . . . . . . . . . . . . . . . . . 11 2.3. YANG Technologies . . . . . . . . . . . . . . . . . . . . 13 2.3.1. YIN . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.2. DSDL (Relax NG) . . . . . . . . . . . . . . . . . . . 13 2.4. YANG Types . . . . . . . . . . . . . . . . . . . . . . . . 14 3. Working with YANG . . . . . . . . . . . . . . . . . . . . . . 15 - 3.1. Addressing Operator Problems . . . . . . . . . . . . . . . 15 - 3.2. Building YANG-based Solutions . . . . . . . . . . . . . . 17 - 3.3. Modeler . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 3.4. Reviewer . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 3.5. Device Developer . . . . . . . . . . . . . . . . . . . . . 17 - 3.5.1. Generic Content Support . . . . . . . . . . . . . . . 17 - 3.5.2. XML "over the wire" Definitions . . . . . . . . . . . 18 - 3.6. Application Developer . . . . . . . . . . . . . . . . . . 18 - 3.6.1. Hard Coded . . . . . . . . . . . . . . . . . . . . . . 18 - 3.6.2. Bottom Up . . . . . . . . . . . . . . . . . . . . . . 18 - 3.6.3. Top Down . . . . . . . . . . . . . . . . . . . . . . . 19 - 4. Modeling Considerations . . . . . . . . . . . . . . . . . . . 21 - 4.1. Default Values . . . . . . . . . . . . . . . . . . . . . . 21 - 4.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . . 21 - 4.3. Data Distinctions . . . . . . . . . . . . . . . . . . . . 22 - 4.3.1. Background . . . . . . . . . . . . . . . . . . . . . . 22 - 4.3.2. Definitions . . . . . . . . . . . . . . . . . . . . . 22 - 4.3.3. Implications . . . . . . . . . . . . . . . . . . . . . 24 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 - 6. Normative References . . . . . . . . . . . . . . . . . . . . . 26 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 3.1. Building YANG-based Solutions . . . . . . . . . . . . . . 15 + 3.2. Addressing Operator Problems . . . . . . . . . . . . . . . 16 + 3.3. Building YANG-based Solutions . . . . . . . . . . . . . . 18 + 3.4. Modeler . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 3.5. Reviewer . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 3.6. Device Developer . . . . . . . . . . . . . . . . . . . . . 19 + 3.6.1. Generic Content Support . . . . . . . . . . . . . . . 19 + 3.6.2. XML "over the wire" Definitions . . . . . . . . . . . 20 + 3.7. Application Developer . . . . . . . . . . . . . . . . . . 20 + 3.7.1. Hard Coded . . . . . . . . . . . . . . . . . . . . . . 20 + 3.7.2. Bottom Up . . . . . . . . . . . . . . . . . . . . . . 20 + 3.7.3. Top Down . . . . . . . . . . . . . . . . . . . . . . . 21 + 4. Modeling Considerations . . . . . . . . . . . . . . . . . . . 23 + 4.1. Default Values . . . . . . . . . . . . . . . . . . . . . . 23 + 4.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . . 24 + 4.3. Data Distinctions . . . . . . . . . . . . . . . . . . . . 24 + 4.3.1. Background . . . . . . . . . . . . . . . . . . . . . . 25 + 4.3.2. Definitions . . . . . . . . . . . . . . . . . . . . . 25 + 4.3.3. Implications . . . . . . . . . . . . . . . . . . . . . 27 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28 + 6. Normative References . . . . . . . . . . . . . . . . . . . . . 29 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30 1. Origins of 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 meet the stability needs of existing services while incorporating new services in a world where the growth of networks is exhausting the @@ -128,41 +129,50 @@ operator's needs were reasonable and straight forward, including the need for transactions, rollback, low implementation costs, and the ability 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 NETCONF protocol was created. This protocol defines a simple - RPC-based 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. + 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. 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 an - RPC which is encoded in XML is a distinct problem from defining an - XML document. + 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. - In early 2005, the NETMOD working group embraced 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 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. + 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 + + 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 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. 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. @@ -177,26 +187,27 @@ related technologies work and how solutions built on them can address the network management problem domain. 2. Elements of YANG 2.1. NETCONF YANG is focused on creating data models for NETCONF, and any understanding of the former must begin with the latter. - NETCONF defines an XML-based RPC mechanism that leverages the - simplicity and availability of high-quality XML parsers. XML gives a - rich, flexible, hierarchical, standard representation of data that - matches the needs of networking devices. NETCONF carries - configuration data and operations encoded in XML using an RPC - mechanism over a connection-oriented transport. + NETCONF defines an XML-based remote procedure call (RPC) mechanism + that leverages the simplicity and availability of high-quality XML + parsers. XML gives a rich, flexible, hierarchical, standard + representation of data that matches the needs of networking devices. + NETCONF carries configuration data and operations as requests and + replies using RPCs encoded in XML over a connection-oriented + transport. XML's hierarchical data representation allows complex networking data to be rendered in a natural way. For example, the following configuration places interfaces in OSPF areas. The element contains a list of elements, each of which contain a list of elements. The element identifies the specific area or interface. Additional configuration for each area or interface appears directly inside the appropriate element. @@ -271,32 +282,31 @@ leaf name { type nett:area-id; } list interface { key name; leaf name { type nett:interface-name; } leaf priority { description "Designated router priority"; - type uint { // The type and range are - range 0..255; // constraints on valid - } // values for "priority". + type uint8; // The type is a constraint on + // valid values for "priority". } leaf metric { - type uint { + type uint16 { range 1..65535; } } leaf dead-interval { units seconds; - type uint { + type uint16 { range 1..65535; } } } } } } A YANG module defines a data model in terms of the data, its hierarchical organization, and the constraints on that data. YANG @@ -476,21 +486,21 @@ 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) 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 (DSDL) [DSDL]. + Description Languages ([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. @@ -500,21 +510,105 @@ 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 [RFCYANGTYPES]. These YANG modules define commonly used data types for IETF-related standards. 3. Working with YANG -3.1. Addressing Operator Problems +3.1. Building YANG-based Solutions + + In the typical YANG-based solution, the client and server are driven + by the content of YANG modules. The server includes the definitions + of the modules as meta-data that is available to the NETCONF engine. + This engine processes incoming requests, uses the meta-data to parse + and verify the request, performs the requested operation, and returns + the results to the client. + + +----------------------------+ + |Server (device) | + | +--------------------+ | + | | configuration | | + +----+ | | ---------------| | + |YANG|+ | | m d state data | | + |mods||+ | | e a ---------------| | + +----+|| -----> | t t notifications | | + +----+| | | a a ---------------| | + +----+ | | operations | | + | +--------------------+ | + | ^ | + | | | + | v | + +------+ | +-------------+ | + | | -------------> | | | + |Client| | | NETCONF | | + | (app)| | | engine | | + | | <------------ | | | + +------+ +-------------+ | + | / \ | + | / \ | + | / \ | + | +--------+ +---------+ | + | | config | |system |+ | + | | data- | |software ||+ | + | | 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: + + 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 defined + in the YANG module + + o [S] performs the requested operation, possibly changing the + configuration database + + 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 + + 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 and + sends it to the server. + +3.2. Addressing Operator Problems YANG addresses 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 Operational data: YANG clearly divides configuration data from other types of data. @@ -594,152 +688,159 @@ mechanisms when the connection is lost. o Delta friendly: YANG-based models support operations that are delta friendly. Add, change, insert, and delete operations are all well defined. o Method-oriented: YANG allows new NETCONF RPCs to be defined, including an operation name, which is essentially a method. The RPC's input and output data are also defined in the YANG module. -3.2. Building YANG-based Solutions +3.3. Building YANG-based Solutions Building YANG-based solutions requires interacting with many distinct groups. Modelers must understand how to build useful models that give structure and meaning to data while maximizing the flexibility of that data to "future proof" their work. Reviewers need to quickly determine if that structure is accurate. Device developers need to code that data model into their devices, and application developers need to code their applications to take advantage of that data model. There are a variety of strategies for performing each piece of this work. This section discusses some of those strategies. -3.3. Modeler +3.4. Modeler - (No clue what needs said here; lots to say, but what's important?) + The modeler's role constructing a model based on their in-depth + knowledge of the problem domain being modeled. This model should be + as simple as possible, but should balance complexity with + expressiveness. The organization of the model should target not only + the current model, but should allow for extensibility from other + modules and for adaptability to future changes. Additional modeling issues are discussed in Section 4. -3.4. Reviewer +3.5. Reviewer The reviewer role is perhaps the more important and the time reviewers are willing to give is precious. To help the reviewer, YANG stresses readability, with a human-friendly syntax, natural data hierarchy, and simple, concise statements. In addition, reviewers can encode review policies in scripts, such as XSLT. A policy that leaf names can't have underscores can be coded as: Error: leaf name contains underscore -3.5. Device Developer +3.6. Device Developer The YANG model tells the device developer what data is being modeled. The developer reads the YANG models, absorbs the zen of the model, and writes code that supports the model. The model describes the data hierarchy and associated constraints, and the description and reference material helps the developer understand how to transform the models view into the device's native implementation. -3.5.1. Generic Content Support +3.6.1. Generic Content Support 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.5.2. XML "over the wire" Definitions +3.6.2. XML "over the wire" 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. -3.6. Application Developer +3.7. 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.6.1. Hard Coded +3.7.1. Hard Coded An application can be coded against the specific, well-known contents of YANG modules, implementing their organization, rules, and logic directly with explicit knowledge. For example, a script could be written to change the domain name of a set of devices using a standard YANG module that includes such a leaf node. This script takes the new domain name as an argument and inserts it into a string containing the rest of the XML encoding as required by the YANG module. This content is then sent via NETCONF to each of the devices. This type of application is useful for small, fixed problems where the cost and complexity of flexibility is overwhelmed by the ease of hard coding direct knowledge into the application. -3.6.2. Bottom Up +3.7.2. Bottom Up An application may take a generic, bottom up approach to configuration, concentrating on the device's data directly and 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 XML hierarchy. 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. -3.6.3. Top Down +3.7.3. Top Down In contrast to the bottom-up approach, the top-down approach allows the application to take a view of the configuration data which is distinct from the standard and/or proprietary YANG modules. The application is free to construct its own model for data organization and to present this model to the user. When the application needs to transmit data to a device, the application transforms its data from the problem-oriented view of the world into the data needed for that particular device. This transformation is under the control and maintenance of the application, allowing the transformation to be changed and updated without affecting the device. For example, an application could be written that models VPNs in a network-oriented view. The application would need to transform these high-level VPN definitions into the configuration data that would be handed to any particular device within a VPN. Even in this approach, YANG is useful since it can be used to model - the VPN. + the VPN. For example, the following VPN straw-man models a list of + VPNs, each with a protocol, a topology, a list of member interfaces, + and a list of classifiers. - list vpn { + list ietf-bgpvpn { key name; leaf name { ... } - leaf type { + leaf protocol { type enumeration { enum bgpvpn; enum l2vpn; } } leaf topology { type enumeration { enum hub-n-spoke; enum mesh; } @@ -750,33 +851,74 @@ leaf interface { ... } } list classifiers { ... } } The application can use such a YANG module to drive its operation, building VPN instances in a database and then pushing the configuration for those VPNs to individual devices uses either a - standard device model (e.g. bgp.yang) or by transforming that + standard device model (e.g. ietf-bgpvpn.yang) or by transforming that standard device content into some proprietary format for devices that do not support that standard. 4. Modeling Considerations This section discusses considerations the modeler should be aware of while developing models in YANG. 4.1. Default Values - (With all the discussion on this point, it needs to be mentioned - here.) + The concept of default values is simple, but their details, + representation, and interaction with configuration data can be + difficult issues. NETCONF leaves default values as a data model + issue, and YANG gives flexibility to the device implementation in + terms of how default values are handled. The requirement is that the + device "MUST operationally behave as is if the leaf was present in + the 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 is given as + part of those instructions is the default value, then it should be + retained as part of the configuration, but if it 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. + 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 + implementation and deployment costs of YANG-based models. + + When the client retrieves data from the device, it must be prepared + to handle the absence of leaf nodes with the default value, since the + server is not required to send such leaf elements. This permits the + device to implement either of the first two default handling schemes + given above. + + Regardless of the implementation choice, the device can support the + "with-defaults" capability ([RFCWITHDEFAULTS]) and give the client + the ability to select the desired handling of default values. + + When evaluating the XPath expressions for constraints like "must" and + "when", the evaluation context for the expressions will include any + appropriate default values, so the modeler can depend on consistent + behavior from all devices. 4.2. Compliance In developing good data models, there are many conflicting interests the data modeler must keep in mind. Modelers need to be aware of four types of behavior in modeled device: o [strict compliance] behavior that follow the model completely o [modeled deviations] behavior that follows within deviations @@ -948,26 +1090,34 @@ determining the behaviour of the box instead of its static and explicit configuration state. 5. Security Considerations This document discusses data modeling using YANG, and has no security impact on the Internet. 6. Normative References + [DSDL] International Organization for Standardization, "DSDL Part + 0 - Overview", ISO DSDL, December 2001. + [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. + [RFCWITHDEFAULTS] + Bierman, A. and B. Lengyel, "With-defaults capability for + NETCONF", draft-ietf-netconf-with-defaults-05.txt (work in + progress). + [RFCYANG] Bjorklund, M., Ed., "YANG - A data modeling language for NETCONF", draft-ietf-netmod-yang-11 (work in progress). [RFCYANGTYPES] Schoenwaelder, J., Ed., "Common YANG Data Types", draft-ietf-netmod-yang-types-07.txt (work in progress). Author's Address Phil Shafer