Internet DRAFT - draft-tp-i2rs-yang
draft-tp-i2rs-yang
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]
