Network Working Group J. Schoenwaelder Internet-Draft University of Osnabrueck Expires: November 30, 2002 Jun 2002 On the Future of Internet Network Management Standards draft-schoenw-iab-nm-ws-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 November 30, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract There have been ongoing debates during the past few years on the direction for the evolution of various Internet management technologies and standards such as SNMP, COPS, PCIM. This memo has been written in preparation of the IAB network management workshop to be help in June 2002. It documents some of the author's views and visions and as such it does not even try to be objective. Schoenwaelder Expires November 30, 2002 [Page 1] Internet-Draft Future of Internet Network Management Standards Jun 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. General Aspects . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Aspects . . . . . . . . . . . . . . . . . . . . . . . 4 3.1 SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2 COPS-PR . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3 CIM/PCIM . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Industrial Aspects . . . . . . . . . . . . . . . . . . . . . . 6 5. Standardization Aspects . . . . . . . . . . . . . . . . . . . 7 6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10 Schoenwaelder Expires November 30, 2002 [Page 2] Internet-Draft Future of Internet Network Management Standards Jun 2002 1. Introduction There is always a need to manage networks. However, the specific management tasks change over time as the underlying networking technologies evolve. As a consequence, the technologies used to manage networks have to adapt to new requirements. There have been several more or less competing proposals within the IETF in recent years on how to evolve or complement the original Internet management framework defined in the late 1980s, ranging from evolutions of the SNMP technologies (EOS, SMIng, SNMPconf) over the addition of new provisioning technologies (COPS-PR) to policy-based management technologies (PCIM). This memo looks at the current situation from four different viewpoints: 1. General Aspects 2. Protocol Aspects 3. Industry Aspects 4. Standardization Aspects The author believes that it is necessary to discuss all these aspects and understand the interrelationships in order to develop a sound vision for the future of the Internet management technologies. 1.1 Terminology This section introduces some terminology as it is being used in this memo. Monitoring: Activities to collect status data or statistics. Configuration: Activities which establish the long-term core configuration of network devices. Control: Activities to change parameters which influence the behaviour of network devices. (This is sometimes also called short-term configuration.) Alarming: Determination and reporting of problematic situations (alarms) in the network. Schoenwaelder Expires November 30, 2002 [Page 3] Internet-Draft Future of Internet Network Management Standards Jun 2002 2. General Aspects It is important to understand which technologies are being managed, which technologies can be used for management and what the overall context is in which Internet management takes place. o Today's network devices can perform rather complex management operations at reasonable costs. In general, it can be expected that devices get more and more programmable and that it will be possible at some point in time to execute control software directly on the devices. o Most of the time when management operations are performed, it is safe to assume connectivity (also called the myths of the collapsing network). In case connectivity is lost, other out of band mechanisms are usually used to bring back connectivity first before management operations continue. o It is crucial to reduce the implementation and education costs involved with management functions. This implies that existing general purpose technologies should be adopted for management wherever possible. 3. Protocol Aspects This section discusses some of the protocols that have been used for generic network management. There are additional special purpose protocols for specific problem domains (such as routing protocols) which perform management functions but will not be discussed here. 3.1 SNMP SNMP was developed in the late 1980s. SNMPv1 is widely deployed and heavily used for monitoring, fault isolation and to some extend for control and alarming. It is not widely used for configuration, although there are some notable configuration applications for enterprise networks. The basic operations supported by SNMP did not change significantly since the late 1980s, even though the dimension of devices in terms of available processing power and complexity of networking functions did chance radically. As such, SNMP suffers from several problems: o Efficiency: Retrieving bulky data via SNMP is way too slow due to the lock-step nature of SNMP operations, the lack of reasonable flow control and pipelining. Schoenwaelder Expires November 30, 2002 [Page 4] Internet-Draft Future of Internet Network Management Standards Jun 2002 o Complexity: While the operations supported by SNMP are simple (and in fact too simple), the complexity of the overall protocol is rather large. In order to write SNMP agents or management application, one usually has to invest several months of time. o Semantic Mismatch: Today's networks require more complex control and configuration interactions. SNMP's model of simple typed variables with side-effects requires to break a semantically rich management operation down into a sequence of micro-management actions that are performed by a sequence of SNMP interactions. On the managed element side, these SNMP interactions have to be analyzed in order to discover what the manager was actually trying to achieve. o Data Model: The underlying data model and the language to express data models has several restrictions (such as no reusable structured data types). The model of simple typed variables that can be organized in simple conceptual tables is not adequate to describe complex systems. The data definition language itself relies on ASN.1 which is hardly being used in new protocol work today. o Organizational Model: The assumption of multiple managers coordinating their control and configuration activities through the network devices themself does not work with most existing SNMP MIBs. There is no general notification mechanism for configuration changes and there is absolutely no guarantee that information installed via control or configuration operations stays unchanged on the devices. It should be noted that some of the problems listed above are not relevant for monitoring. 3.2 COPS-PR COPS-PR was defined to better support the provisioning of control and configuration information. While COPS-PR was trying to address some important shortcomings of SNMP, it did not go far enough. o The SPPI data definition language has only minor improvements. There are still no reusable structured data types which are needed to describe complex programmatic interfaces. o Using TCP as a transport is a reasonable choice as it simplifies the protocol significantly and allows larger transactions without worrying about message size constraints. o The total lack of an access control model is problematic. Having Schoenwaelder Expires November 30, 2002 [Page 5] Internet-Draft Future of Internet Network Management Standards Jun 2002 to revert to a different protocol to read data while a COPS-PR session is alive does not make much sense. o The efficiency improvements on the wire are a nice side-effect, although less important in the context of COPS-PR compared to SNMP where message size constraints are a real issue. o One can question whether the design choice to use BER encodings in COPS-PR was pointing into the right direction. It might have been more appropriate to adopt a simpler encoding. In addition, OID naming could have been replaced by a more human friendly naming mechanism. A more detailed comparison between COPS-PR and SNMP can be found in [xxx]. 3.3 CIM/PCIM Policies are commonly defined as a set of rules to administer, manage, and control access to network resources. Policy-based network management has the advantage of being goal-driven and more declarative rather than procedural. The Policy Core Information Model (PCIM) is an extension of the Common Information Model (CIM) developed by the DMTF. o CIM and PCIM are frequently used as a starting point by designers of management applications. It is not uncommon that CIM/PCIM definitions are copied and modified to meet the specific needs and then implemented in management applications. As these models are used internally, there is usually little desire to actually gain interoperability at the CIM layer. o The CIM/PCIM specifications follow a strict top-down design philosophy and thus require concrete extensions to become useful. Some of them are being worked on in the IETF and the DMTF. 4. Industrial Aspects There are several industrial aspects to consider when evaluating management protocols. o Branding: SNMP has a bad recognition in a large user potential base of system administrators or network operators. It is nevertheless used for monitoring by these people, although mainly because it is the only option to get easily access to the relevant data. Many people associate with SNMP the terms "insecure", "cryptic", "complex", "slow" and "limited interoperability". Schoenwaelder Expires November 30, 2002 [Page 6] Internet-Draft Future of Internet Network Management Standards Jun 2002 o Market Control and Protection: It is a normal desire of companies to control and protect their markets. This is also true for management technologies. Some companies contribute to standards in order to gain or keep technology control and thus market control. Other may choose to not contribute to standards processes in order to protect their markets via protection of their management interfaces. o Market Improves Management Applications: Open management interfaces can create a competitive market where competing companies provide a stream of improving management applications. In reality, this model does not seem to work very well. After more than 12 years of SNMP, we have a reasonable market for MIB browser kind of applications and data collectors. The number of real network management applications which are able to manage networks and to abstract from the MIB specifics is rather limited (perhaps because it is rather difficult to develop such applications). o Market Decisions: Management aspects usually have little influence on buyment decisions. The main factors are the primary network functions supported and of course the price. It is not uncommon that people prefer to save a few bucks when they buy devices even if they have to spend quite a bit of money in the operational phase due to missing, incompatible non-standard management interfaces. o Skills: Since management functions are not considered to be of prime importance, it is not uncommon that new employees are tasked to work on management issues. If they are good, it is likely that they will change position to work on primary device functions. 5. Standardization Aspects There are several aspects that are related to the way standards are being developed in the IETF. o Standardization efforts generally take too long. For management interfaces, it is crucial to have a good timing. If reasonable specifications are available early enough, then there is a good chance that vendors will adopt and implement them. Standards that come out after vendors have implemented their own proprietary solutions are pretty unlikely to be adopted. o Management data definitions need maintenance. Although the SMI has clear rules on how to evolve definitions while retaining interoperability with fielded implementations, we see little Schoenwaelder Expires November 30, 2002 [Page 7] Internet-Draft Future of Internet Network Management Standards Jun 2002 interest in the community to update definitions and to adopt updated definitions in real products. o Some of the standard process rules impact the clarity of data models. It is not uncommon that related definitions are spread across several modules just to be able to pass complete modules along the standards process. This results in confusion and it is not unlikely that people outside the IETF fail to reassemble fragmented related definitions. o Design by committee does in general not work well. Trying to accomodate every preference equally well usually leads to data definitions that are relatively vague and which make it difficult to write interoperable management implementations. 6. Recommendations Below is a list of recommendations. o Reduce the amount of special purpose technology developed for managing networks. o It is desirable to integrate the main good improvements of COPS-PR into SNMP in order to avoid two competing standard-track protocols addressing almost identical requirements. o A new mechanism is needed to support long-term configuration. It should use a declarative document-oriented approach in describing configurations and configuration templates and distributing them. XML might be a reasonable infrastructure for such a mechanism. o The approach of defining formalized universal information models which can be used to derive high-quality data models for various protocols is unlikely to work in practice. o There is a need for separate specific data models for long-term configuration as well as monitoring and control. These data models should be aligned by defining apropriate IETF procedures. o The data definition revision process must be streamlined. It must be possible to make minor modifications and additions to published data definitions without destabilizing large completely unrelated parts of a specification. o The work on policy-based extensions of the CIM model should be hosted in one organization. Since the DMTF is the owner of the CIM, it is suggested to move change control of PCIM over to the Schoenwaelder Expires November 30, 2002 [Page 8] Internet-Draft Future of Internet Network Management Standards Jun 2002 DMTF. o Work should be started to move to an exception-driven fault detection and isolation model. The work being done in the DISMAN working group is constrainted by the limits of the SMIv2 data definition language. In order to move to an exception-driven fault detection and isolation model, it might be necessary to make alarms first class object of the data definition language and to provide a proper extensible infrastructure for alarm forwarding and logging. References [1] Saperia, J. and J. Schoenwaelder, "Policy-Based Enhancements to the SNMP Framework", Informatikbericht 00-02, May 2000. Author's Address Juergen Schoenwaelder University of Osnabrueck Albrechtstr. 28 49069 Osnabrueck Germany Phone: EMail: schoenw@ibr.cs.tu-bs.de Schoenwaelder Expires November 30, 2002 [Page 9] Internet-Draft Future of Internet Network Management Standards Jun 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Schoenwaelder Expires November 30, 2002 [Page 10]