Network Working Group J. Schoenwaelder Internet-Draft Jacobs University Bremen Intended status: Informational September 25, 2007 Expires: March 28, 2008 Protocol Independent Network Management Data Modeling Languages - Lessons Learned from the SMIng Project draft-schoenw-sming-lessons-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 March 28, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract A data modeling language for network management protocols called SMIng was developed within the Network Management Research Group of the Internet Research Task Force over a period of several years. This memo documents some of the lessons learned during the project for consideration by designers of future data modeling languages for network management protocols. Schoenwaelder Expires March 28, 2008 [Page 1]
Internet-Draft SMIng Lessons Learned September 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. SMIng Goals and History . . . . . . . . . . . . . . . . . . . 4 3. Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Readers, Writers, Tool Developers . . . . . . . . . . . . 5 3.2. Data vs. Command vs. Object vs. Document . . . . . . . . . 5 3.3. Naming Independence . . . . . . . . . . . . . . . . . . . 7 3.4. Errors and Exceptions . . . . . . . . . . . . . . . . . . 7 3.5. Configuration Storage Models . . . . . . . . . . . . . . . 8 3.6. Selection of Language Features . . . . . . . . . . . . . . 8 3.7. Syntax versus Semantics . . . . . . . . . . . . . . . . . 8 3.8. Reuse of Definitions . . . . . . . . . . . . . . . . . . . 9 3.9. Versioning and Meta Information . . . . . . . . . . . . . 9 3.10. Extensibility . . . . . . . . . . . . . . . . . . . . . . 9 3.11. Language Independence . . . . . . . . . . . . . . . . . . 10 3.12. Compliance and Conformance . . . . . . . . . . . . . . . . 10 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. Informative References . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Schoenwaelder Expires March 28, 2008 [Page 2]
Internet-Draft SMIng Lessons Learned September 2007 1. Introduction Network management is often performed using a collection of different management protocols. Many operators use several different management protocols to access a single managed device for different purposes, such as device configuration, event and notification delivery, and collection of statistics. While some operators manage to settle on a single protocol for a given management task and/or domain, it is not uncommon that different operators select different competing management protocols for the same management task and/or domain. As a result, device vendors are forced to support multiple management interfaces to satisfy their customers. This increases software complexity and costs. It is therefore understandable that device vendors are interested to reduce the complexity and efforts associated with supporting multiple management interfaces. One obvious step in this direction could be to have a common data model which is underlying all management protocol interfaces instead of the current situation where every management protocol interface has its own slightly different data model. As a consequence, it is attractive to design data modeling languages that are protocol independent and allow for a "late binding" to concrete management protocols. The Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF) has developed a new protocol independent data modeling language for network management protocols called SMIng [RFC3780]. Work on SMIng started in 1999 and concluded with the publication of the core language [RFC3780] and an extension providing mappings to the Simple Network Management Protocol (SNMP) [RFC3781] in 2004. This memo documents some of the lessons learned during the project for consideration by engineers of future data modeling languages for network management protocols. Our focus is on technical design aspects that have turned out to be more difficult than expected as well as aspects that required significant discussions in order to understand trade-offs. The rest of this document is structured as follows. Section 2 provides a short review of the goals and the history of the SMIng project. Section 3 discusses twelve lessons learned. The document concludes in Section 4. Schoenwaelder Expires March 28, 2008 [Page 3]
Internet-Draft SMIng Lessons Learned September 2007 2. SMIng Goals and History The SMIng project started in 1999 as a research project to address some drawbacks of SMIv2 [RFC2578] [RFC2579] [RFC2580], the current standard data modeling language for management information base modules in the IETF [DSOM99]. Primarily, SMIv2's partial dependence on ASN.1 and a number of exception rules were considered to be problematic. In 2000, the work was handed over to the IRTF Network Management Research Group where SMIng was significantly detailed. In 1999/2000, the work of the Resource Allocation Protocol (RAP) working group on the Common Open Policy Service (COPS) usage for Policy Provisioning (COPS-PR) [RFC3084] lead to the creation of the Structure of Policy Provisioning Information (SPPI) [RFC3159]. As a consequence, SMIng was split into two parts: a core protocol independent data definition language and protocol specific mappings to allow the access of core definitions through (potentially) multiple management protocols. The replacement of SMIv2 and SPPI by a single merged data definition language was also a primary goal of the IETF SMING working group chartered at the end of 2000. The SMING working group, after carefully documenting the objectives [RFC3216], could not reach agreement on a common solution, resulting in the working group being closed down in April 2003. The NMRG then published the SMIng specifications in 2004 in [RFC3780] and [RFC3781] in order to document the results achieved in the NMRG. The published version of SMIng aimed at being a data modeling language that can be adapted for different management protocols and thus be closer to an information modeling language. See RFC 3444 [RFC3444] for a more detailed discussion of the terms data modeling language and information modeling language. The problem which drove the development of SMIng, namely duplicated data modeling efforts and often also duplicated instrumentation code, is still widely unsolved and it even may have become more pressing. A standard data modeling language capable to drive tools that can automate the implementation of command line interfaces, monitoring interfaces, and configuration interfaces from a single specification surely would have significant value for the networking industry and standardization bodies. During the SMIng project, people have looked at various issues that have to be dealt with in this context. The purpose of this memo is to document these issues and some of the alternatives that have been explored to tackle them so that future language designers can learn from the SMIng experiment. Schoenwaelder Expires March 28, 2008 [Page 4]
Internet-Draft SMIng Lessons Learned September 2007 3. Lessons Learned This section summarizes the lessons learned from the SMIng project. Designers of future data modeling languages for network management protocols are encouraged to study these lessons to avoid potential pitfalls. 3.1. Readers, Writers, Tool Developers Network management data modeling languages are used by engineers to develop and specify data models for (sub-components of) managed systems. The data models are later read by implementers with the goal to create interoperable implementations. Network operators often read data models while managing networks and services. A data modeling language is therefore used by both data model writers and data model readers. In most cases, the number of data model readers is much larger than the number of data model writers. Hence, when taking design decisions, it may be necessary to consider to what extent the design choice simplifies the task of data model readers and the task of data model writers. All other things being equal, preference should be given to solutions that simplify the task of data model readers. The third group to be considered in the data modeling language design process are tool developers creating parser libraries or compilers. In general, language features should be simple and straight forward to implement in order to achieve wide spread tool support. However, when considering alternatives, it is important to realize that in most cases the number of data model writers is much larger than the number of developers of tools (e.g., parsers, compilers) supporting a data modeling language. As a consequence, preference should be give to solutions that simplify the task of readers. Reduction of the efforts required by writers is of secondary importance and the reduction of the efforts required by tool developers is of least important preference. While this perhaps seems obvious, it is at times difficult to take according design decisions, especially if the group working on a new data modeling language is dominated by tool developers or data model writers. 3.2. Data vs. Command vs. Object vs. Document There are different approaches to model network management interfaces and to design supporting protocols: Schoenwaelder Expires March 28, 2008 [Page 5]
Internet-Draft SMIng Lessons Learned September 2007 o The data-oriented approach models all management aspects through data objects that can be read, written, created, and destroyed. The SNMP technology is an extreme example of this approach where even create and destroy operations are handled as side effects of write operations. While the data-oriented approach is conceptually simple, it is usually difficult to use for modeling complex operations, for example due to atomicity issues. o The command-oriented approach does not model data objects but instead treats the state maintained by a managed element as a black box and provides specific commands to cause state changes or to retrieve/modify some selected internal state information. The command-oriented approach is widely used by command line interfaces. o The object-oriented approach can be seen as a combination of the data-oriented and the command-oriented approach where commands are bound to data objects and the black-box state is limited to the internal state of objects. The object-oriented approach is being used for example by the Common Information Model. o The document-oriented approach represents the state of a device and its configuration as a structured document. As a consequence, primitive operations are the retrieval of (parts of) a document and the application of changes to move from one document version to the next. Since a configuration is treated as a complete document, it becomes more natural to support coarse grained atomic operations. The document-oriented approach is used by the Network Configuration (NETCONF) protocol [RFC4741] recently published by the IETF. Note that the choice of the data modeling approach has impact on the features required by a data modeling language. Trying to be protocol neutral may imply to support multiple of these approaches, which clearly increases the complexity of the language design. A data modeling language aiming at supporting a document-oriented view for configuration, a data-oriented view for monitoring, and a command- oriented view for ad-hoc operations on a device must be able to link say a command to the data objects that may be manipulated to achieve the behaviour defined for that command. This quickly becomes difficult and it might be better to avoid mixing different data modeling approaches. Unfortunately, in many real-world implementations, new management protocols will be used together with existing interfaces or databases, which already follow one of the approaches. This will force the designers of new data modeling languages to accommodate features of multiple approaches, even if this makes the result more complicated. Schoenwaelder Expires March 28, 2008 [Page 6]
Internet-Draft SMIng Lessons Learned September 2007 3.3. Naming Independence One of the goals of the SMIng project was to provide a data definition language where the data definitions are not tied to a specific management protocol. Since protocols typically use different approaches to name instances of managed objects, it is required to support multiple instance naming systems. While this may sound easy to do, it turns out that trying to achieve naming independence has many implications: o There is in general a need to model relationships. A common approach is to refer to other definitions using names as pointers. Being naming system independent, such a pointer needs to be abstracted and the protocol mappings then need to explain how the pointer works for a given protocol. This quickly becomes difficult since management protocols tend to impose protocol specific constraints, resulting from the different naming systems. o Many relationships between data model components are typically explained in description clauses. Being protocol neutral, description clauses have to be worded carefully so that they make sense with the various protocol mappings. This significantly increases the efforts to write data models and to review them. o When thinking about relationships, it is crucial to think about fate sharing of data objects, namely does the removal of an object imply the removal of other objects? Being naming system independent causes some additional challenges here since some fate sharing properties may be implicit in the naming system used in one protocol mapping while they must be explicit in other protocol mappings. 3.4. Errors and Exceptions Well written data definitions include clear definitions how implementations should react in various error situations or during run-time exceptions. It is often a mistake if a data model writer assumes that implementers will choose a particular error code in a given error situation. For interoperability reasons, it is far better to spell out the precise behaviour in error situations and run-time exceptions. Unfortunately, it becomes quite difficult to be precise about errors and exceptions in a protocol and naming system neutral data modeling framework such as SMIng since all error and exception reporting mechanisms of the underlying protocols need to be abstracted because otherwise description clauses become protocol specific. Furthermore, due to the varying features of the underlying protocols, some errors and exceptions may only exist in some of the mappings and must therefore be dealt with when the generic data model is mapped to a concrete protocol. Schoenwaelder Expires March 28, 2008 [Page 7]
Internet-Draft SMIng Lessons Learned September 2007 3.5. Configuration Storage Models Management protocols use different mechanisms to deal with persistence of configuration state. The SNMP protocol uses StorageType [RFC2579] columns in conceptual tables to indicate which rows are persistent. The COPS-PR [RFC3084] protocol binds provisioned information to the existence of the COPS-PR session which provisioned policy information. The NETCONF protocol [RFC4741] has a concept of different data stores (running, startup, candidate) that imply whether configuration state is persistent or not. Given these fundamentally different approaches, it is difficult to write protocol neutral configuration data models that work equally well with the various management protocols. While it is possible to introduce say StorageType columns in protocol mappings, it is sometimes awkward to define the semantics of data objects if the persistence model is left to the protocol mappings. 3.6. Selection of Language Features A data modeling language, like any good language, should be based on a small orthogonal set of language features to control the overall complexity of the language, both in terms of usage and implementation. While it is relatively easy to invent and propose new features, it seems much harder to find a minimal and orthogonal set of basic features that addresses the requirements. During the design of the SMIng language, it was found useful to repeatedly ask the question why certain features are needed or whether there are any language rules without a strong and convincing justification. The general principle stated by Antoine de Saint- Exupery was followed: Perfection [in design] is achieved, not when there is nothing more to add, but when there is nothing left to take away. Language features should be selected by considering what tools can actually do with the information formalized by a language feature. In general, language features should raise automation and improve clarity. Features without a clear justification that they actually reduce implementation efforts or significantly improve the clarity of a data model specification should not be accepted. 3.7. Syntax versus Semantics During the design of a data modeling language, it is most important to focus on a clear semantic of all language constructs. Syntactical issues are of secondary importance. While this may sound obvious, it Schoenwaelder Expires March 28, 2008 [Page 8]
Internet-Draft SMIng Lessons Learned September 2007 is important, especially in open consensus driven processes, to keep contributors reminded that semantics of language constructs come first while the syntactic aspects are of secondary importance. 3.8. Reuse of Definitions A good data modeling language should allow data model writers to produce reusable definitions. However, not all definitions are equally easy to reuse. Experience has shown that data types derived from a small set of base types are usually very easy to reuse; structured data types are often getting slightly more complex to reuse. Reusing collections of structured data types with non-trivial interrelationships are often difficult to reuse. The low hanging fruits are therefor the simple type definitions. Sub-typing is frequently used to add specific semantics to a more generic type and to constrain the set of possible values. While constraining values is often a good thing, it should be noted that too strict constraints can turn out to be painful in the future. There are many examples where data types proved too constrained to represent protocols that followed a natural evolution. 3.9. Versioning and Meta Information Changes to data models are inevitable. Even the most careful design and review process will not be able to predict how technologies evolve in the future. It is therefore crucial that the data modeling language supports a suitable versioning model and that it establishes clear rules which changes are possible without having to change a version number or (module) name. Supporting complex collections of meta data (e.g., a granular revision log) as part of the data modeling language may be less of an issue since such information can often be maintained in revision control systems and automatically placed into comments where needed. 3.10. Extensibility It has proven to be useful to support language extensibility features that avoid backward compatibility problems with existing parsers when new language features are introduced. If a data modeling language supports language extensions, it should be possible to gradually introduce new language features. Supporting language extensions essentially requires to be very consistent with the syntactic structure so that deployed implementations can skip over new language constructs. In addition, it is necessary to precisely identify language extensions so that implementations supporting extensions know where to apply the Schoenwaelder Expires March 28, 2008 [Page 9]
Internet-Draft SMIng Lessons Learned September 2007 appropriate additional processing. 3.11. Language Independence One way to define a new data modeling language is to start from an existing language and to extend it and/or subset it as needed. However, there are some dangers associated with this approach. Since languages that are in actual use are not static, it is important to deal with conflicts that can arise if the base language is revised such that the extensions or subsets do not work anymore. This issue becomes particularly important if different organizations have change control since this makes coordination relatively complex. Things get even worse if the data modeling extension constitutes not a significant usage of the core language. Another risk associated with sub-setting an existing language is that generic tools are likely not aware of the subset allowed in data models and hence such tools will not help to restrict the features of the general language to the subset adequate to define management data models. The alternative is to provide a complete and self-contained definition for the data modeling language. This protects against change control issues and also makes it simpler for implementers or data model writers to find all language rules in one place. As a general rule, there is hardly a reason to import language definitions from other organizations. If you like to import something from a source that is likely to change, do not import. If, however, the source is assumed to be stable, then you can just import by value and explain the relationship to the original source. 3.12. Compliance and Conformance Any successful data modeling language will at some point have to deal with compliance and conformance definitions. However, designing language features to express compliance and conformance statements is non-trivial. Very fine grained mechanisms to define implementation requirements for different usage scenarios can lead to very detailed but also very complex compliance and conformance definitions that are difficult to understand, review and maintain. It is therefore important to make a good trade-off between the required expressiveness and the pragmatic usage of compliance and conformance definitions. The general considerations for language features discussed Section 3.6 particularly apply here. One approach is to first gain experience with the usage of a new data modeling Schoenwaelder Expires March 28, 2008 [Page 10]
Internet-Draft SMIng Lessons Learned September 2007 language and to support compliance and conformance definitions through language extensions, improving their expressiveness over time as needed. 4. Conclusions This memo documents some of the insights gained in the SMIng project in order to guide future data modeling language designers by making them aware of some of the problems encountered in the SMIng project and some of the design guidelines that have been developed through the project. While protocol independent data modeling languages seem like a very good idea in world which uses several different management protocols for different tasks and deployments, the complexity associated with the design and effective usage of protocol independent data modeling languages should not be underestimated. 5. IANA Considerations This document has no IANA actions. 6. Security Considerations This document discusses lessons learned during the design of a network management data modeling language and they have no impact on the security of the Internet. 7. Acknowledgements Many people contributed directly or indirectly to this documented through their participation in the SMIng project. Martin Bjorklund, David Harrington, Balazs Lengyel, Frank Strauss and Bert Wijnen provided valuable feedback on earlier versions of this document. 8. Informative References [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", RFC 2578, STD 58, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", RFC 2579, STD 58, Schoenwaelder Expires March 28, 2008 [Page 11]
Internet-Draft SMIng Lessons Learned September 2007 April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", RFC 2580, STD 58, April 1999. [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001. [RFC3159] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, S., Sahita, R., Smith, A., and F. Reichmeyer, "Structure of Policy Provisioning Information (SPPI)", RFC 3159, August 2001. [RFC3216] Elliot, C., Harrington, D., Jason, J., Schoenwaelder, J., Strauss, F., and W. Weiss, "SMIng Objectives", RFC 3216, December 2001. [RFC3780] Strauss, F. and J. Schoenwaelder, "SMIng - Next Generation Structure of Management Information", RFC 3780, May 2004. [RFC3781] Strauss, F. and J. Schoenwaelder, "Next Generation Structure of Management Information (SMIng) Mappings to the Simple Network Management Protocol (SNMP)", RFC 3781, May 2004. [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, January 2003. [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. [DSOM99] Schoenwaelder, J. and F. Strauss, "Next Generation Structure of Management Information for the Internet", Springer LNCS 1700, October 1999. Schoenwaelder Expires March 28, 2008 [Page 12]
Internet-Draft SMIng Lessons Learned September 2007 Author's Address Juergen Schoenwaelder Jacobs University Bremen Campus Ring 1 28725 Bremen Germany Phone: +49 421 200-3587 Email: j.schoenwaelder@jacobs-university.de Schoenwaelder Expires March 28, 2008 [Page 13]
Internet-Draft SMIng Lessons Learned September 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Schoenwaelder Expires March 28, 2008 [Page 14]