I2RS T. Petch Internet-Draft Engineering Networks Ltd Intended status: Standards Track May 8, 2014 Expires: November 9, 2014 Interactions of I2RS with NETCONF and YANG draft-tp-i2rs-yang-00.txt Abstract This memo looks at some possible interactions between the requirements of I2RS and the current capabilities (and data models) of YANG and NETCONF. 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 9, 2014. Copyright Notice Copyright (c) 2014 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. Petch Expires November 9, 2014 [Page 1] Internet-Draft Interactions of I2RS with NETCONF and YANG May 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Operational State . . . . . . . . . . . . . . . . . . . . . . 2 3. Instantiation . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Editable state . . . . . . . . . . . . . . . . . . . . . . . 5 6. Persistence . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Stability . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction This memo looks at some possible interactions between the requirements of I2RS and the current capabilities (and data models) of YANG [RFC6020] and NETCONF [RFC6241]. 2. Operational State YANG and NETCONF characterise data as being one of two types, config and state. State may then be further subdivided into operational state and read-only statistics. This terminology has been around since at least RFC3535 (2002) when the operators told the IAB of some limitations of SNMP. The sort of feature that was missing was the ability to pull the config from a box, replace the box, push the config back to a replacement box which would then resume operation, as if nothing had changed (give or take a few flaps and Graceless Restarts of the routing protocols). Crucially, config, in this context, is the changes made from the default state by CLI (or some such) to enable the box to operate. The rest of the data in a box is state, which is then divided into read-only statistics (the only kind thereof) and - Operational State, which is everything else that the box has acquired, be it from BGP or OSPF, from DHCP or NTP or ND, or parameters set up by the box itself, for example in response to detecting the insertion of a new blade in a card slot. (Such data is sometimes referred to as System Controlled). Thus entries in a routing table learnt from BGP are Operational State; a static entry put in by CLI (or some such) is config. The parameters for a hot-plugged interface card are Operational State; turning on passive ospf on that interface is config. Petch Expires November 9, 2014 [Page 2] Internet-Draft Interactions of I2RS with NETCONF and YANG May 2014 YANG (along with NETCONF) is designed for writing configuration, and reading everything else. Configuration means, in the YANG context, what you might put in through the CLI and it excludes everything else, such as data learnt via a protocol or created by the system. YANG defines data nodes with the container, leaf, leaf-list, list and anyxml statements, each of which can take the YANG substatement 'config', which can take the values true or false. 'config false' is then state, is read only and is read with a NETCONF get RPC. 'config true' is config, can be written and can be read with a NETCONF get- config RPC. NETCONF contains powerful filtering capabilities and these filters could have been used to extract 'config true' data from a box but the resulting RPC would be complex and error-prone; the NETCONF get- config RPC allows simple retrieval of the data of greatest interest to the users of NETCONF, i.e. configuration data. Thus 'config true' does not just make it possible to edit the data node - it also defines a subset of the data model that can be retrieved with a single, get-config, RPC. The set of data that is editable and the set that should be retrieved as the configuration is one and the same; this coincidence of the two sets, happily, appears not to have generated any issues. The value of the config substatement cascades down to subordinate nodes - YANG models are currently a tree structure - so that in practice, the statement need only be specified in a few places at the highest level of a tree. 3. Instantiation One restriction is that while 'config false' nodes may appear in the subtree of 'config true' nodes, 'config true' nodes may not appear in the subtree of 'config false' nodes. One quirk arising from this, that may not be immediately apparent, is that 'config false' nodes in the subtree of a 'config true' node do not get instantiated in the data model unless and until the 'config true' node is configured. Thus operational state data may be inaccessible unless and until some configuration is performed. This would apply to tables, such as the interface table, the routing table or a prefix list for an interface. The treatment of this issue has evolved and is still evolving. It led, initially, to a twin trees approach in defining data models, as can be seen in the current system, interfaces-cfg and routing-cfg YANG data models, with one read-write tree of configured information and a separate read-only tree of state information. (draft-ietf- netmod-interfaces-cfg-10 is an example of the earlier approach). In the case of a routing table, the configured table may be more or less Petch Expires November 9, 2014 [Page 3] Internet-Draft Interactions of I2RS with NETCONF and YANG May 2014 empty with all the information coming via routing protocols, and so being (operational) state. In the case of interfaces, then there could be more or less complete duplication, with every interface appearing in both lists. If a user of NETCONF wished to obtain all the relevant data, it would then have been necessary to obtain data from both trees. YANG provides no way to correlate entries in such a pair of lists, such as of routes or interfaces. Rather, the description of the data model must specify how entries should be matched between one list and another. Thus the routing model, in www.ietf.org/id/draft-ietf- netmod-routing-cfg-13.txt specifies that "Corresponding entries in both versions of the list (in operational state data and configuration) have the same value of the list key." An evolution of this position is that entries in a configuration list are automatically copied into the operational state list so that now, only the operational state list need to read in order to obtain a comprehensive picture. Again, this is something that must be specified in the description of the data model; YANG provides no assistance in this regard. Again, quoting from the routing model, "If the server accepts a configured user-controlled entry, then this entry also appears in the operational state version of the list. " where user-controlled refers to data input as config via NETCONF. As data models evolve, it seems possible, if not even likely, that the paralleling of data between (operational) state and config will be the norm and not just restricted to a few lists - there seems little that can only ever appear as config, perhaps such statements as 'ospf passive' or 'bgp 192.168.1.1 as 65533' (important as such statements are). 4. Defaults While the split between config and state, the latter being any 'config false' node, has been well-defined since the early days of NETCONF, the question of whether or not this two-way split is sufficient has led to much discussion, with a proposal for up to three boolean substatements for YANG data nodes, leading to eight possible combinations with much discussion as to which might be valid or useful. Petch Expires November 9, 2014 [Page 4] Internet-Draft Interactions of I2RS with NETCONF and YANG May 2014 One feature to emerge from this is the handling of defaults. Much of what might be configured can be left to take a default value as specified in the data model, so that the task of configuring a box can be simplified if default values may be omitted. On the other hand, there are times when the existence of a default may be the key to understanding why a system is performing as it is and so it should also be possible to read default values that the system is using. Then there are times when a data node is configured with the value that is the default value and this may, or may not, be regarded as being in the same condition as if the value were not configured at all. Three possible treatments of default values were identified, all regarded as valid, and all are specified in [RFC6243]. Note that while YANG can specify the existence of a default value, the treatment of it, as described above, is part of NETCONF - YANG did not acquire any additional substatements to defined the treatment of defaults. 5. Editable state By contrast, the issue of whether or not it is possible (or desirable) to be able to edit operational state has continued to generate discussion and here YANG has a part to play. Clearly such editing is a requirement for I2RS. YANG is an extensible language so an additional substatement can be added to data nodes, such as i2rs:edit-data where edit-data might be a boolean taking the values true or false. (The i2rs: is a prefix that is linked to the namespace in which the substatement, or indeed any element of YANG that is not in the original definition thereof, resides). This substatement then overrides one of 'config false' in that it makes the node editable. This substatement could be modelled on the config substatement, in that it applies to all nodes in the subtree unless overridden. The substatement would, presumably, only be valid on 'config false' nodes. Earlier, it was pointed out that 'config true' served a dual purpose; it defines the set of nodes that can be edited and it defines the set that it is useful to retrieve, with a NETCONF get-config RPC. It seems likely, to the author, that this logic does not apply to I2RS operations on operational state, that is the set of data that I2RS may want to edit will be a subset of the data that is of interest to I2RS; read-only statistics, for example, will not be in Petch Expires November 9, 2014 [Page 5] Internet-Draft Interactions of I2RS with NETCONF and YANG May 2014 the former but will be in the latter. From this it follows that while a single, boolean substatement may be sufficient, and that anything else can be achieved with filters, it would much simpler and less error-prone for I2RS to have a further substatement that defines the set of data that is of interest to I2RS so that such data can be readily retrieved by an additional NETCONF RPC, get-i2rs perhaps (NETCONF, like YANG, is extensible). Such substatements would, like config, apply to all nodes in the subtree unless overridden. By analogy with the config substatement, it would seem likely that an 'edit-data true' node should not appear under an 'edit-data false' node (although quite why is not clear to the author). 6. Persistence YANG has no concept of persistence and only a limited one of a datastore. YANG defines a schema tree; whether there is one or more than one instantiation thereof and where they are is outside the scope of YANG, but is very much a part of NETCONF. NETCONF defines a configuration datastore as the data that is required to get a device from its initial default state into a desired operational state (presuming that protocols such as BGP and DHCP will then do the rest of the work that is needed). By default, NETCONF defines a single, running configuration datastore to which NETCONF operations are applied. Curiously, the persistence thereof appears not to be specified, the assumption appearing to be that changes made thereto are persistent and will be present after a reboot of a box. Optionally, there can be other datastores, such as a startup configuration datastore. Now changes made to the running datastore are not persistent unless and until a NETCONF copy-config RPC is performed, from running to startup. NETCONF defines a candidate configuration datastore while users can define any number of additional datastores. A datastore is not just a coherent collection of configuration data. YANG contains powerful logical capabilities that allow the validity checking of a configuration, with statements such as when "../type = 'read' or ../type = 'write'"; or Petch Expires November 9, 2014 [Page 6] Internet-Draft Interactions of I2RS with NETCONF and YANG May 2014 augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route" { when "../../rt:address-family = 'v6ur:ipv6-unicast'" { } ... } The question for I2RS is whether or not the concept of a datastore is applicable, for either of the reasons given above. Will I2RS, having made changes to the operational state of a box, want to copy those changes to somewhere else, perhaps so that they can be re-applied at a later time, such as after a reboot, or is the underlying assumption of I2RS that such changes should be lost at a reboot? Will such a copy be required as an audit trail, a check on what actually happened, given that the changes that I2RS make are likely to be of higher risk to the integrity of the routing system than those made via configuration and NETCONF? If copying is required, where will the copies be to? on the box or, as seems more likely, back to the rest of the I2RS infrastructure, the I2RS clients? Will I2RS also want to create a set of changes on the box, like a candidate configuration datastore, so that they can be reviewed, validity checked by YANG logical statements, before they are applied? If such copy operations are required, then how will the data that is to be copied be identified? NETCONF deals with a relatively simple set of data, the configuration data that is needed to take a box to its operational state. (Even then, the picture is complicated by issues such as defaults). With I2RS, the amount of data involved is, potentially much greater - e.g. the full BGP table - if not so diverse - NETCONF must deal with any aspect of configuration whereas I2RS, at least initially, is focussed on routing. Will I2RS need an additional YANG substatement to specify which nodes should form part of an I2RS datastore? Will there need to be different types of datastore for different types of data within I2RS? As before, the current concept of configuration makes these issues relatively simple for NETCONF, more complex where I2RS is concerned. Equally it seems unclear whether or not the other property of datastores, that of being able to specify validity checks to be performed on the data, is applicable to I2RS or not, both in the sense of whether or not it makes sense for I2RS to have that functionality and whether or not the YANG statements make sense when applied to I2RS state data. Currently such checks are defined as valid for any configuration datastore, or for all state data on the device along with the running datastore, the latter being applicable to the results of a NETCONF get RPC. The introduction of editable operational state complicates this picture further. Petch Expires November 9, 2014 [Page 7] Internet-Draft Interactions of I2RS with NETCONF and YANG May 2014 The answers to these questions may lie with the uses to which I2RS is put; tightly scoped use cases would be a help here. 7. Stability Finally, one unanswered question (where use cases would again be of help) is what data it is that I2RS is likely to want to change, within, say, the routing system. A routing system is stable in some sense of that word (arguably, there will always be some change in the global Internet that has yet to propagate all the way to all routers but within a limited radius of the box in question, the routing system may be considered stable). A stable system in engineering is one that, when perturbed, returns to its original state. So make a change in one router and the rest of the routing system may seek to update that router and reinstate the status quo. For example, at least conceptually, a change to BGP's Adj-RIB-Out will be refreshed from Adj-RIB-In and so lost, while a change to Adj-RIB-In will be lost when the router that provided the data repeats its advertisement of the route. Thinking of the changes I2RS might want to make, it seems likely that many, or most, will be changes to what NETCONF/YANG refer to as config and not to the operational state. Whether such changes are ephemeral or persistent, in the long term, is then a question of which NETCONF configuration datastore the changes are made to, running or startup or both. Again, use cases might clarify this. 8. Security Considerations This informational memo introduces no security considerations. 9. Acknowledgements 10. References 10.1. Normative References [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. Petch Expires November 9, 2014 [Page 8] Internet-Draft Interactions of I2RS with NETCONF and YANG May 2014 10.2. Informative References [RFC6243] Bierman, A. and B. Lengyel, "With-defaults Capability for NETCONF", RFC 6243, June 2011. Author's Address Tom Petch Engineering Networks Ltd 18 Parkwood Close Lymm, Cheshire WA13 0NQ UK Email: tomSecurity@network-engineer.co.uk Petch Expires November 9, 2014 [Page 9]