Internet Engineering Task Force R. Cole Internet-Draft Johns Hopkins University Intended status: Informational D. Romascanu Expires: August 30, 2009 Avaya February 26, 2009 Robust Configuration Management within NETCONF draft-cole-netconf-robust-config-00 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. 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." 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 August 30, 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. Abstract The IETF has developed a new configuration management protocol, Cole & Romascanu Expires August 30, 2009 [Page 1] Internet-Draft Robust Management February 2009 NETCONF. NETCONF has defined a capability called ':confirmed-commit' which allows a management application time to build confidence in desired configuration changes prior to the managed device committing to the changes. However, NETCONF does not define methods to build this confidence in configuration changes, nor does it afford the remote managed device the opportunity to actively participate in the test and evaluation phase of the ':confirmed-commit' capability. We believe that this capability should be further developed to afford network management applications and managed devices a more robust and resilient configuration management capability, which is of value to commercial enterprise and public networks as well as wireless emergency and military networks. We explore the alternatives for enhancing this capability within the context of the existing NETCONF protocol, the YANG modeling language and existing related IETF standards. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. Objectives and Benefits . . . . . . . . . . . . . . . . . . . 5 3. Background Capabilities . . . . . . . . . . . . . . . . . . . 6 3.1. NETCONF Capabilities . . . . . . . . . . . . . . . . . . . 6 3.2. YANG Capabilities . . . . . . . . . . . . . . . . . . . . 7 3.3. RMON Capabilities . . . . . . . . . . . . . . . . . . . . 8 4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Challenges . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Cole & Romascanu Expires August 30, 2009 [Page 2] Internet-Draft Robust Management February 2009 1. Introduction This report lays out our initial thoughts on the use NETCONF and NETMOD capabilities and enhancements to each to achieve a more robust model of configuration management for IETF systems. Most network management systems which are required to provide a highly robust network service rely upon some form of out-of-band access for configuration management. This provides an alternative management entry into devices in the event that in-band access is unavailable due to mis-configuration. However, not all network deployments can afford the luxury of alternative networks for management access to all networking devices, nor should this be necessary. Examples include Mobile Ad-Hoc Wireless Networks (MANETs) and other forms of Disruption Tolerant Networks (DTNs). All managed networks, as well, would benefit from a more robust configuration management capability from the IETF, e.g., to provide equivalent network reliability at reduced infrastructure costs. The NETCONF protocol goes a long way towards realizing this goal. We explore possible extensions to improve upon existing capabilities. The NETCONF protocol is intended to replace the SNMP protocol for configuration management applications. The NETCONF protocol supports a set of configuration operations, including o , o , o , o ...., o . For devices advertising the optional capability, the device may then support the ':confirmed-commit' capability within the operation. Parameter values for the operation then include 'confirmed' and 'confirmed-timeout'. The 'confirmed-timeout' allows the server to perform a validation on the requested (new) configuration and to commit only if the validation tests and checks succeed. However, NETCONF does not specify or recommend the tests or checks to be performed, nor does it allow the remote managed device to actively participate in the test phase of the 'commit' then 'test' then 'confirmed-commit' procedure. We suggest that improved robustness and resilience in configuration management can be achieved by defining capabilities for the managed devices to actively participate in the test phase of these procedures. Cole & Romascanu Expires August 30, 2009 [Page 3] Internet-Draft Robust Management February 2009 None the less, the NETCONF protocol is defined to provide a set of operations and optional capabilities which afford applications a configuration framework significantly improved over previous capabilities of SNMP-based configuration management. Specifically, as described in Appendix D of NETCONF RFC 4741 [RFC4741], the following client (application) to server (device) procedure is possible within NETCONF: 1. Acquire a configuration 'lock' - prevent other applications from simultaneously modifying the same sections of the device configuration. 2. Load configuration update - move the desired new configuration to the managed device. 3. Validate configuration (syntax) - perform a syntax check on the new configuration code. 4. Checkpoint the configuration - save the old configuration in case the device needs to back out of the desired changes. 5. Change the configuration - move the proposed configuration changes over to the configuration using, e.g., the ':confirmed-commit' capability. 6. Test the new configuration - within the time limits set in the ':confirmed-commit' the application can perform a set of tests, e.g., 'ping', or inferential checks, e.g., pull routing information from the device or peers, to build some confidence in the proposed configuration changes. If the application is not satisfied with the tests and checks available to it, it can withhold the 'confirming-commit' forcing the device to back out of the desired configuration changes. 7. Make the changes permanent (if desired) - 8. Release the configuration 'lock' - This represents an significant step forward from a reliance upon SNMP for configuration management. However, further improvements are desirable, specifically in the definition and automation of tests associated with Step 6 above. Herein lies our interests and the focus of the framework discussion outlined in this report. Further, with respect to the above procedure, extensions to network-wide configuration changes are limited to a simultaneous parallel repetition for each network device. This may prove awkward for large numbers of devices. Whereas, an enhanced testing capability may Cole & Romascanu Expires August 30, 2009 [Page 4] Internet-Draft Robust Management February 2009 result in improved methods and procedures for network-wide configuration updates. This is an area for future studies. In this report we explore the possible set of extensions to the NETCONF protocol and its associated modeling language, YANG YANG [yang], to accomplish an automation of tests performed from managed devices and tied to configuration changes to afford a more robust and resilient configuration management capability within the IETF. We examine the options for test specifications, test types, and test success definitions within existing standards. We identify areas within NETCONF and YANG where enhancements are required, e.g.,new error messages and definitions. We also discuss potential security issues associated with the development of a more automated testing associated with the ':confirmed-commit' capability. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Objectives and Benefits Our objective is to further develop a robust and resilient network configuration capability, building upon the improvements afforded by the NETCONF protocol and it's associated modeling language, YANG. NETCONF gives a management application the ability to instruct a managed device to temporarily change its configuration, wait a specified time, the 'confirm-timeout' parameter, while the application performs a set of tests and checks prior to instructing the device to commit to the change by issuing the 'confirmed-commit' operation. We propose to define methods to explicitly define tests operating on the remote device in order to give the collective management application and managed devices improved confidence in the correctness of the desired changes prior to committing to them. By moving the test capabilities to the remote devices themselves, a more reliable set of tests can be performed. Full-proof tests of proposed configuration changes need to be performed within the same context of the intended use of the network, its devices and their configuration. Running tests from the application or performing checks of device state, are not always strong tests of the viability of configuration changes but instead are often inferential in nature. Further, by providing methods to specify tests, one can envision the device modeler explicitly associating tests to configured objects through the managed device modeling language affording network management applications access to the expertise of the expert-matter device modelers. Cole & Romascanu Expires August 30, 2009 [Page 5] Internet-Draft Robust Management February 2009 There are advantageous to placing the test capabilities on the remote managed device as opposed to relying upon the remote management application to test, probe and infer the state of the network. For example, information can flow over paths for which data transport is not possible. This can occur due to asymmetric links, mis- configuration of control and data protocols, mis-configured security filters allowing control but not data traffic, etc. The best way to test correctness of configuration is from the perspective of the managed device itself and the specific configuration objects affected. The envisioned benefits of better specification of testing and extending the tests to the managed devices themselves include: o Minimize faulty configuration, o Minimize disconnects in networks with no 'out-of-band' access, e.g., wireless MANETs or DTNs o Provide opportunity for device modelers to associate/recommend tests tied to specific configuration items. o Potentially improve coordinated network upgrades. 3. Background Capabilities In this section we identify some existing protocol capabilities which may play a role in extending NETCONF testing capabilities and specifications for improved configuration management. 3.1. NETCONF Capabilities Here we highlight existing NETCONF mechanisms associated with checking configuration changes prior to committing to those changes. We conclude this section with a potential list of extensions to NETCONF which may be necessary to accomplish improved configuration checking. NETCONF devices can advertise capabilities upon initial session establishments. One capability is the ':validate' capability. When implementing the :validate capability, the device ``checks at least for syntax error ...'' (reference NETCONF). This level of checking can be tied directly to the operation through the operation test-option: 'test-then-set' if the device advertises :validate capability (NETCONF sect 8.6). This forces the device to perform syntax checking during the operation. Cole & Romascanu Expires August 30, 2009 [Page 6] Internet-Draft Robust Management February 2009 A further NETCONF capability is the ':confirmed-commit' capability. This allows the application to instruct the device through the optional operation's parameters, 'confirmed' and 'confirmed- timeout', to run the desired configuration changes for a period of time, until it either receives a 'confirming commit' from the application and commits, or times out and reverts back to the prior configuration. This gives the application time to perform a set of tests and checks to build confidence in the desired changes prior to instructing to commit. The following enhancements are in consideration for improved testing and checking functionality: o Enhance the operation to include a greater set of checks on the proposed configuration. These may include specifying tests through reference, i.e., URI, or through explicit device models, e.g, constraint checks defined through YANG. o Enhance the 'confirmed commit' capability to pass specific tests for the remote managed device to run prior to allowing the 'confirming commit' to occur. This would also require a method to specific the success criteria associated with the specified tests. The tests and their success criteria could be specified by reference, e.g., URI, or by explicit definitions, e.g., YANG, or by other means. o Enhance the device capabilities to play a role in the confirmed commitment phase of the configuration change procedures. 3.2. YANG Capabilities In this section discuss relevant aspects of the YANG modeling language. We conclude this sections by identifying some areas for potential enhancements to YANG or new applications of the existing YANG language. The YANG 'must' statement extends the :validate capability beyond simple syntax checking by including checking of 'must' constraints specified in the device model through YANG. (YANG sect 7.5.2) ``.. when a configuration data-store is validated, all 'must' constraints (defining necessary relationships between device configuration parameter values) are conceptually evaluated ...''. Further, (YANG sect 7.5.2) ``.. all such constraints must evaluate to true ..'' prior to setting the new configuration. YANG, as a device modeling language, could be used to define an extensible set of tests through a specific test device model akin to the SSPM-MIB RFC 4149 [RFC4149] defined within RMON RFC 3577 Cole & Romascanu Expires August 30, 2009 [Page 7] Internet-Draft Robust Management February 2009 [RFC3577]. This would allow specific tests to be indicated from the application to the device associated with specific configuration changes. The SSPM-MIB relies upon extensible methods (described below) to define broad sets of network tests. YANG, as a device modeling language, could be used to associate within the device model itself, tests explicitly associated with configuration objects within the device model. This would afford the device modelers the ability to recommend associated (optional) tests tied to desired object changes. Likely, associated success criteria would need to be modeled as well. YANG, as a device modeling language, could be used to specify references to associated tests and test success criteria, e.g., through URIs. See YANG [yang] for more information. The following enhancements or work items are in consideration: o There may be additional relevant YANG extensions (YANG sect 7.17) to define further NETCONF ':validate' procedure similar to the already defined constraints checking. o YANG models may be required to define extensible network tests. o Future YANG device models may contain test definitions and success criteria or references to these. 3.3. RMON Capabilities RMON RFC 3577 [RFC3577] defined a set of capabilities related to definition and execution of network tests which may be valuable to this discussion. Refer to RFC 2074 [RFC2074], RFC 3729 [RFC3729], RFC 4149 [RFC4149], and RFC 4150 [RFC4150] for further information. The RMON 'protocol-ID' and AppLocalIndex (APM-MIB) RFC 3729 [RFC3729] define an extensible method to specify application/protocol network transactions. These have proven useful in the definition of network monitoring and reporting and in the specification of specific network-level active tests. These constructs can be moved forward into YANG models to provide similar benefits in the context of NETCONF configuration management. RMON Synthetic Sources for Performance Management MIB (SSPM-MIB) RFC 4149 [RFC4149] uses AppLocalIndex to define network measurements and remotely instrument such measurements. SSPM-MIB does not specify success criteria, i.e., ``What constitutes success''. This model can Cole & Romascanu Expires August 30, 2009 [Page 8] Internet-Draft Robust Management February 2009 be defined within YANG and enhanced to potentially incorporate success criteria along with the test specification. SSPM-MIB does not report measurements; these are collected via APM-MIB RFC 3729 [RFC3729] and TPM-MIB RFC 4150 [RFC4150]. Collectively, this capability set may need to be carried forward. RMON developed the control table and report table constructs. These allow a management application to instruct a remote device to monitor specific performance objects and to construct reports which can be collected in bulk at a later time. This capability may be desirable in the development of tests and reports to influence the ':confirmed- commit' capability in NETCONF. 4. Framework Here we collect our thoughts on the development of an enhanced ':confirmed-commit' capability within NETCONF. Enhancements are probable not confined to NETCONF but may also include enhancements to YANG, or at least the development of new device models within YANG. We propose to enhance/develop the NETCONF ':confirmed-commit' capability to: o Specify a set of tests associated with specific configuration modifications. (Multiple methods are possible and under consideration, see below.) o One specific class of tests would be network tests (network test imply a set of active measurement probes injected into the network). This class of tests may provide our first set of work tasks. o Define a set of pass/fail criteria. There exist several options for the method to specify tests and their associated pass/fail criteria. Potential specification options include: o Local or remote script specifications, i.e., passes an URL pointing to the script and passes a specification of 'success'. o Tests can be separately specified via a modeling language, similar to SSPM-MIB (for network test specification) but using YANG, and passed with the operation. Cole & Romascanu Expires August 30, 2009 [Page 9] Internet-Draft Robust Management February 2009 o Tests are associated with specific configuration objects within the device's (YANG) model. The module developer passes their expertise on to the network configuration process by ``recommending'' specific tests tied to specific configuration objects. Success criteria, but not specific values, are defined in module. Specific values for success criteria may be passed through, e.g., operations. Several objectives will be developed to help direct decisions as this proposal moves forward. We list a set here, but expect these to evolve over the future revisions of the framework draft. These include: o Improve the verify prior to commit capability in NETCONF by developing a local-to-the-device automated test capability. o Leverage existing capabilities within NETCONF, YANG and other IETF standards where possible. o Consider enhancements which potentially simplify network-wide configuration upgrades as outlined in Appendix D of NETCONF. 4.1. Challenges We conclude this report with a brief discussion of the major challenges to performing and completing this work program. Currently identified challenges are: o Identifying methods to specify specific tests in a simple yet extensible fashion. o Can and should specific tests be tied to specific configuration parameters within the device's data model? o What are the security implications of this work and what security mechanisms need development? 5. Acknowledgements 6. IANA Considerations This memo includes no request to IANA. All drafts are required to have an IANA considerations section (see the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis] for a guide). If the draft does not require IANA to do anything, the Cole & Romascanu Expires August 30, 2009 [Page 10] Internet-Draft Robust Management February 2009 section contains an explicit statement that this is the case (as above). If there are no requirements for IANA, the section will be removed during conversion into an RFC by the RFC Editor. 7. Security Considerations All drafts are required to have a security considerations section. See RFC 3552 [RFC3552] for a guide. This section addresses the security concerns and objectives for the development of a more robust ':confirmed-commit' capability within NETCONF. This section is currently TBD. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [I-D.narten-iana-considerations-rfc2434bis] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", draft-narten-iana-considerations-rfc2434bis-09 (work in progress), March 2008. [RFC2074] Bierman, A. and R. Iddon, "Remote Network Monitoring MIB Protocol Identifiers", RFC 2074, January 1997. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [RFC3577] Waldbusser, S., Cole, R., Kalbfleisch, C., and D. Romascanu, "Introduction to the Remote Monitoring (RMON) Family of MIB Modules", RFC 3577, August 2003. [RFC3729] Waldbusser, S., "Application Performance Measurement MIB", RFC 3729, March 2004. [RFC4149] Kalbfleisch, C., Cole, R., and D. Romascanu, "Definition of Managed Objects for Synthetic Sources for Performance Monitoring Algorithms", RFC 4149, August 2005. Cole & Romascanu Expires August 30, 2009 [Page 11] Internet-Draft Robust Management February 2009 [RFC4150] Dietz, R. and R. Cole, "Transport Performance Metrics MIB", RFC 4150, August 2005. [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. [yang] Bjorklund, M., "YANG - A data modeling language for NETCONF", January 2009. Appendix A. Additional Stuff This becomes an Appendix. Authors' Addresses Robert G. Cole Johns Hopkins University 11100 Johns Hopkins Road Laurel, MD 20723 USA Phone: +1.443.778.6951 Email: robert.cole@jhuapl.edu URI: http://www.cs.jhu/~rgcole/ Dan Romascanu Avaya Atidim Technology Park, Bldg. #3 Tel Aviv 61131 Israel Phone: Email: dromascanu@avaya.com Cole & Romascanu Expires August 30, 2009 [Page 12]