Network Working Group T. Petch Internet-Draft Engineering Networks Ltd Intended status: Standards Track May 08, 2013 Expires: November 09, 2013 Netconf surprises draft-petch-netconf-surprises-00.txt Abstract This document identifies some aspects of Netconf that may come as a suprise to those familiar with the use of SNMP for device management. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on November 09, 2013. Copyright Notice Copyright (c) 2013 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction Petch Expires November 09, 2013 [Page 1] Internet-Draft Netconf surprises May 2013 This document looks at aspects of Netconf from the view of an experienced SNMP user, identifying some behaviour that may come as a surprise. 2. Terminology 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]. Manager and agent are used to refer to the part of the management system that makes requests and changes, and that part in the device that is being managed respectively. This is not the accepted terminology of SNMPv3. Netconf uses client and server. 3. Configuration and State Data Netconf is a protocol for configuration. It arose from an IAB workshop RFC3535 [RFC3535] which emphasised the need to process configuration data independent of state data, a distinction that SNMP never made. A laudable requirement, this has proved more difficult to turn into practice. Netconf RFC6241 [RFC6241] defines "configuration data: The set of writable data that is required to transform a system from its initial default state into its current state" so that any read-only object is excluded. To some extent, the property of read-only versus read-write has become the touchstone of configuration so that the statistical counters, clearly state data, are read-only in the data models currently under development. In this, it follows SNMP but in doing so, it also adopts the SNMP practice that a single value of a counter object of type counter is meaningless. Rather a counter has to be read more than once and it is the difference between values over time that is significant. Also, counters, read-only, cannot be reset, to zero or any other value, and so will eventually reach a maximum value at which point they are defined to wrap, reset to zero automatically. Other management systems use a different approach, allowing counters to be reset by a management station so that they can be read and reset at a time convenient to the management system. 4. Persistence SNMP developed the concept of persistent data and embodied it in a Textual Convention, StorageType [RFC2579] . This means that the persistence or otherwise of the data is integral with definition of the data model. Petch Expires November 09, 2013 [Page 2] Internet-Draft Netconf surprises May 2013 Netconf took a different approach, defining datastores, of which the one mandatory one is :running, although most devices will also have a :startup datastore. Netconf says nothing about the persistency of the datastores. :startup is used at boot time and so by implication is in a storage type that persists across shutdowns. Again, by implication, :running is ephemeral since "Operations that affect the running configuration will not be automatically copied to the startup configuration " [RFC6241]. So making data persistent with Netconf requires a successful protocol operation, with SNMP, it is integral with the data definition. The impact of this could be far-reaching. 5. Common data In some devices, Netconf will coexist with SNMP and both protocols may be used to retrieve data. While this may result in the same data, there is no formal requirement for this to happen. SNMP views data as forming a single virtual MIB in a tree structure with data at the leaves of the tree. Netconf defines a number of discrete datastores so that a given object may appear in multiple datastores and have different values in those datastores, as when an update has been performed to :running and not yet copied to :startup. Perforce, then, Netconf can give multiple, different answers when SNMP only gives one (short of implementing multiple MIBs in a device and accessing them via different addresses, communities or such-like). This different approach may affect the implementation of when data is obtained. Most of the data supplied by SNMP or Netconf will be obtained from other parts of the device, hardware or software. Once obtained, the agent has the option of caching the data for a future request or of discarding it and obtaining it afresh as and when it is again requested. The Netconf concept of datastores may colour an implementation into favouring caching as opposed to retrieval, whereas the SNMP concept of a single virtual MIB may point in the other direction. This is speculative but what is certain is that at present, there is no requirement for the different agents in a device to behave consistently and to produce the same values; indeed, with a single MIB and multiple datastores, there will be times, hopefully understood by management system, when this is to be expected. 6. Data models SNMP objects are defined in MIB modules, each of which has a unique name. Each module is rooted as part of a single tree, managed, at the top level, by ISO, with each branch and each leaf having an integer identifier; thus all IETF objects start with an object identifier of 1.3.6.1. Petch Expires November 09, 2013 [Page 3] Internet-Draft Netconf surprises May 2013 In SNMP, each object has a unique, case-significant, name. By convention, the name starts with a short, lower-case prefix, which identifies the module in which the object is defined, if for the IF- MIB (MIB modules have an upper-case name), snmp for the SNMP- FRAMEWORK-MIB. Nowadays, such prefixes would be registered with IANA to ensure uniqueness; then, it just happened. Scalar objects need no further identification so that snmpEngineID identifies such an object within an agent's MIB. Objects in tables need one or more index values to identify the row of the table, as with ifType.29 where 29 is the relevant value of ifIndex. Every MIB module makes reference to other MIB modules and can do so with a reference to module name and another name as with IMPORTS snmpTraps FROM SNMPv2-MIB Netconf, strictly YANG, the data modelling language that Netconf uses, RFC6020 [RFC6020] is different. The objects are defined in modules but the structure is now flat so that a device will have many top-level modules. Modules have names that are required to be unique, at least for IETF- defined modules, but this name is not used in the identification of objects. Rather, each module has a namespace associated with it, such as urn:ietf:params:xml:ns:yang:ietf-interfaces and names exist within that namespace, so a reference to a name must implicitly or explicitly state that namespace. Namespaces are (mostly) referenced by an associated prefix, such as if, so a reference to an object might be if:ifname, but that prefix is not required to be unique and the use of that prefix in contexts outside the defining module, such as when one module augments another module or when a filter is defined in a Netconf get operation, is only a 'SHOULD' and not a 'MUST'; as it can only be, since the prefixes chosen in modules are not themselves required to be unique. Absence of a prefix means that the default namespace applies. Modules can include submodules which in turn can include submodules, making the content from a submodule available to parent module. The included submodule is identified by name. It is currently unclear if, when A includes B which includes C, the definitions in C are available to A or only to B; doubtless, this will be resolved. Petch Expires November 09, 2013 [Page 4] Internet-Draft Netconf surprises May 2013 Modules can import the contents of another module which makes definitions from one module available inside another module or submodule. The imported module is identified by name and the import statement specifies the prefix to be used within the importing module (which may or may not be the same as that used in the imported module). The subtle difference is that an import allocates a prefix because the imported definitions come from a different namespace, while an include is part of a namespace common to the including module. So what? If the walkthrough of Netconf naming given above seems complicated, that is because it is and this is apparent when making reference to or interpreting a data object, whether viewing data gathered from a device, data on the wire, making a request for data or understanding what an object is from its model definition. While SNMP encodes in binary on the wire so some form of analyser is highly desirable to decode the binary and to turn the numeric object identifier into an object name, by accesssing the MIB module, an object name is readily obtained and may be all that is needed. Equally, a command line request for an object need only specify the object name; command line tools can turn that into an encoded request to get or set data. Indices, when needed, to identify a row in a table, are mostly numeric. The uniqueness of names makes the interface simple. With Netconf, a name is unique within a namespace, so a reference will be of the form prefix:objectname, and the meaning of the prefix: must be looked in the context, whatever that may be in order to identify a namespace, such as xmlns="urn:ietf:params:xml:ns:yang :ietf-interfaces". Furthermore, most names will be part of a heirarchy, such as true and in many cases, such as when an interface object has been added to the base interfaces module by a interface-type specific augmentation, then the heirarchy will come from multiple namespaces, each with associated prefixes. Petch Expires November 09, 2013 [Page 5] Internet-Draft Netconf surprises May 2013 Elements in such a hierarchy may also be lists (tables) which require index values which again may take the form of multiple elements with multiple namespaces. It is not so much that this is not logical and straightforward to automate but rather that such automation will be essential, the simple command line interface is likely to become too complex to be used in safety. Of course, the IETF does not involve itself in user interfaces but the complexity thereof may be .. well, a surprise. 7. Twin objects The management of a device often results in a pair of objects, the desired, configuration state and the actual state, as with operating status or with the speed and duplicity of a MAC card. With MAC cards, the state set by the management system may be for the device to select the best available option ('automatic'), in which case, knowing what that state is (100Mbps, FDX) is essential. With SNMP, there is no difference between configuration and state and such objects coexist in a row of a table. Netconf splits configuration from state. The objects are related so it is likely that both will appear as objects in a YANG list (ie table), and while the configuration can be retrieved and set by a Netconf get-config or edit-config operation, it will require a get to retrieve them both and both will require filters in order to select the relevant column from the table (to use the terminology of SNMP). Using just the base interfaces module, such a filter might be It seems unlikely that this can be made into a command line interface for the general user. 8. ifindex changed to ifname tba Petch Expires November 09, 2013 [Page 6] Internet-Draft Netconf surprises May 2013 9. Security Considerations There are no security considerations 10. IANA Considerations There are no IANA considerations. 11. Acknowledgments This document was written using the xml2rfc tool described in RFC2629 [RFC2629] which is why I cannot make it look the way I would like it to, after four hours writing and eight hours xml2rfc-ing. 12. References 12.1. Normative [I-D.ietf-netmod-interfaces-cfg] Bjorklund, M., "A YANG Data Model for Interface Management", draft-ietf-netmod-interfaces-cfg-10 (work in progress), April 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2629] Rose, M.T., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. [RFC6244] Shafer, P., "An Architecture for Network Management Using NETCONF and YANG", RFC 6244, June 2011. 12.2. Informative [RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network Management Workshop", RFC 3535, May 2003. Author's Address Tom Petch Engineering Networks Ltd Email: tomSecurity@network-engineer.co.uk Petch Expires November 09, 2013 [Page 7]