Network Working Group B. Lengyel Internet-Draft Ericsson Intended status: Standards Track November 29, 2007 Expires: June 1, 2008 Why we need a NETCONF-Specific Modeling Language - YANG draft-lengyel-why-yang-00 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 June 1, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract Today, the NETCONF protocol [RFC4741] lacks a standardized way to create data models. Instead, vendors are forced to use proprietary solutions. In order for NETCONF to be an interoperable protocol, models must be defined in a vendor-neutral way. We see a strong need for a domain-specific (i.e., a NETCONF-specific) solution. The YANG modeling methodology provides the language and rules for defining such models for use with NETCONF. This document explains why a NETCONF-specific solution is needed and why we have not chosen to use Lengyel Expires June 1, 2008 [Page 1] Internet-Draft Why YANG? November 2007 existing languages. 1. Introduction The NETCONF protocol [RFC4741] today lacks a standard modeling language. We propose the usage of [YANG], a data modeling language used to model configuration and state data manipulated by the NETCONF protocol, NETCONF remote procedure calls, and NETCONF notifications. There are a number of existing modeling languages in use today, so it is natural to ask why we need a new language. We will examine the current environment of NETCONF, the requirements for a NETCONF modeling language and the possibility of using one of the existing modeling languages. We will show that a new modeling language is indeed needed, and that this should be a narrow NETCONF-specific solution. 2. What problem do we want to solve? NETCONF needs something to model its data, RPCs (Remote Procedure Calls) and notifications. Modeling data transferred in NETCONF RPCs is not enough. In order to understand how an RPC will be handled, we need to understand what the state of NETCONF datastore is. Clearly, we need something that can be accepted by the NETCONF community. No current modeling language is usable for NETCONF in its current state. NETCONF has constructs that are not found in these languages. 75% of the missing features can be considered generic configuration management related features while 25% are NETCONF-specific. o Defining Custom RPCs: XSD in combination with [RFC4741] provides some support but is not a full solution (for example, linking requests and responses is missing). Other languages lack this feature. o Defining Notifications: XSD together with [NOTIFICATION] provide support. Other languages lack this feature. o A set of data types (IpAddress, MacAddress, Gauge32, ...): While XSD or RelaxNG provide a set of basic data types, they are missing higher-level constructs like IpAddress, etc. that are expected by the management community. Lengyel Expires June 1, 2008 [Page 2] Internet-Draft Why YANG? November 2007 o NETCONF filter semantics for the data constructs: How are values considered that are not entered by the client, but are derived from default values. o semantics for the data constructs: How the operation options 'none', 'merge', 'replace', 'create', and 'delete' work on data constructs must be clarified. o Compatibility rules for updating models: Which changes are considered compatible, which not? When do we need to step the revision of a data module, when do we have to rename it? o How to put the defined data into NETCONF RPCs: e.g., some items are mandatory in and optional in o Key constructs for choosing between list of elements: XSD has a key construct, but it is not clear how it would work with in general. Other languages lack this feature, for example RelaxNG excluded this by design. o keyref for referencing other elements of the model: XSD keyref mechanism is not sufficient, since it is restricted to point to keys defined in ancestor elements only. o Error-messages specific for NETCONF e.g. 'error-app-tag', 'error- tag' o Formal description of constraints e.g. "the accounting server assigned to a user group must exist and must be reachable" o Instance Naming: how do I refer to a specific data object? o status (current/deprecated/obsolete): same as in SMI o marking operational and configuration data o user-ordered lists: How do I influence the order of elements in a list? Can this be set and modified by the user (e.g., an access control list), or is this done automatically? o the possibility to extend existing models by augmenting: Once a data model is defined, how can I add new parts to it? Just saying that anything can be added at some point to an existing model, allows for any garbage that was never modeled. We need a method where any additions are always modeled as well. o a proposed structure for data models. There are millions of ways to define data models; we shall provide some guidance how to do Lengyel Expires June 1, 2008 [Page 3] Internet-Draft Why YANG? November 2007 this. o We need some guidelines what kind of administrative data should be provided: description, contact information, revision information, etc. Given all of these issues, there will be a great deal of work to do, no matter what modeling methodology we choose as our base, or if we design our own. 3. Some past experience with modeling When planning YANG we based our strategy on three key bits of experience. While these bits might not be what we wished for, it is hard to argue that yesterday people behaved in a certain way, but in the future all will be different. In the NETCONF working group during the last 6 years XSD was used as the modeling language. The NETCONF WG consists of highly motivated individuals who are interested in the topic (otherwise they would not be there). Nonetheless, they had major difficulties using XSD. XSD related errors persisted in our schemas after many rounds of reviews and parts of the schemas were misunderstood by active members of the workgroup. This implies that: o Members of the workgroup did not master XSD to a sufficient level, which means that learning XSD needs more effort than people were willing to invest. o Many working group members probably did not review the normative XSD part and read only the textual description in the drafts. The SMIng effort in the IETF and NMRG tried to define a data modeling language for multiple network management protocols. It failed after many years of work. The lessons learned can be found in [SMINGLESSON]. Some of the main conclusions include: o Creating a modeling language covering multiple protocols is immensely more difficult then designing a language for just one protocol. o If the scope of the data modeling effort is too big, discussions become endless, and there is no guarantee that consensus will ever be reached. o Network management data modeling languages are used by engineers to develop and specify data models for managed systems. The data Lengyel Expires June 1, 2008 [Page 4] Internet-Draft Why YANG? November 2007 models are later read by implementers as well as network operators 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 readers of a data model is much larger than the number of writers. Hence, when taking design decisions, preference should be given to solutions that simplify the task of the human reader. The people/companies involved in the YANG effort invented YANG because they have reached the conclusion that it was best after real implementation work. In multiple cases (Ericsson, Juniper, Tail-F, and NCX), the process has been similar: look at existing languages (XSD and RelaxNG) and try to make them work before deciding that they simply weren't acceptable. The fact is that *all* NETCONF implementations that we know of have designed their own modeling language, and in at least two cases after thorough evaluation of existing languages. In other words, the choice to create something grew out of the requirements of real implementations. 4. Lessons learned from SNMP's SMI The SMI data modeling language has been heavily used (within the IETF, by other standards developing organizations, and vendors) for more than 15 years for writing MIB modules for the SNMP protocol. A paper published in 2005 counted about 170 IETF modules, 480 Cisco modules, and 100 Juniper modules with a rough total of 32,000 object definitions [IM2005]. There are two important lessons that have been learned by using the SMI language. The first one concerns the value of using a formalized notation and the second one concerns the short term benefits and long term costs of creating an adapted subset of an existing language. 4.1. Formalized Notations The SNMP world has used a rather strict and formalized languages. One can ask the question whether this is required since there are other protocols very much less formalized notations are used to define data objects. We believe the key difference is simply the number of definitions network management people happen to deal with. The complete configuration of high-end routers involves significantly more than just a few 10s of knobs. Once you reach a critical number of definition you have to deal with, you really like to have precise machine readable specifications that can drive a tool chain and to some extend validate definitions, automate some of the implementation work, reduce implementation bugs, drive documentation tools and so Lengyel Expires June 1, 2008 [Page 5] Internet-Draft Why YANG? November 2007 on. The formalized SMI notation used for SNMP has been a major success in the sense that the whole industry uses a common notation and there is an existing tool chain (open source and commercial) to validate definitions, to generate implementation code, to generate documentation, to translate definitions in other formats, etc. As mentioned above, we count the number of modules generated and maintained by some standardization bodies or vendors in the hundreds and object definitions in the 1,000s. In addition, there is a fast pace of adding definitions as new technology gets introduced. We believe that all this works reasonably well is to a large extend due to the fact that a formalized notation allows a high degree of automation and thus scales well. 4.2. Adapted Subsets of Languages Back in the old times when SNMP came up, the language of the day was called ASN.1. When the SMI became formalized (after it turned out that plain textual descriptions are too difficult to be understood by tools), something now called an adapted subset of ASN.1 was created. The idea was to take ASN.1, forbid those constructs that are somehow not useful in the SNMP context, and add some new constructs via ASN.1 macros that carry the stuff needed for SNMP data modeling. Since then, the SMI has become pretty much its own language and almost all SNMP tools actually do not use generic ASN.1 parsers to parse MIB modules. There are several reasons for this which we can't be discussed here in detail. The experience, however, has been that creating an "adapted subset" of ASN.1 (1987) turned out to be no long term money or energy saver and there are still today questions popping up once in a while whether some constructs are legal, which you can't easily answer since you need the 1987 spec of ASN.1 and then find the "right" interpretation of it. (Note that the whole macro notation meanwhile got removed from ASN.1.) We think it is important to consider the long term implications of creating adapted subsets of other languages in the IETF. NETCONF needs a data modeling language and framework that must be long term stable and easy to use. We believe that designing a domain specific language for NETCONF has large benefits since we can optimize the language for what is needed for NETCONF, make the language simple to read, ensure the language works well in the IETF process, and we can enjoy long term stability and full chance control in the IETF, which also exercises change control over NETCONF. Lengyel Expires June 1, 2008 [Page 6] Internet-Draft Why YANG? November 2007 5. Requirements Based on the above we reached a set of requirements for any modeling language that could be successful for NETCONF. o We need a modeling language fast. NETCONF is a valuable new protocol, but it is not yet a widely-deployed protocol. Equipment manufacturers, standard bodies and operators will probably be reluctant to deploy it on a large scale, as long as the data models are described in a proprietary way, effectively hindering interoperability and ease of understanding. If we cannot provide a modeling language quickly, NETCONF as a whole might become irrelevant. o We either design our own language or need to add the missing feature listed above to some existing modeling language. o We naturally need a language that maps easily to an XML encoding. o The language must be easy to learn, and especially to read. People simply do not spend time to learn a modeling language. Choosing a more complex modeling language could mean that many people simply skip the formal model, as was the case for NETCONF RFCs. o In contrast to many XML modeling applications, the data modeling language of NETCONF will be read by many people (operators) who are not or only slightly trained in XML modeling. These people MUST be able to grok the language. o If a modeling language provides too much freedom, does not provide some degree of guidance for its users, the models soon become significantly different in structure and information content. o We need a language that has a chance of gaining widespread support in the NETCONF community. Even the best proposal will fail if it is foreign to the "NETCONF people". 6. Why not ... ? 6.1. XML Schema - XSD XSD would be a natural choice as it was already used in the NETCONF workgroup, and it provides some support for RPCs, Notifications and keys. However, XSD is unsatisfactory for some crucial reasons: Lengyel Expires June 1, 2008 [Page 7] Internet-Draft Why YANG? November 2007 o The problem we need to solve is different from the goal of XSD: modeling of arbitrary XML documents versus modeling management commands, notification, management information and related behavior. o A number of the above listed features are missing from XSD. o Experience tells us XSD is too complicated; people just do not learn it. o XSD is not simple, not readable enough o XSD has dangerous constructs e.g. redefine. o XSD is often used together with WDSL or SML to describe service and management interfaces, but if people don't even learn XSD don't add some additional methodology. o It is not obvious which XML instance document the XSD describes. With the NETCONF community, some people model the entire configuration and state data as one XML instance document. Some other people specify the data model by defining an XSD which validates messages. 6.2. RelaxNG RelaxNG is a widely used alternative to XSD although tool support for it is inferior to that of XSD. RelaxNG shares many of the problems of XSD as seen below. o The problem we need to solve is different from the goal of RelaxNG just as for XSD. o A number of the above listed feature are missing from RelaxNG this time even Notifications, RPCs and key constructs. o By design, RelaxNG does not have any support for integrity constraints. o RelaxNG is in most respects just as powerful and complex as XSD. o Once all "additional" information, descriptions and information belonging to the above missing features, are added to a RelaxNG model, it is not more readable than XSD. Lengyel Expires June 1, 2008 [Page 8] Internet-Draft Why YANG? November 2007 6.3. SMI(v2) SMIv2 is the most widely used management modeling language today in IETF. We could try to extend it according to NETCONF's needs. SMIv2 has some limitations and extending it in a compatible way would be very difficult. o SMI is strictly connected to SNMP o SMI has a completely different naming method (OIDs) o SMI has no XML mapping o SMI does not support hierarchical data structures (just tables) o SMI is missing many A lot of other features from the above list. 6.4. SMIng IETF has already done a big effort to produce a next generation modeling language SMIng [SMINGLESSON]. Why not use it? Actually YANG does use many concepts from SMIng e.g. the simple syntax of it's commands. Still there are some problems with SMIng: o SMIng never reached consensus. o It is intended for multiple protocols, which is too generic. o XML mapping is missing o NETCONF specific features are missing. 6.5. Why YANG? Given that we see that there are problems or at least work to do for all of the above alternatives, is YANG better? What do we gain with a new NETCONF-specific modeling language? Let us see what are the advantages of YANG: o It is custom-made for NETCONF, so it will support all needed features. o It is extremely easy to read and quite simple to write. It is possible to understand YANG models after less than one day of training. Lengyel Expires June 1, 2008 [Page 9] Internet-Draft Why YANG? November 2007 o It is already quite well-defined, so it has a chance to get accepted relatively quickly. o It already has considerable support in the NETCONF community. o It already has tools to check the YANG data models and produce XSD and XML formats from YANG. Let us now consider the disadvantages: o Work needed to define YANG, but we already have a well-baked draft. The successful NETCONF effort was started in the same way, with a reasonably well-defined document even before the workgroup was set up. As we have shown above we cannot get away without a considerable amount of work for any of the alternatives. o It will be a NETCONF-ONLY modeling language, but NETCONF has it own specific protocol features (e.g. edit-config operation options) that need specific treatment. o We lose the support of generic XML, XSD etc. tools. This is only partly true, as there already exist working tools, that translate YANG into XML and XSD formats for usage with other generic tools. 7. Conclusion NETCONF urgently needs a standard data modeling language. Many people in the NETCONF community agree that none of the current modeling alternatives are suitable for the task. While it would be worthwhile to define a generic XML based modeling language, SMIng has shown us how difficult and slow that can be. So any large generic solution, however desirable, will simply be too late for NETCONF. YANG, with its dedicated supporting community, has an excellent chance of being the solution to the acute NETCONF modeling problem. 8. Security Considerations None 9. IANA Considerations None Lengyel Expires June 1, 2008 [Page 10] Internet-Draft Why YANG? November 2007 10. References 10.1. Normative References [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. 10.2. Non-Normative References [SMINGLESSON] "Lessons Learned from the SMIng Project", draft-schoenw-sming-lessons-01 (work in progress), June 2007. [NOTIFICATION] "NETCONF Event Notifications", draft-ietf-netconf-notification-10 (work in progress), October 2007. [YANG] "YANG - A data modeling language for NETCONF", draft-bjorklund-netconf-yang-00 (work in progress), November 2007. [IM2005] "Characterization of SNMP MIB Modules", Proc. 9th IFIP/ IEEE International Symposium on Integrated Network Management (IM 2005), May 2005. Author's Address Balazs Lengyel Ericsson Email: balazs.lengyel@ericsson.com Lengyel Expires June 1, 2008 [Page 11] Internet-Draft Why YANG? November 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). Lengyel Expires June 1, 2008 [Page 12]