Internet DRAFT - draft-rfernando-i2rs-yang-mods
draft-rfernando-i2rs-yang-mods
INTERNET-DRAFT R. Fernando
Intended Status: Proposed Standard P. Chinnakannan
Expires: August 19, 2013 M. Madhayyan
A. Clemm
February 15, 2013
YANG modifications for I2RS
draft-rfernando-i2rs-yang-mods-00
Abstract
Interface to Routing Systems (I2RS) provides the mechanisms for the
programmatic access of routing system components. YANG [RFC 6020] is
a modeling language that is used to specify an external visible data
model of sub-system - for defining both configuration and operational
data held in the networking device. NETCONF is the protocol that is
used to perform these configurations and accessing the operational
data.
This document proposes to use the YANG data modeling language for
I2RS data models. It also proposes a set of YANG language changes to
enable the I2RS data models for multi-client and programmatic access.
This document also proposes the scope for the I2RS programmed data
set on the Routing System and the necessary mechanisms for data
synchronization.
This document also recommends a binary encoding for "on-the-wire"
transfer of the YANG data model elements instead of XML.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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
Fernando, et. al. Expires August 19, 2013 [Page 1]
INTERNET DRAFT draft-rfernando-i2rs-yang-mods-00 February 15, 2013
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License 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.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2 I2RS Components . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 I2RS components . . . . . . . . . . . . . . . . . . . . . . 4
3 I2RS extensions to Yang . . . . . . . . . . . . . . . . . . . . 5
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Exclusive Owner I2RS . . . . . . . . . . . . . . . . . . . . 7
3.3 Canonical Client Name Identifier (cname) . . . . . . . . . . 11
3.4 Ephemeral data nodes . . . . . . . . . . . . . . . . . . . . 14
3.5 YANG module "ietf-i2rs-extensions.yang" . . . . . . . . . . 17
3.6 Client priority . . . . . . . . . . . . . . . . . . . . . . 19
4 Security Considerations . . . . . . . . . . . . . . . . . . . . 21
5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 21
6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1 Normative References . . . . . . . . . . . . . . . . . . . 21
7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
Fernando, et. al. Expires August 19, 2013 [Page 2]
INTERNET DRAFT draft-rfernando-i2rs-yang-mods-00 February 15, 2013
1 Introduction
The Network Configuration Protocol (NETCONF) provides mechanisms to
programmatically install, manipulate, and delete the configuration of
network devices. It uses an Extensible Markup Language (XML)-based
data encoding for the configuration data as well as the protocol
messages. The NETCONF protocol uses a remote procedure call (RPC)
paradigm and protocol operations are performed on top of this simple
RPC layer. A client encodes an RPC in XML and sends it to a server
using a secure, connection-oriented session. The server responds
with a reply encoded in XML.
YANG is the NETCONF Data Modeling Language [RFC6020], which supports
hierarchical modeling of data elements that represent the
configuration and runtime state of a particular network element.
The elements defined by the YANG module can be used for NETCONF-based
communication, including passing configuration and state data, remote
procedure calls (RPCs), and notifications. Thus YANG allows one to
completely describe all the data sent between a NETCONF client and
server.
YANG models the hierarchical organization of data as a tree in which
each node has a name and a value or a set of child nodes. It provides
clear and concise descriptions of the nodes, as well the inter-
relationship between those nodes.
Interface to routing system (I2RS) framework is a draft proposal that
sets out to build a framework to provide a common, standard interface
to allow programmatic access to the information maintained in a
router, like the routing protocol states, statistics, Routing
Information Base (RIB) states, interface and their states etc.
Fundamental to the I2RS is a clear data model that defines the
semantics of the information that can be written and read. This
document proposes the use of Yang to define I2RS data models. It
further proposes a set of YANG language extensions in order satisfy
all the requirements of I2RS.
Specifically, this document makes the following proposal:
o That I2RS shall use YANG for defining the data models that are
applicable for I2RS. These models are termed 'I2RS data models' in
this document.
o A mechanism to express data ownership for a data set injected by
I2RS clients into a Routing System using the I2RS data models.
Fernando, et. al. Expires August 19, 2013 [Page 3]
INTERNET DRAFT draft-rfernando-i2rs-yang-mods-00 February 15, 2013
o A mechanism to express multi-client semantics and multi-client
operations in an I2RS data model.
o A mechanism to express the life time scope of programmatic data
injected by I2RS clients in a Routing System and to express them in
the I2RS data models.
The draft proposal for binary encoding for "on-the-wire" transfer of
the YANG data model elements instead of XML and the associated
NETCONF version2 is specified in a companion document (draft-tbd).
The extensions proposed in this document is independent of the other
changes proposed and will operate with or without the binary encoding
as well as NETCONF version 2.
1.1 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].
2 I2RS Components
2.1 Overview
This section describes the roles performed by the different I2RS
components when YANG is used as the modeling language and NETCONF
used as the protocol.
2.2 I2RS components
An I2RS domain comprises of the following entities:
o A Routing System supporting the I2RS data models and interfaces.
o I2RS clients accessing and operating on the Routing systems using
the I2RS interface.
o I2RS servers present within a Routing system and providing the
interface into the I2RS services and associated data models.
o The NETCONF V2 Protocol that is used by the I2RS clients to access
the I2RS services provided by the I2RS servers using a binary
encoding format.
o The I2RS client admission and authorization control service, which
is co-located within the routing system. This function is provided by
Fernando, et. al. Expires August 19, 2013 [Page 4]
INTERNET DRAFT draft-rfernando-i2rs-yang-mods-00 February 15, 2013
an external service and this document recommends using NACM model
[RFC 6536].
3 I2RS extensions to Yang
3.1 Overview
I2RS clients operate on the I2RS data models to obtain the services
provided by the Routing sub-systems. Client operations result in
creation, modification and deletion of data sets in the I2RS data
model tree, which is represented in YANG.
The data set injected by an I2RS client may be single valued, which
is modeled as a "leaf" object or multi-valued, which are modeled as
hierarchy of nodes using "containers", "lists", etc. The hierarchy of
nodes, termed as "data model sub tree" or simply "sub tree", is
conceptually owned by the I2RS client.
I2RS clients may access operational data and persistent configuration
data. In this, they are like applications that automate management
workflows. In addition, I2RS clients may inject ephemeral data.
Ephemeral data corresponds to data that installs state, but that
(unlike configuration data) is not persisted.
The ownership in this context requires identification of the I2RS
client that injected the data set and the exclusivity assurance that
the entire data set is injected and maintained by one client.
The exclusivity property guarantees that no other client shall modify
any data item in the data set injected by one I2RS client. This
concept of exclusivity assurance is proposed and described in section
3.2 Exclusive Owner, using the new YANG statement "exclusive-owner".
That said, while an I2RS client is not able to modify the data that
was injected by another client, it may able to view data injected by
other clients (assuming proper authorization). This is required so
that I2RS clients are able to understand the I2RS server's behavior.
In contrast, current NETCONF treats all data to be global, meaning
modification of data by one client is visible to all other clients
and can be modified by other clients as well. In short, NETCONF is
inherently designed for multi-owner datastores. Whether data items
can be modified or not depends on the intrinsic nature of the data
item (specified by 'config' statement). The proposed YANG extensions
allow establishing a concept of ownership to data that is based on
the extrinsic property of who created it, rather than solely based on
the intrinsic nature of the data item. The I2RS data models may be
operated upon by multiple I2RS clients or a NETCONF client or a
Fernando, et. al. Expires August 19, 2013 [Page 5]
INTERNET DRAFT draft-rfernando-i2rs-yang-mods-00 February 15, 2013
mixture of both types of clients.
I2RS also requires a uniform and consistent mechanism to identify the
client that had injected the data set for the entire data model or to
the subset of data model. This is required so that ownership of data
items can be tagged to the data item themselves. The YANG data model
language must provide a capability to express and capture the
identity of a data model client in uniform and consistent manner
across all data models. The data model client identifier must be a
canonical client name identifier whose value must reference an unique
client name record in a NETCONF access control model, NACM, [RFC
6536] database within the domain. Section, 3.4 Canonical Client Name
Identifier (cname) describes this capability through the canonical
client name, "cname" extension to YANG.
The I2RS clients operations on routing sub-systems results in
creation, modification and deletion of data elements that are
represented by the I2RS data models. The I2RS data models not only
provide the schema for the data set injected, but also indicate the
sections within the data model that are modifiable or editable by an
I2RS client. The term editable is used in this document to refer to
any IRS operation that leads to creation, modification or deletion of
data model elements.
The editable portions of a data model sub tree is indicated by the
YANG statement "config true", and any resulting data set through edit
operations are stored in a data store called the running
configuration data store. This data set is functionally permanent, in
the sense that this data set must be stored in a persistent data
store by the Routing System component and it is present across router
reboots.
However, in I2RS operations, one of the requirement is to allow the
i2rs clients to perform edit operations and the resulting data set is
not stored permanently. This data set is "ephemeral" and is lost once
a router reboots. This requirement is met using a new YANG extension
called "ephemeral true", which is described in section 3.5 Ephemeral
data nodes.
An I2RS client injects a set of data items under a sub tree within an
I2RS data model. The exclusivity assurance guarantees that no other
client will be able to modify any data item in the data set injected
by one I2RS client in a sub tree that is indicated through the YANG
statement "exclusive-owner".
It is possible for I2RS clients to attach data items marked as
"ephemeral" or "exclusive" as a subtree underneath another data node,
defined in an existing YANG data module. The fact that the I2RS
Fernando, et. al. Expires August 19, 2013 [Page 6]
INTERNET DRAFT draft-rfernando-i2rs-yang-mods-00 February 15, 2013
client injects data under an existing subtree MUST NOT affect the
behavior of this containing subtree. Specifically, the exclusivity
property MUST NOT prevent an item that was previously configurable,
from being locked for configuration purposes. If a container is
deleted, any I2RS client data attached below it is deleted along with
it. In practice, it is therefore RECOMMENDED that I2RS ephemeral data
is only attached below subtrees that are not subject to configuration
(e.g., data items representing an immutable property, such as the
system as a whole), or highly unlikely to change (e.g., data items
representing a physical interface).
Although 'exclusivity' and 'ephemeral' statements describe two
different characteristics, in practice they tend to apply to the same
set of data nodes. That said, the concept of exclusivity is
orthogonal to the concept of ephemeral data. This means that the
"exclusive" property can be applied to data nodes marked as "config
true" just as it can be applied to data nodes that are marked as
ephemeral. Applying an exclusivity concept to configuration data
implies the need to apply this concept across datastores (running,
startup, candidate etc). As noted before, NETCONF datastores are
essentially global and do not carry the notion of ownership to data.
3.2 Exclusive Owner I2RS
Currently NETCONF/YANG allows an instance of a sub tree, created by
one client, to be modified later by another client. A data model
primitive is required that disallows modifications to ephemeral data
elements under a sub tree created by one I2RS client by another I2RS
client.
This mechanism provides the guarantee that no other client shall
modify any data item in the data set injected by one I2RS client.
This draft specification proposes that a new YANG statement be
supported that defines a data node as "exclusive". The presence of
the statement indicates that the data node, and all its descendants,
is modifiable only by the client which created the instance. Other
clients can retrieve the data node, but cannot edit it or delete it.
They also cannot add any of their own data nodes below it.
There are several scenarios for applying exclusive ownership. The
following outlines some of them:
o Exclusive ownership shall apply for an entire list. This can be
visualized as multiple identical tables, with each table being owned
by one client. In this case, the YANG data model needs to be defined
such that the list is contained in a container. The exclusive
property is applied to that container.
Fernando, et. al. Expires August 19, 2013 [Page 7]
INTERNET DRAFT draft-rfernando-i2rs-yang-mods-00 February 15, 2013
o Exclusive ownership shall apply for a list element, but different
list elements can have different owners. This can be visualized as a
single table with multiple rows, with each row owned by a different
client. In this case, the exclusive property is applied at the level
of the definition of the list.
o Exclusive ownership shall apply only to a particular cell within a
list element. This can be visualized as a single table with one cell
of a row owned by a different clients. In this case, the exclusive
property is applied at the level of the definition of the data node
within the list.
The requirement for exclusive ownership is best illustrated with a
few examples.
In the first example, the exclusive property is applied to a
container within a list element. This means that within a list
element, the container and everything it contains can only be
modified by its owner. However, different list elements can have
different owners for the corresponding container. Also, data nodes
that are part of the same list element, but siblings of the
container, can be modified by other clients as well.
module i2rs-routing
{
imports ietf-i2rs-extensions {
prefix "ix";
}
config true;
description "An i2rs-routing module that contains sub tree nodes
that are either single-owner or multi-owner. This example is for
illustration of the single owner data node that represents a
sub-section of cells in a row";
list i2rs-route {
key "prefix";
.....
leaf prefix {
type inet:ip-prefix;
}
container i2rs-route-attributes {
ix:exclusive;
ix:ephemeral;
Fernando, et. al. Expires August 19, 2013 [Page 8]
INTERNET DRAFT draft-rfernando-i2rs-yang-mods-00 February 15, 2013
//This allows the name of the owning client
//to be returned as part of the instantiated
//information
uses ix:client;
description "The i2rs-route-attributes container contains
several properties of a route. Only the client that
originally created the container is allowed to modify or
delete the container and its contents.";
}
container i2rs-dont-care {
description "The i2rs-don't-care container contains
properties of a route that can be manipulated
by any client";
}
}
}
In the second example, the exclusive property is applied to list
elements. Each list element has an exclusive owner. However, the
same list can contain many list elements, and different list elements
can have different exclusive owners.
module i2rs-routing
{
imports ietf-i2rs-extensions {
prefix "ix";
}
config true;
description "An i2rs-routing module that contains sub tree
nodes that are either single-owner or multi-owner. This
example is for illustration of the single owner data node that
represents a single row within a table";
list i2rs-route {
ix:exclusive;
ix:ephemeral;
key "prefix ix:cname";
//This allows the name of the owning client
//to be returned as part of the instantiated
//information, and to be a part of the key
uses ix:client;
container i2rs-route-attributes {
Fernando, et. al. Expires August 19, 2013 [Page 9]
INTERNET DRAFT draft-rfernando-i2rs-yang-mods-00 February 15, 2013
description
"The i2rs-route-attributes container contains
several properties of a route. Each list element has
an exclusive owner. Only the client that created the
list element can edit or delete it. In case of
multiple list elements with the same prefix, the
element that is associated with the client of the
highest priority takes effect. ";
}
}
}
Note that in the above example, the client name ("ix:cname") is used
as a key. This allows two separate clients, distinguished by their
cname, to inject a list element of otherwise the same key.
Note furthermore that in this example, if there are multiple list
elements that have the same prefix as part of their index, only a
single list element (i.e. only a single route entry) for the same
prefix will be in effect. This is resolved by virtue of the owning
client's priority, as determined by the server.
This example addresses the following scenario: Consider two I2RS
clients, "sdn-app-A" and "sdn-app-b", operating on the above data
model and injecting routes. Both clients may inject the same prefix
"10.0.0.0/8" and will result into two separate data nodes in the
hosting routing system component. The data record introduced by the
I2RS client "sdn-app-A" is identified by the keys {10.0.0.0/8, "sdn-
app-A"}, which contains an instance of the container i2rs-route-
property and an instance of the container i2rs-don't-care. Likewise,
the data record introduced by the I2RS client "sdn-app-B" is
identified by the keys {10.0.0.0/8, "sdn-app-B"}.
It would have been possible to declare the same list without the
client name as a key. In that case, each list element still has its
own exclusive owner. However, two clients cannot own a list element
that otherwise has the same key.
In the third example, the exclusive property is applied to the entire
list. In this case, a container for the list is introduced and the
exclusive property applied at that level.
Fernando, et. al. Expires August 19, 2013 [Page 10]
INTERNET DRAFT draft-rfernando-i2rs-yang-mods-00 February 15, 2013
module i2rs-routing
{
imports ietf-i2rs-extensions {
prefix "ix";
}
config true;
description "An i2rs-routing module that contains sub tree
nodes that are either single-owner or multi-owner. This
example is for illustration of the single owner data node that
represents a conceptual table";
container i2rs-routes {
ix:exclusive;
ix:ephemeral;
uses ix:client;
description
"This container serves as the container of a list of
i2rs routes that has an exclusive owner. Only the
owner of this container can modify the list and any
list elements within it.";
list i2rs-route {
key "prefix";
container i2rs-route-attributes {
description "The i2rs-route-attributes container
contains several properties of a route. ";
}
}
}
It should be noted that the concept of exclusive ownership pertains
only with regards to modification operations, not to retrieval
operations. Any client can retrieve data, even if it is exclusively
owned by another client.
3.3 Canonical Client Name Identifier (cname)
A routing system supports data models for different components within
the system which are known as I2RS data models in this specification.
The I2RS data models may be operated by multiple I2RS clients or a
single configuration NETCONF client or a mixture of both types of
Fernando, et. al. Expires August 19, 2013 [Page 11]
INTERNET DRAFT draft-rfernando-i2rs-yang-mods-00 February 15, 2013
clients. This programmatic access requires the concept of a client
and associated properties to be specified in the data model. A data
model requires a uniform and consistent methodology, and a mechanism
to identify the client that had injected the data set for the entire
data model or to the subset of the data model. The YANG data model
language must provide a capability to express and capture the
identity of a data model client in uniform and consistent manner
across all data models.
This specification proposes the following elements to meet with the
I2RS framework:
A new data type "cname" is introduced, used to identify the client
that owns a particular data node.
The data model client identifier value must reference a unique client
name record in a NETCONF access control model, [RFC 6536] database
within the domain. The NACM service within the domain shall be used
for specifying the client access privileges and other authentication,
authorization records.
A grouping, "client" is introduced which contains a client identifier
of cname type. The grouping may be used in conjunction with any data
nodes (e.g. containers or lists) whose data owner needs to be
identified. The client identifier is always provided by the server,
reflecting the client name as identified through NACM.
The client identifier may be used as key for identifying the client
in the data model sub tree sections that requires unambiguous
identity of the data owner.
This document specifies that I2RS data models use "cname" type to
specify the client identifier at required sections that are specified
using the "exclusive" keyword.
There are times when data provided by multiple clients need to be
maintained in a list with clear ownership of nodes maintained in the
list. For instance, next-hops for the same prefix could be provided
by multiple applications.
This type of data model construct can be achieved in two ways as
follows:
o Introducing an explicit YANG "list" node with a single key of the
type "cname" as a parent node for a data model sub tree that is a non
list type like containers, leaf-list, leaf etc.
o Introducing an additional key of the type "cname" for a data model
Fernando, et. al. Expires August 19, 2013 [Page 12]
INTERNET DRAFT draft-rfernando-i2rs-yang-mods-00 February 15, 2013
sub tree that is a YANG list.
module i2rs-routing {
imports ietf-i2rs-extensions {
prefix "ix";
}
list i2rs-routing-client {
key "ix:cname";
ix:exclusive;
description "The i2rs-routing-client is a list node
that provides the client identifier of the I2RS client
performing programmatic operation below this
sub tree in the data model";
uses ix:client;
container i2rs-routing-table {
description "Routing table maintained per client";
/* Contents not specified here*/
}
}
}
The following code fragment demonstrates a I2RS programmatic sub tree
that is a list node.
module interfaces {
imports ietf-i2rs-extensions {
prefix "ix";
}
container a-non-i2rs-container {
/* Contents not specified */
}
list i2rs-routing-interface {
key "ix:cname if-name";
ix:exclusive;
description "i2rs-routing-interface provides a list of i2rs
interfaces. The I2RS client identifier performing
programmatic access to the routing interfaces are identified
Fernando, et. al. Expires August 19, 2013 [Page 13]
INTERNET DRAFT draft-rfernando-i2rs-yang-mods-00 February 15, 2013
by the key client-id.";
uses ix:client;
leaf if-name {
type string;
description "The key field which is of the string type
that specifies the interface name";
}
/* Other nodes not specified */
}
}
3.4 Ephemeral data nodes
The I2RS clients operations on routing sub-systems results into
creation, modification and deletion of data elements that are
represented by the I2RS data models. The I2RS data models not only
provide the schema for the data set injected, but also indicate the
sections within the data model that are modifiable or editable by an
I2RS client.
The editable portions of a data model sub tree is indicated by the
YANG statement "config true", and any resulting data set through edit
operations are stored in a data store called the running
configuration data store. This data set is functionally permanent, in
the sense that this data set must be stored in a persistent data
store by the Routing System component and it is present across router
reboots. However, in Routing System operations a requirement is
present that must allow clients to perform edit operations and the
resulting data set is not stored permanently. This data set is
ephemeral and is present only for the duration in which the Router
System component is up and operational. This specification calls
this persistency nature of the I2RS client state data on the routing
system as ephemeral state and the data associated as ephemeral state
data.
NETCONF allow its clients to create, modify, and delete data model
elements expressed in YANG. This data created by NETCONF operations
is called as configuration data and is associated with a certain type
of data store called running configuration. The data present in the
running configuration data store is permanent and is present across
routing system reboots and is in contrast with the state data created
and maintained by I2RS clients. This requires a new YANG extension to
designate ephemeral state data. It must be noted that only sections
of the data model that use the YANG statement "config true" are
Fernando, et. al. Expires August 19, 2013 [Page 14]
INTERNET DRAFT draft-rfernando-i2rs-yang-mods-00 February 15, 2013
editable. Other sections of the data model that use the YANG
statement "config false" are not editable and these type of data are
called as operational data. Operational data is not associated with
any data store. I2RS clients need a third type of data which must be
editable, but not persistent across routing system component reboots
as well as not associated with any data store like the operational
data.
This specification proposes a new YANG statement called "ephemeral"
be supported which takes one argument that is a string with the value
that "true" or "false". A value of "true" indicates the inclusive
data node and all its sub tree is editable and remains persistent as
long as the routing system component is up and operational. Value of
'false' serves the same purpose of 'config false' i.e. to mark a
schema node as operational data.
The YANG statement "ephemeral true;" may be a specified at any node
of the data model tree and is inherited by all descendant nodes.
Ephemeral data cannot be part of a startup or candidate datastore.
It can only be part of a running datastore.
The following example shows a valid use of the "ephemeral" statement.
module i2rs-routing {
description "An i2rs-routing module with the root node of
designated as configurable for illustration purpose";
container i2rs-routing-main-container {
config true;
container i2rs-section {
ix:ephemeral;
description "The node i2rs-section and its entire sub
tree is now made ephemeral. This indicates that this
node and all children of the container i2rs-section is
writable but not configurable any more. Any writes
made to this sub tree is not present in the running
configuration and is lost when the router reboots";
}
container config-section {
config true;
Fernando, et. al. Expires August 19, 2013 [Page 15]
INTERNET DRAFT draft-rfernando-i2rs-yang-mods-00 February 15, 2013
description "The config-section node and its sub tree
is editable and is stored in the running config data
store. This sub tree is stored persistently across
reboots";
}
container oper-section {
config false;
description "This is node and its sub tree is not
editable and is the operational data";
}
container an-ephemeral-node {
ephemeral true;
container incorrect-config-node {
config true;
description "This node is marked incorrectly
as configurable and this is not permitted. A
descendant node of an ephemeral schema node cannot
be marked as 'config true'";
}
}
}
}
The following example shows how a section of the ephemeral sub tree
can represent operational data.
module i2rs-routing {
description "An i2rs-routing module with the root node of
designated as configurable for illustration purpose";
container i2rs-routing-main-container {
config true;
container another-ephemeral-node {
ix:ephemeral;
container an-intermediate-oper-node {
config false;
description "This node illustrates how an
ephemeral sub tree can have operational data.";
Fernando, et. al. Expires August 19, 2013 [Page 16]
INTERNET DRAFT draft-rfernando-i2rs-yang-mods-00 February 15, 2013
}
}
}
}
The following example shows in correct usage of the ephemeral
statement that would be flagged as error by the YANG compiler.
module i2rs-routing {
description "An i2rs-routing module with the root node of
designated as configurable for illustration purpose";
container i2rs-routing-main-container {
config true;
container an-ephemeral-node {
ix:ephemeral;
container incorrect-config-node {
config true;
description "This node is marked incorrectly
as configurable and this is not permitted";
}
}
container an-oper-node {
config false;
container an-errored-ephemeral-node {
ix:ephemeral;
description "This node is incorrect and will
not be accepted by the data model development
}
}
}
}
3.5 YANG module "ietf-i2rs-extensions.yang"
Yang module "ietf-i2rs-extensions" contains a set of definitions
needed by clients that intend to inject ephemeral state into a
device. Specifically, this module defines the following:
o A YANG extension that allows to declare the "ephemeral" clause
o A YANG extension that allows to declare the "exclusive" clause
Fernando, et. al. Expires August 19, 2013 [Page 17]
INTERNET DRAFT draft-rfernando-i2rs-yang-mods-00 February 15, 2013
o A grouping to be used in conjunction with data nodes that use the
ephemeral clause. This grouping contains node to identify the owning
control client and that client's priority.
o A set of management information containing a registry of control
clients, expiration timers, and operational status (TBD)
file "ietf-i2rs-extensions.yang"
module ietf-i2rs-extensions {
namespace "urn:ietf:params:xml:ns:yang:ietf-i2rs-extensions ";
prefix "i2rs-extn";
imports nacm {
prefix nacm;
}
organization
"example.com";
contact
"tbd";
description
"This module contains YANG extensions that would be needed to
model i2rs specific data models.";
revision "2013-02-14";
extension ephemeral {
description
"This extension can be used on schema nodes to indicate that
those data nodes and their descendant nodes do not survive
device reload."
argument access-specifier {
yin-element true;
};
}
extension exclusive {
description
"This extension can be used on schema nodes to indicate that
those data nodes and their descendant nodes can be created by
and written to by only one i2rs client. Other clients may have
Fernando, et. al. Expires August 19, 2013 [Page 18]
INTERNET DRAFT draft-rfernando-i2rs-yang-mods-00 February 15, 2013
have read-only access to those data node.;
}
typedef cname {
type leafref {
path "/nacm:nacm/nacm:groups/nacm:group/nacm:name";
}
description
"Control client ID by which the client is authenticated by the
server. An object of this type is always populated by the
server, not by the invoking application.";
}
grouping client {
leaf cname {
config false;
type cname;
}
}
}
3.6 Client priority
Multiple I2RS clients can inject ephemeral state in a device. With
the exclusivity statement in the data model, the state injected by
multiple clients can all be maintained concurrently on the device.
Applications in the device that are interested in ephemeral state
injected by multiple clients can subscribe to receive notifications
and read from the data store. In some cases, I2RS clients can inject
conflicting information. For instance, we could have multiple I2RS
clients programming different next- hop for the same destination
prefix.
In some cases, the backend applications would need to prioritize one
entry over the other. To do so, we may need some mechanism to assign
a relative priority to each of the i2rs client.
The proposal is to assign a priority to each client in the NACM
database. In I2RS datamodels that use the 'cname', backend
applications can receive the priority setting along with the client-
id.
To set the priority for a NACM user, the proposal is to enhance the
NACM user-group entries with a priority setting. Here is the
corresponding YANG snippet, to be incorporated into a corresponding
Fernando, et. al. Expires August 19, 2013 [Page 19]
INTERNET DRAFT draft-rfernando-i2rs-yang-mods-00 February 15, 2013
YANG module:
augment /nacm:nacm/nacm:groups/nacm:group {
leaf priority {
type uint32;
description
"Relative priority setting of a user-group (to which a i2rs
client gets assigned to".
default 0;
}
}
Both the user-group and priority setting is passed to the backend
application if the data model uses the 'exclusive true' keyword. It
is entirely up to the backend application to act on this data.
Fernando, et. al. Expires August 19, 2013 [Page 20]
INTERNET DRAFT draft-rfernando-i2rs-yang-mods-00 February 15, 2013
4 Security Considerations
This draft does not change the security characteristics of YANG.
5 IANA Considerations
This draft does not have any IANA considerations.
6 References
6.1 Normative References
[IRS-FRMWK] A. Atlas, T. Nadeau, D. Ward, "Interface to the Routing
System Framework", draft-ward-irs-framework-00
[IRS-FRMWK-REQ] R. Fernando et al, "IRS Framework Requirements",
draft-rfernando-irs-framework-requirement-00
7 Authors' Addresses
Rex Fernando
Cisco Systems
170 Tasman Dr
San Jose
EMail: rex@cisco.com
Palani Chinnakannan
Cisco Systems
170 Tasman Dr
San Jose
EMail: pals@cisco.com
Muthumayan Madhayyan
Cisco Systems
170 Tasman Dr
San Jose
EMail: muthu@cisco.com
Alexander Clemm
Cisco Systems
170 Tasman Dr
San Jose
Fernando, et. al. Expires August 19, 2013 [Page 21]
INTERNET DRAFT draft-rfernando-i2rs-yang-mods-00 February 15, 2013
EMail: alex@cisco.com
Fernando, et. al. Expires August 19, 2013 [Page 22]
