idnits 2.17.1 draft-schoenw-iab-nm-ws-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Jun 2002) is 7984 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 357, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schoenwaelder 3 Internet-Draft University of Osnabrueck 4 Expires: November 30, 2002 Jun 2002 6 On the Future of Internet Network Management Standards 7 draft-schoenw-iab-nm-ws-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on November 30, 2002. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 There have been ongoing debates during the past few years on the 39 direction for the evolution of various Internet management 40 technologies and standards such as SNMP, COPS, PCIM. This memo has 41 been written in preparation of the IAB network management workshop to 42 be help in June 2002. It documents some of the author's views and 43 visions and as such it does not even try to be objective. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. General Aspects . . . . . . . . . . . . . . . . . . . . . . . 4 50 3. Protocol Aspects . . . . . . . . . . . . . . . . . . . . . . . 4 51 3.1 SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3.2 COPS-PR . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 3.3 CIM/PCIM . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 4. Industrial Aspects . . . . . . . . . . . . . . . . . . . . . . 6 55 5. Standardization Aspects . . . . . . . . . . . . . . . . . . . 7 56 6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 8 57 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 59 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10 61 1. Introduction 63 There is always a need to manage networks. However, the specific 64 management tasks change over time as the underlying networking 65 technologies evolve. As a consequence, the technologies used to 66 manage networks have to adapt to new requirements. 68 There have been several more or less competing proposals within the 69 IETF in recent years on how to evolve or complement the original 70 Internet management framework defined in the late 1980s, ranging from 71 evolutions of the SNMP technologies (EOS, SMIng, SNMPconf) over the 72 addition of new provisioning technologies (COPS-PR) to policy-based 73 management technologies (PCIM). 75 This memo looks at the current situation from four different 76 viewpoints: 78 1. General Aspects 80 2. Protocol Aspects 82 3. Industry Aspects 84 4. Standardization Aspects 86 The author believes that it is necessary to discuss all these aspects 87 and understand the interrelationships in order to develop a sound 88 vision for the future of the Internet management technologies. 90 1.1 Terminology 92 This section introduces some terminology as it is being used in this 93 memo. 95 Monitoring: Activities to collect status data or statistics. 97 Configuration: Activities which establish the long-term core 98 configuration of network devices. 100 Control: Activities to change parameters which influence the 101 behaviour of network devices. (This is sometimes also called 102 short-term configuration.) 104 Alarming: Determination and reporting of problematic situations 105 (alarms) in the network. 107 2. General Aspects 109 It is important to understand which technologies are being managed, 110 which technologies can be used for management and what the overall 111 context is in which Internet management takes place. 113 o Today's network devices can perform rather complex management 114 operations at reasonable costs. In general, it can be expected 115 that devices get more and more programmable and that it will be 116 possible at some point in time to execute control software 117 directly on the devices. 119 o Most of the time when management operations are performed, it is 120 safe to assume connectivity (also called the myths of the 121 collapsing network). In case connectivity is lost, other out of 122 band mechanisms are usually used to bring back connectivity first 123 before management operations continue. 125 o It is crucial to reduce the implementation and education costs 126 involved with management functions. This implies that existing 127 general purpose technologies should be adopted for management 128 wherever possible. 130 3. Protocol Aspects 132 This section discusses some of the protocols that have been used for 133 generic network management. There are additional special purpose 134 protocols for specific problem domains (such as routing protocols) 135 which perform management functions but will not be discussed here. 137 3.1 SNMP 139 SNMP was developed in the late 1980s. SNMPv1 is widely deployed and 140 heavily used for monitoring, fault isolation and to some extend for 141 control and alarming. It is not widely used for configuration, 142 although there are some notable configuration applications for 143 enterprise networks. 145 The basic operations supported by SNMP did not change significantly 146 since the late 1980s, even though the dimension of devices in terms 147 of available processing power and complexity of networking functions 148 did chance radically. As such, SNMP suffers from several problems: 150 o Efficiency: Retrieving bulky data via SNMP is way too slow due to 151 the lock-step nature of SNMP operations, the lack of reasonable 152 flow control and pipelining. 154 o Complexity: While the operations supported by SNMP are simple (and 155 in fact too simple), the complexity of the overall protocol is 156 rather large. In order to write SNMP agents or management 157 application, one usually has to invest several months of time. 159 o Semantic Mismatch: Today's networks require more complex control 160 and configuration interactions. SNMP's model of simple typed 161 variables with side-effects requires to break a semantically rich 162 management operation down into a sequence of micro-management 163 actions that are performed by a sequence of SNMP interactions. On 164 the managed element side, these SNMP interactions have to be 165 analyzed in order to discover what the manager was actually trying 166 to achieve. 168 o Data Model: The underlying data model and the language to express 169 data models has several restrictions (such as no reusable 170 structured data types). The model of simple typed variables that 171 can be organized in simple conceptual tables is not adequate to 172 describe complex systems. The data definition language itself 173 relies on ASN.1 which is hardly being used in new protocol work 174 today. 176 o Organizational Model: The assumption of multiple managers 177 coordinating their control and configuration activities through 178 the network devices themself does not work with most existing SNMP 179 MIBs. There is no general notification mechanism for 180 configuration changes and there is absolutely no guarantee that 181 information installed via control or configuration operations 182 stays unchanged on the devices. 184 It should be noted that some of the problems listed above are not 185 relevant for monitoring. 187 3.2 COPS-PR 189 COPS-PR was defined to better support the provisioning of control and 190 configuration information. While COPS-PR was trying to address some 191 important shortcomings of SNMP, it did not go far enough. 193 o The SPPI data definition language has only minor improvements. 194 There are still no reusable structured data types which are needed 195 to describe complex programmatic interfaces. 197 o Using TCP as a transport is a reasonable choice as it simplifies 198 the protocol significantly and allows larger transactions without 199 worrying about message size constraints. 201 o The total lack of an access control model is problematic. Having 202 to revert to a different protocol to read data while a COPS-PR 203 session is alive does not make much sense. 205 o The efficiency improvements on the wire are a nice side-effect, 206 although less important in the context of COPS-PR compared to SNMP 207 where message size constraints are a real issue. 209 o One can question whether the design choice to use BER encodings in 210 COPS-PR was pointing into the right direction. It might have been 211 more appropriate to adopt a simpler encoding. In addition, OID 212 naming could have been replaced by a more human friendly naming 213 mechanism. 215 A more detailed comparison between COPS-PR and SNMP can be found in 216 [xxx]. 218 3.3 CIM/PCIM 220 Policies are commonly defined as a set of rules to administer, 221 manage, and control access to network resources. Policy-based 222 network management has the advantage of being goal-driven and more 223 declarative rather than procedural. The Policy Core Information 224 Model (PCIM) is an extension of the Common Information Model (CIM) 225 developed by the DMTF. 227 o CIM and PCIM are frequently used as a starting point by designers 228 of management applications. It is not uncommon that CIM/PCIM 229 definitions are copied and modified to meet the specific needs and 230 then implemented in management applications. As these models are 231 used internally, there is usually little desire to actually gain 232 interoperability at the CIM layer. 234 o The CIM/PCIM specifications follow a strict top-down design 235 philosophy and thus require concrete extensions to become useful. 236 Some of them are being worked on in the IETF and the DMTF. 238 4. Industrial Aspects 240 There are several industrial aspects to consider when evaluating 241 management protocols. 243 o Branding: SNMP has a bad recognition in a large user potential 244 base of system administrators or network operators. It is 245 nevertheless used for monitoring by these people, although mainly 246 because it is the only option to get easily access to the relevant 247 data. Many people associate with SNMP the terms "insecure", 248 "cryptic", "complex", "slow" and "limited interoperability". 250 o Market Control and Protection: It is a normal desire of companies 251 to control and protect their markets. This is also true for 252 management technologies. Some companies contribute to standards 253 in order to gain or keep technology control and thus market 254 control. Other may choose to not contribute to standards 255 processes in order to protect their markets via protection of 256 their management interfaces. 258 o Market Improves Management Applications: Open management 259 interfaces can create a competitive market where competing 260 companies provide a stream of improving management applications. 261 In reality, this model does not seem to work very well. After 262 more than 12 years of SNMP, we have a reasonable market for MIB 263 browser kind of applications and data collectors. The number of 264 real network management applications which are able to manage 265 networks and to abstract from the MIB specifics is rather limited 266 (perhaps because it is rather difficult to develop such 267 applications). 269 o Market Decisions: Management aspects usually have little influence 270 on buyment decisions. The main factors are the primary network 271 functions supported and of course the price. It is not uncommon 272 that people prefer to save a few bucks when they buy devices even 273 if they have to spend quite a bit of money in the operational 274 phase due to missing, incompatible non-standard management 275 interfaces. 277 o Skills: Since management functions are not considered to be of 278 prime importance, it is not uncommon that new employees are tasked 279 to work on management issues. If they are good, it is likely that 280 they will change position to work on primary device functions. 282 5. Standardization Aspects 284 There are several aspects that are related to the way standards are 285 being developed in the IETF. 287 o Standardization efforts generally take too long. For management 288 interfaces, it is crucial to have a good timing. If reasonable 289 specifications are available early enough, then there is a good 290 chance that vendors will adopt and implement them. Standards that 291 come out after vendors have implemented their own proprietary 292 solutions are pretty unlikely to be adopted. 294 o Management data definitions need maintenance. Although the SMI 295 has clear rules on how to evolve definitions while retaining 296 interoperability with fielded implementations, we see little 297 interest in the community to update definitions and to adopt 298 updated definitions in real products. 300 o Some of the standard process rules impact the clarity of data 301 models. It is not uncommon that related definitions are spread 302 across several modules just to be able to pass complete modules 303 along the standards process. This results in confusion and it is 304 not unlikely that people outside the IETF fail to reassemble 305 fragmented related definitions. 307 o Design by committee does in general not work well. Trying to 308 accomodate every preference equally well usually leads to data 309 definitions that are relatively vague and which make it difficult 310 to write interoperable management implementations. 312 6. Recommendations 314 Below is a list of recommendations. 316 o Reduce the amount of special purpose technology developed for 317 managing networks. 319 o It is desirable to integrate the main good improvements of COPS-PR 320 into SNMP in order to avoid two competing standard-track protocols 321 addressing almost identical requirements. 323 o A new mechanism is needed to support long-term configuration. It 324 should use a declarative document-oriented approach in describing 325 configurations and configuration templates and distributing them. 326 XML might be a reasonable infrastructure for such a mechanism. 328 o The approach of defining formalized universal information models 329 which can be used to derive high-quality data models for various 330 protocols is unlikely to work in practice. 332 o There is a need for separate specific data models for long-term 333 configuration as well as monitoring and control. These data 334 models should be aligned by defining apropriate IETF procedures. 336 o The data definition revision process must be streamlined. It must 337 be possible to make minor modifications and additions to published 338 data definitions without destabilizing large completely unrelated 339 parts of a specification. 341 o The work on policy-based extensions of the CIM model should be 342 hosted in one organization. Since the DMTF is the owner of the 343 CIM, it is suggested to move change control of PCIM over to the 344 DMTF. 346 o Work should be started to move to an exception-driven fault 347 detection and isolation model. The work being done in the DISMAN 348 working group is constrainted by the limits of the SMIv2 data 349 definition language. In order to move to an exception-driven 350 fault detection and isolation model, it might be necessary to make 351 alarms first class object of the data definition language and to 352 provide a proper extensible infrastructure for alarm forwarding 353 and logging. 355 References 357 [1] Saperia, J. and J. Schoenwaelder, "Policy-Based Enhancements to 358 the SNMP Framework", Informatikbericht 00-02, May 2000. 360 Author's Address 362 Juergen Schoenwaelder 363 University of Osnabrueck 364 Albrechtstr. 28 365 49069 Osnabrueck 366 Germany 368 Phone: 369 EMail: schoenw@ibr.cs.tu-bs.de 371 Full Copyright Statement 373 Copyright (C) The Internet Society (2002). All Rights Reserved. 375 This document and translations of it may be copied and furnished to 376 others, and derivative works that comment on or otherwise explain it 377 or assist in its implementation may be prepared, copied, published 378 and distributed, in whole or in part, without restriction of any 379 kind, provided that the above copyright notice and this paragraph are 380 included on all such copies and derivative works. However, this 381 document itself may not be modified in any way, such as by removing 382 the copyright notice or references to the Internet Society or other 383 Internet organizations, except as needed for the purpose of 384 developing Internet standards in which case the procedures for 385 copyrights defined in the Internet Standards process must be 386 followed, or as required to translate it into languages other than 387 English. 389 The limited permissions granted above are perpetual and will not be 390 revoked by the Internet Society or its successors or assigns. 392 This document and the information contained herein is provided on an 393 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 394 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 395 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 396 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 397 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 399 Acknowledgement 401 Funding for the RFC Editor function is currently provided by the 402 Internet Society.