draft-ietf-i2rs-architecture-00.txt   draft-ietf-i2rs-architecture-01.txt 
Network Working Group A. Atlas Network Working Group A. Atlas
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Informational J. Halpern Intended status: Informational J. Halpern
Expires: February 17, 2014 Ericsson Expires: August 14, 2014 Ericsson
S. Hares S. Hares
ADARA ADARA
D. Ward D. Ward
Cisco Systems Cisco Systems
T. Nadeau T. Nadeau
Juniper Networks Brocade
August 16, 2013 February 10, 2014
An Architecture for the Interface to the Routing System An Architecture for the Interface to the Routing System
draft-ietf-i2rs-architecture-00 draft-ietf-i2rs-architecture-01
Abstract Abstract
This document describes an architecture for a standard, programmatic This document describes an architecture for a standard, programmatic
interface for state transfer in and out of the Internet's routing interface for state transfer in and out of the Internet's routing
system. It describes the basic architecture, the components, and system. It describes the basic architecture, the components, and
their interfaces with particular focus on those to be standardized as their interfaces with particular focus on those to be standardized as
part of I2RS. part of I2RS.
Status of This Memo Status of This Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 17, 2014. This Internet-Draft will expire on August 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Functional Overview . . . . . . . . . . . . . . . . . . . 3 1.1. Drivers for the I2RS Architecture . . . . . . . . . . . . 4
1.2. Architectural Overview . . . . . . . . . . . . . . . . . 4 1.2. Architectural Overview . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Key Architectural Properties . . . . . . . . . . . . . . . . 8 3. Key Architectural Properties . . . . . . . . . . . . . . . . 10
3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Model-Driven Programmatic Interfaces . . . . . . . . . . 9 3.3. Model-Driven Programmatic Interfaces . . . . . . . . . . 11
3.4. Authorization and Authentication . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
4. Network Applications and I2RS Client . . . . . . . . . . . . 10 4.1. Identity and Authentication . . . . . . . . . . . . . . . 12
4.1. Example Network Application: Topology Manager . . . . . . 11 4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 13
5. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 11 5. Network Applications and I2RS Client . . . . . . . . . . . . 13
5.1. Relationship to its Routing Element . . . . . . . . . . . 11 5.1. Example Network Application: Topology Manager . . . . . . 14
5.2. State Storage . . . . . . . . . . . . . . . . . . . . . . 12 6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 14
5.2.1. Starting and Ending . . . . . . . . . . . . . . . . . 12 6.1. Relationship to its Routing Element . . . . . . . . . . . 15
5.2.2. Reversion . . . . . . . . . . . . . . . . . . . . . . 13 6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 15
5.3. Interactions with Local Config . . . . . . . . . . . . . 13 6.2.1. I2RS Agent Failure . . . . . . . . . . . . . . . . . 15
5.4. Routing Components and Associated I2RS Services . . . . . 13 6.2.2. Starting and Ending . . . . . . . . . . . . . . . . . 16
5.4.1. Unicast and Multicast RIB and LFIB . . . . . . . . . 14 6.2.3. Reversion . . . . . . . . . . . . . . . . . . . . . . 16
5.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 14 6.3. Interactions with Local Config . . . . . . . . . . . . . 17
5.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 15 6.4. Routing Components and Associated I2RS Services . . . . . 17
5.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 15 6.4.1. Routing and Label Information Bases . . . . . . . . . 18
6. I2RS Client Agent Interface . . . . . . . . . . . . . . . . . 15 6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 19
6.1. Protocol Structure . . . . . . . . . . . . . . . . . . . 15 6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Channel . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 20
6.3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 16 6.4.5. Information Modeling, Device Variation, and
6.4. Identity and Security Role . . . . . . . . . . . . . . . 16 Information Relationships . . . . . . . . . . . . . . 20
6.4.1. Client Redundancy . . . . . . . . . . . . . . . . . . 16 6.4.5.1. Managing Variation: Object Classes/Types and
6.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 17 Inheritance . . . . . . . . . . . . . . . . . . . 20
6.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 17 6.4.5.1.1. Managing Variation: Optionality . . . . . . . 21
6.7. Information collection . . . . . . . . . . . . . . . . . 18 6.4.5.1.2. Managing Variation: Templating . . . . . . . 21
6.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 18 6.4.5.1.3. Object Relationships . . . . . . . . . . . . 22
6.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 19 7. I2RS Client Agent Interface . . . . . . . . . . . . . . . . . 23
7. Manageability Considerations . . . . . . . . . . . . . . . . 19 7.1. One Control and Data Exchange Protocol . . . . . . . . . 23
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7.2. Communication Channels . . . . . . . . . . . . . . . . . 23
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7.3. Capability Negotiation . . . . . . . . . . . . . . . . . 23
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 7.4. Identity and Security Role . . . . . . . . . . . . . . . 24
11. Informative References . . . . . . . . . . . . . . . . . . . 20 7.4.1. Client Redundancy . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
7.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 24
7.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 25
7.7. Information collection . . . . . . . . . . . . . . . . . 26
7.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 26
7.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 27
8. Manageability Considerations . . . . . . . . . . . . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
11. Informative References . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
Routers that form the Internet's routing infrastructure maintain Routers that form the Internet's routing infrastructure maintain
state at various layers of detail and function. For example, a state at various layers of detail and function. For example, a
typical router maintains a Routing Information Base (RIB), and typical router maintains a Routing Information Base (RIB), and
implements routing protocols such as OSPF, ISIS, BGP to exchange implements routing protocols such as OSPF, ISIS, and BGP to exchange
protocol state and other information about the state of the network protocol state and other information about the state of the network
with other routers. with other routers.
A router also has information that may be required for applications Routers know how to convert all of this information into the
to understand the network, verify that programmed state is installed forwarding operations that are installed in the forwarding plane.
in the forwarding plane, measure the behavior of various flows, The forwarding plane and the specified forwarding operations then
routes or forwarding entries, as well as understand the configured contain active state information that describes the expected and
and active states of the router. Furthermore, routers are typically observed operational behavior of the router and which is also needed
configured with procedural or policy-based instructions that tell by the network applications. Network-oriented applications require
them how to convert all of this information into the forwarding easy access to this information to learn the network topology, to
operations that are installed in the forwarding plane. It is also verify that programmed state is installed in the forwarding plane, to
the active state information that describes the expected and observed measure the behavior of various flows, routes or forwarding entries,
operational behavior of the router. as well as to understand the configured and active states of the
router.
This document sets out an architecture for a common, standards-based This document sets out an architecture for a common, standards-based
interface to this information. This Interface to the Routing System interface to this information. This Interface to the Routing System
(I2RS) facilitates control and diagnosis of the RIB manager's state, (I2RS) facilitates control and observation of the routing-related
as well as enabling network applications to be built on top of state (for example, a Routing Element RIB manager's state), as well
as enabling network-oriented applications to be built on top of
today's routed networks. The I2RS is a programmatic asynchronous today's routed networks. The I2RS is a programmatic asynchronous
interface for transferring state into and out of the Internet's interface for transferring state into and out of the Internet's
routing system, and recognizes that the routing system and a router's routing system. This I2RS architecture recognizes that the routing
OS provide useful mechanisms that applications could harness to system and a router's OS provide useful mechanisms that applications
accomplish application-level goals. could harness to accomplish application-level goals.
Fundamental to the I2RS are clear data models that define the Fundamental to the I2RS are clear data models that define the
semantics of the information that can be written and read. The I2RS semantics of the information that can be written and read. The I2RS
provides a framework for registering for and requesting the provides a framework for registering for and requesting the
appropriate information for each particular application. The I2RS appropriate information for each particular application. The I2RS
provides a way for applications to customize network behavior while provides a way for applications to customize network behavior while
leveraging the existing routing system as much as desired. leveraging the existing routing system as desired.
The I2RS, and therefore this document, are specifically focused on an Although the I2RS architecture is general enough to support
interface for routing data. information and data models for a variety of data, the I2RS, and
therefore this document, are specifically focused on an interface for
routing data.
1.1. Functional Overview 1.1. Drivers for the I2RS Architecture
There are four key aspects to the I2RS. First, the interface is a There are four key drivers that shape the I2RS architecture. First
programmatic interface which needs to be asynchronous and offers is the need for an interface that is programmatic, asynchronous, and
fast, interactive access. Second, the I2RS gives access to offers fast, interactive access. Second is the access to structured
information and state that is not usually configurable or modeled in information and state that is frequently not directly configurable or
existing implementations or configuration protocols. Third, the I2RS modeled in existing implementations or configuration protocols.
gives applications the ability to learn additional, structured, Third is the ability to subscribe to structured, filterable event
filterable information and events from the router. Fourth, the I2RS notifications from the router. Fourth, the operation of I2RS is to
will be data-model driven to facilitate extensibility and provide be data-model driven to facilitate extensibility and provide standard
standard data-models to be used by network applications. data-models to be used by network applications.
I2RS is described as an asynchronous programmatic interface; the key I2RS is described as an asynchronous programmatic interface, the key
properties of which are described in Section 5 of properties of which are described in Section 5 of
[I-D.atlas-i2rs-problem-statement]. [I-D.ietf-i2rs-problem-statement].
Such an interface facilitates the specification of implicitly non- The I2RS facilitates obtaining information from the router. The I2RS
permanent state into the routing system, that can optionally be made provides the ability to not only read specific information, but also
permanent. In addition, the extraction of that information and to subscribe to targeted information streams and filtered and
additional dynamic information from the routing system is a critical thresholded events.
component of the interface. A non-routing protocol or application
could inject state into a routing element via the state-insertion
aspects of the I2RS and that state could then be distributed in a
routing or signaling protocol and/or be used locally (e.g. to program
the co-located forwarding plane).
There are several types of information that the I2RS will facilitate Such an interface also facilitates the injection of ephemeral state
an I2RS Client obtaining. These range from dynamic event into the routing system. A non-routing protocol or application could
notifications (e.g. changes to a particular next-hop, interface up/ inject state into a routing element via the state-insertion
down, etc.)to information collection streams (statistics, topology, functionality of the I2RS and that state could then be distributed in
route changes, etc) to simply read operations. The I2RS provides the a routing or signaling protocol and/or be used locally (e.g. to
ability for an I2RS client to request filtered and thresholded program the co-located forwarding plane). I2RS will only permit
information as well as events. modification of state that would be safe, conceptually, to modify via
local configuration; no direct manipulation of protocol-internal
dynamically determined data is envisioned.
1.2. Architectural Overview 1.2. Architectural Overview
The figure in Figure 1 shows the basic architecture for I2RS. Inside Figure 1 shows the basic architecture for I2RS between applications
a Routing Element, the I2RS agent interacts with both the routing using I2RS, their associated I2RS Clients, and I2RS Agents.
subsystem and with local configuration. A network application uses Applications access I2RS services through I2RS clients. A single
an I2RS client to communicate with one or more I2RS agents on their client can provide access to one or more applications. In the
routing elements. The scope of I2RS is to define the interactions figure, Clients A and B provide access to a single application, while
between the I2RS agent and the I2RS client and the associated proper Client P provides access to multiple applications.
behavior of the I2RS agent and I2RS client.
*********************** *********************** Applications can access I2RS services through local or remote
* Application A * * Application B * clients. In the figure, Applicatons A and B access I2RS services
* * * * through local clients, while Applications C, D and E access I2RS
* +----------------+ * * +----------------+ * services through a remote client.
* | Client A | * * | Client B | *
* +----------------+ * * +----------------+ * An I2RS Client can access one or more I2RS agents. In the figure,
******* ^ ************* ***** ^ ****** ^ ****** Clients B and P access I2RS Agents 1 and 2. Likewise, an I2RS Agent
| | | can provide service to one or more clients. In the figure, I2RS
| -----------------------| | Agent 1 provides services to Clients A, B and P while Agent 2
| | | provides services to only Clients B and P.
******* v ***** v ************ ************** v **********
* +----------------+ * * +----------------+ * I2RS agents and clients communicate with one another using an
* | Agent 1 | * * | Agent 2 | * asynchronous protocol. Therefore, a single client can post multiple
* +----------------+ * * +----------------+ * simultaneous requests, either to a single agent or to multiple
* ^ ^ ^ * * ^ ^ ^ * agents. Furthermore, an agent can process multiple requests, either
* | | | * * | | | * from a single client or from multiple clients, simultaneously.
* v | v * * v | v *
* *********** | ********** * * *********** | ********* * The I2RS agent provides read and write access to selected data on the
* * Routing * | * Local * * * * Routing * | * Local * * routing element that are organized into I2RS Services.
* * and * | * Config * * * * and * | * Config* * Section Section 4 describes how access is mediated by authentication
* *Signaling* | ********** * * *Signaling* | ********* * and access control mechanisms. In addition to read and write access,
* ********** v * * *********** v * the I2RS agent allows clients to subscribe to different types of
* ************ * * *********** * notifications about events affecting different object instances. An
* * Dynamic * * * * Dynamic * * example not related to the creation, modification or deletion of an
* * System * * * * System * * object instance is when a next-hop in the RIB is resolved enough to
* * State * * * * State * * be used or when a particular route is selected by the RIB Manager for
* ************ * * *********** * installation into the forwarding plane. Please see Section 7.6 and
* * * * Section 7.7 for details.
* Routing Element 1 * * Routing Element 2 *
****************************** *************************** The scope of I2RS is to define the interactions between the I2RS
agent and the I2RS client and the associated proper behavior of the
I2RS agent and I2RS client.
****************** ***************** *****************
* Application C * * Application D * * Application E *
****************** ***************** *****************
^ ^ ^
| | |
|--------------| | |--------------|
| | |
v v v
***************
* Client P *
***************
^ ^
| |-------------------------|
*********************** | *********************** |
* Application A * | * Application B * |
* * | * * |
* +----------------+ * | * +----------------+ * |
* | Client A | * | * | Client B | * |
* +----------------+ * | * +----------------+ * |
******* ^ ************* | ***** ^ ****** ^ ****** |
| | | | |
| |-------------| | | |-----|
| | -----------------------| | |
| | | | |
************ v * v * v ********* ***************** v * v ********
* +---------------------+ * * +---------------------+ *
* | Agent 1 | * * | Agent 2 | *
* +---------------------+ * * +---------------------+ *
* ^ ^ ^ ^ * * ^ ^ ^ ^ *
* | | | | * * | | | | *
* v | | v * * v | | v *
* +---------+ | | +--------+ * * +---------+ | | +--------+ *
* | Routing | | | | Local | * * | Routing | | | | Local | *
* | and | | | | Config | * * | and | | | | Config | *
* |Signaling| | | +--------+ * * |Signaling| | | +--------+ *
* +---------+ | | ^ * * +---------+ | | ^ *
* ^ | |scoped | * * ^ | |scoped | *
* | |----| | | * * | |----| | | *
* v | v v * * v | v v *
* +----------+ +------------+ * * +----------+ +------------+ *
* | Dynamic | | Static | * * | Dynamic | | Static | *
* | System | | System | * * | System | | System | *
* | State | | State | * * | State | | State | *
* +----------+ +------------+ * * +----------+ +------------+ *
* * * *
* Routing Element 1 * * Routing Element 2 *
******************************** ********************************
Figure 1: Architecture of I2RS clients and agents Figure 1: Architecture of I2RS clients and agents
Routing Element: A Routing Element implements at least some portion Routing Element: A Routing Element implements some subset of the
of the routing system. It does not need to have a forwarding routing system. It does not need to have a forwarding plane
plane associated with it. Examples of Routing Elements can associated with it. Examples of Routing Elements can include:
include:
A router with a forwarding plane and RIB Manager that runs * A router with a forwarding plane and RIB Manager that runs
ISIS, OSPF, BGP, PIM, etc. ISIS, OSPF, BGP, PIM, etc.
A server that runs BGP as a Route Reflector * A server that runs BGP as a Route Reflector
An LSR that implements RSVP-TE, OSPF-TE, and PCEP and has a * An LSR that implements RSVP-TE, OSPF-TE, and PCEP and has a
forwarding plane and associated RIB Manager. forwarding plane and associated RIB Manager.
A server that runs ISIS, OSPF, BGP and uses ForCES to control a * A server that runs ISIS, OSPF, BGP and uses ForCES to control a
remote forwarding plane. remote forwarding plane.
A Routing Element may be locally managed, whether via CLI, SNMP, A Routing Element may be locally managed, whether via CLI, SNMP,
or NETCONF. or NETCONF.
Routing and Signaling: This block represents that portion of the Routing and Signaling: This block represents that portion of the
Routing Element that implements part of the Internet routing Routing Element that implements part of the Internet routing
system. It includes not merely standardized protocols (i.e. IS- system. It includes not merely standardized protocols (i.e. IS-
IS, OSPF, BGP, PIM, RSVP-TE, LDP, etc.), but also the RIB Manager IS, OSPF, BGP, PIM, RSVP-TE, LDP, etc.), but also the RIB Manager
layer. layer.
Local Config: A Routing Element will provide the ability to Local Config: A Routing Element will provide the ability to
configure and manage it. The Local Config may be provided via a configure and manage it. The Local Config may be provided via a
combination of CLI, NETCONF, SNMP, etc. The black box behavior combination of CLI, NETCONF, SNMP, etc. The black box behavior
for interactions between the state that I2RS installs into the for interactions between the state that I2RS installs into the
routing element and the Local Config must be defined. routing element and the Local Config must be defined.
Dynamic System State: An I2RS agent needs access to state on a Dynamic System State: An I2RS agent needs access to state on a
routing element beyond what is contained in the routing subsystem. routing element beyond what is contained in the routing subsystem.
Such state may include various counters, statistics, and local Such state may include various counters, statistics, and local
events. How this information is provided to the I2RS agent is out events. This is the subset of operational state that is needed by
of scope, but the standardized information and data models for network applications based on I2RS that is not contained in the
what is exposed are part of I2RS. routing and signaling information. How this information is
provided to the I2RS agent is out of scope, but the standardized
information and data models for what is exposed are part of I2RS.
I2RS Agent: The I2RS agent implements the I2RS protocol(s) and Static System State: An I2RS agent needs access to static state on
interacts with the routing element to provide specified behavior. a routing element beyond what is contained in the routing
subsystem. An example of such state is specifying queueing
behavior for an interface or traffic. How the I2RS agent modifies
or obtains this information is out of scope, but the standardized
information and data models for what is exposed are part of I2RS.
Application: A network application that needs to manipulate the I2RS Agent: See the definition in Section 2.
network to achieve its service requirements.
I2RS Client: The I2RS client implements the I2RS protocol(s). It Application: A network application that needs to observe the
interacts with other elements of the policy, provisioning, and network or manipulate the network to achieve its service
configuration system by means outside of the scope of the I2RS requirements.
effort. It interacts with the I2RS agents to collect information
from the routing and forwarding system. Based on the information I2RS Client: See the definition in Section 2.
and the policy oriented interactions, the I2RS client may also
interact with the I2RS agent to modify the state of the routing
system the client interacts with to achieve operational goals.
As can be seen in Figure 1, an I2RS client can communicate with As can be seen in Figure 1, an I2RS client can communicate with
multiple I2RS agents. An I2RS client may connect to one or more I2RS multiple I2RS agents. An I2RS client may connect to one or more I2RS
agents based upon its needs. Similarly, an I2RS agent may agents based upon its needs. Similarly, an I2RS agent may
communicate with multiple I2RS clients - whether to respond to their communicate with multiple I2RS clients - whether to respond to their
requests, to send notifications, etc. Timely notifications are requests, to send notifications, etc. Timely notifications are
critical so that several simultaneously operating applications have critical so that several simultaneously operating applications have
up-to-date information on the state of the network. up-to-date information on the state of the network.
As can also be seen in Figure 1, an I2RS Agent may communicate with As can also be seen in Figure 1, an I2RS Agent may communicate with
multiple clients. Each client may send the agent a variety of write multiple clients. Each client may send the agent a variety of write
operations. The handling of this situation has been a source of operations. In order to keep the protocol simple, the current view
discussion in the working group. In order to keep the protocol is that two clients should not be attempting to write (modify) the
simple, the current view is that two clients should not be attempting same piece of information. Such collisions may happen, but are
to write (modify) the same piece of information. Such collisions may considered error cases that should be resolved by the network
happen, but are considered error cases that should be resolved by the applications and management systems.
network applications and management systems.
Multiple I2RS clients may need to supply data into the same list In contrast, although multiple I2RS clients may need to supply data
(e.g. a prefix or filter list); this is not considered an error and into the same list (e.g. a prefix or filter list), this is not
must be correctly handled. The nuances so that writers do not considered an error and must be correctly handled. The nuances so
normally collide should be handled in the information models. that writers do not normally collide should be handled in the
information models.
The architectural goal for the I2RS is that such errors should The architectural goal for the I2RS is that such errors should
produce predictable behaviors, and be reportable to interested produce predictable behaviors, and be reportable to interested
clients. The details of the associated policy is discussed in clients. The details of the associated policy is discussed in
Section 6.8. The same policy mechanism (simple priority per I2RS Section 7.8. The same policy mechanism (simple priority per I2RS
client) applies to interactions between the I2RS agent and the CLI/ client) applies to interactions between the I2RS agent and the CLI/
SNMP/NETCONF as described in Section 5.3. SNMP/NETCONF as described in Section 6.3.
In addition it must be noted that there may be indirect interactions In addition it must be noted that there may be indirect interactions
between write operations. Detection and avoidance of such between write operations. A tivial example of this is when two
interactions is outside the scope of the I2RS work and is left to different but overlapping prefixes are written with different
agent design and implementation for now. [[Editor's note: This topic forwarding behavior. Detection and avoidance of such interactions is
needs more discussion in the working group.]] outside the scope of the I2RS work and is left to agent design and
implementation.
2. Terminology 2. Terminology
The following terminology is used in this document. The following terminology is used in this document.
agent or I2RS Agent: An I2RS agent provides the supported I2RS agent or I2RS Agent: An I2RS agent provides the supported I2RS
services to the local system's routing sub-systems. The I2RS services from the local system's routing sub-systems by
agent understands the I2RS protocol and can be contacted by I2RS interacting with the routing element to provide specified
clients. behavior. The I2RS agent understands the I2RS protocol and can be
contacted by I2RS clients.
client or I2RS Client: A client speaks the I2RS protocol to client or I2RS Client: A client implements the I2RS protocol, uses
communicate with I2RS Agents and uses the I2RS services to it to communicate with I2RS Agents, and uses the I2RS services to
accomplish a task. An I2RS client can be seen as the part of an accomplish a task. It interacts with other elements of the
policy, provisioning, and configuration system by means outside of
the scope of the I2RS effort. It interacts with the I2RS agents
to collect information from the routing and forwarding system.
Based on the information and the policy oriented interactions, the
I2RS client may also interact with I2RS agents to modify the state
of the routing system the client interacts with to achieve
operational goals. An I2RS client can be seen as the part of an
application that uses and supports I2RS and could be a software application that uses and supports I2RS and could be a software
library. library.
service or I2RS Service: For the purposes of I2RS, a service refers service or I2RS Service: For the purposes of I2RS, a service refers
to a set of related state access functions together with the to a set of related state access functions together with the
policies that control their usage. The expectation is that a policies that control their usage. The expectation is that a
service will be represented by a data-model. For instance, 'RIB service will be represented by a data-model. For instance, 'RIB
service' could be an example of a service that gives access to service' could be an example of a service that gives access to
state held in a device's RIB. state held in a device's RIB.
read scope: The set of information which the I2RS client is read scope: The set of information which the I2RS client is
authorized to read. This access includes the permission to see authorized to read. The read scope specifies the access
the existence of data and the ability to retrieve the value of restrictions to both see the existence of data and read the value
that data. of that data.
notification scope: The set of events and associated information notification scope: The set of events and associated information
that the I2RS Client can request be pushed by the I2RS Agent. that the I2RS Client can request be pushed by the I2RS Agent.
I2RS Clients have the ability to register for specific events and I2RS Clients have the ability to register for specific events and
information streams, but must do so given the access restrictions information streams, but must be constrained by the access
of their notification scope. restrictions associated with their notification scope.
write scope: The set of field values which the I2RS client is write scope: The set of field values which the I2RS client is
authorized to write (i.e. add, modify or delete). This access can authorized to write (i.e. add, modify or delete). This access can
restrict what data can be modified or created, and what specific restrict what data can be modified or created, and what specific
value sets and ranges can be installed. value sets and ranges can be installed.
scope: When unspecified as either read scope or write scope, the scope: When unspecified as either read scope, write scope, or
term scope applies to both the read scope and write scope. notification scope, the term scope applies to the read scope,
write scope, and notification scope.
resources: A resource is an I2RS-specific use of memory, storage, resources: A resource is an I2RS-specific use of memory, storage,
or execution that a client may consume due to its I2RS operations. or execution that a client may consume due to its I2RS operations.
The amount of each such resource that a client may consume in the The amount of each such resource that a client may consume in the
context of a particular agent can be constrained based upon the context of a particular agent may be constrained based upon the
client's security role. An example of such a resource could client's security role. An example of such a resource could
include the number of notifications registered for. These are not include the number of notifications registered for. These are not
protocol-specific resources or network-specific resources. protocol-specific resources or network-specific resources.
role or security role: A security role specifies the scope, role or security role: A security role specifies the scope,
resources, priorities, etc. that a client or agent has. resources, priorities, etc. that a client or agent has.
identity: A client is associated with exactly one specific identity: A client is associated with exactly one specific
identity. State can be attributed to a particular identity. It identity. State can be attributed to a particular identity. It
is possible for multiple communication channels to use the same is possible for multiple communication channels to use the same
skipping to change at page 9, line 4 skipping to change at page 10, line 16
secondary identity: An I2RS Client may supply a secondary opaque secondary identity: An I2RS Client may supply a secondary opaque
identity that is not interpreted by the I2RS Agent. An example identity that is not interpreted by the I2RS Agent. An example
use is when the I2RS Client is a go-between for multiple use is when the I2RS Client is a go-between for multiple
applications and it is necessary to track which application has applications and it is necessary to track which application has
requested a particular operation. requested a particular operation.
3. Key Architectural Properties 3. Key Architectural Properties
3.1. Simplicity 3.1. Simplicity
There have been many efforts over the years to improve the access to There have been many efforts over the years to improve the access to
the information known to the routing and forwarding system. Making the information available to the routing and forwarding system.
such information visible and usable to network management and Making such information visible and usable to network management and
applications has many well-understood benefits. There are two applications has many well-understood benefits. There are two
related challenges in doing so. First, the span of information related challenges in doing so. First, the quantity and diversity of
potentially available is very large. Second, the variation both in information potentially available is very large. Second, the
the structure of the data and in the kinds of operations required variation both in the structure of the data and in the kinds of
tends to introduce protocol complexity. operations required tends to introduce protocol complexity.
Having noted that, it is also critical to the utility of I2RS that it Having noted that, it is also critical to the utility of I2RS that it
be easily deployed and robust. Complexity in the protocol hinders be easily deployable and robust. Complexity in the protocol hinders
implementation, robustness, and deployability. Also, complexity in implementation, robustness, and deployability. Also, data models
the data models frequently makes it harder to extend rather than complexity may complicate extensibility.
easier.
Thus, one of the key aims for I2RS is the keep the protocol and Thus, one of the key aims for I2RS is the keep the protocol and
modeling architecture simple. So for each architectural component or modeling architecture simple. So for each architectural component or
aspect, we ask ourselves "do we need this complexity, or is the aspect, we ask ourselves "do we need this complexity, or is the
behavior merely nice to have?" Protocol parsimony is clearly a goal. behavior merely nice to have?" Protocol parsimony is clearly a goal.
3.2. Extensibility 3.2. Extensibility
There are several ways that the scope of the I2RS work is being Naturally, extensibility of the protocol and data model is very
restricted in the interests of achieving a deliverable and deployable important. In particular, given the necessary scope limitations of
result. We are only working on the models to be used over the single the initial work, it is critical that the initial design include
identified interface. We are only looking at modeling a subset of strong support for extensibility.
the data of interest. And we are probably only representing a subset
of the operations that may eventually be needed (although there is
some hope that we are closer on that aspect than others to what is
needed.) Thus, it is important to consider extensibility not only of
the underlying services' data models, but also of the primitives and
protocol operations.
At the same time, it is clearly desirable for the data models and The scope of the I2RS work is being restricted in the interests of
protocol operations we define in the I2RS to be useful the in more achieving a deliverable and deployable result. The I2RS Working
general settings. It should be easy to integrate data models from Group is modeling only a subset of the data of interest. It is
the I2RS with other data. Other work should be able to easily extend clearly desirable for the data models defined in the I2RS to be
it to represent additional aspects of the network elements or network useful in more general settings. It should be easy to integrate data
systems. Hence, the data model and protocol definitions need to be models from the I2RS with other data. Other work should be able to
designed to be highly extensible, preferably in a regular and simple easily extend it to represent additional aspects of the network
fashion. elements or network systems. This reinforces the criticality of
designing the data models to be highly extensible, preferably in a
regular and simple fashion.
The I2RS Working Group is defining operations for the I2RS protocol.
It would be optimistic to assume that more and different ones may not
be needed when the scope of I2RS increases. Thus, it is important to
consider extensibility not only of the underlying services' data
models, but also of the primitives and protocol operations.
3.3. Model-Driven Programmatic Interfaces 3.3. Model-Driven Programmatic Interfaces
A critical component of I2RS is the standard information and data A critical component of I2RS is the standard information and data
models with their associated semantics. While many components of the models with their associated semantics. While many components of the
routing system are standardized, associated data models for them are routing system are standardized, associated data models for them are
not yet available. Instead, each router uses different information, not yet available. Instead, each router uses different information,
different mechanisms, and different CLI which makes a standard different mechanisms, and different CLI which makes a standard
interface for use by applications extremely cumbersome to develop and interface for use by applications extremely cumbersome to develop and
maintain. Well-known data modeling languages exist and may be used maintain. Well-known data modeling languages exist and may be used
skipping to change at page 10, line 20 skipping to change at page 11, line 35
architecture and protocol(s). First, it allows for transferring architecture and protocol(s). First, it allows for transferring
data-models whose content is not explicitly implemented or data-models whose content is not explicitly implemented or
understood. Second, tools can automate checking and manipulating understood. Second, tools can automate checking and manipulating
data; this is particularly valuable for both extensibility and for data; this is particularly valuable for both extensibility and for
the ability to easily manipulate and check proprietary data-models. the ability to easily manipulate and check proprietary data-models.
The different services provided by I2RS can correspond to separate The different services provided by I2RS can correspond to separate
data-models. An I2RS agent may indicate which data-models are data-models. An I2RS agent may indicate which data-models are
supported. supported.
3.4. Authorization and Authentication 4. Security Considerations
All control exchanges between the I2RS client and agent MUST be This I2RS architecture describes interfaces that clearly require
authenticated and integrity protected (such that the contents cannot serious consideration of security. First, here is a brief
be changed without detection). Manipulation of the system must be description of the assumed security environment for I2RS. The I2RS
accurately attributable. In an ideal architecture, even information Agent associated with a Routing Element is a trusted part of that
collection and notification should be protected; this may be subject Routing Element. For example, it may be part of a vendor-distributed
to engineering tradeoffs during the design. signed software image for the entire Routing Element or it may be
trusted signed application that an operator has installed. The I2RS
Agent is assumed to have a separate authentication and authorization
channel by which it can validate both the identity and permissions
associated with an I2RS Client. To support numerous and speedy
interactions between the I2RS Agent and I2RS Client, it is assumed
that the I2RS Agent can also cache that particular I2RS Clients are
trusted and their associated authorized scope. This implies that
either in a pull model, the permission information may be old until
the I2RS Agent rerequests it, or in a push model, that the
authentication and authorization channel can notify the I2RS Agent of
changes.
I2RS Agents, in performing information collection and manipulation, An I2RS Client is not automatically trustworthy. It has identity
will be acting on behalf of the I2RS clients. As such, they will information and applications using that I2RS Client should be aware
operate based on the lower of the two permissions of the agent itself of the scope limitations of that I2RS Client. If the I2RS Client is
and of the client. acting as a broker for multiple applications, managing the security,
authentication and authorization for that communication is out of
scope; nothing prevents I2RS and a separate authentication and
authorization channel from being used. Regardless of mechanism, an
I2RS Client that is acting as a broker is responsible for determining
that applications using it are trusted and permitted to make the
particular requests.
Different levels of integrity, confidentiality, and replay protection
are relevant for different aspects of I2RS. The primary
communication channel that is used for client authentication and then
used by the client to write data requires integrity, privacy and
replay protection. Appropriate selection of a default required
transport protocol is the preferred way of meeting these
requirements.
Other communications via I2RS will not require integrity,
confidentiality, and replay protection. For instance, if an I2RS
Client subscribes to an information stream of prefix announcements
from OSPF, those may require integrity but probably not
confidentiality or replay protection. Similarly, an information
stream of interface statistics may not even require guaranteed
delivery. In Section 7.2, more reasoning for multiple communication
channels is provided. From the security perspective, it is critical
to realize that an I2RS Agent may open a new communication channel
based upon information provided by an I2RS Client; to avoid an
indirect attack, such a request must be done in the context of an
authenticated and authorized client whose communications cannot have
been altered.
4.1. Identity and Authentication
As discussed above, all control exchanges between the I2RS client and
agent should be authenticated and integrity protected (such that the
contents cannot be changed without detection). Further, manipulation
of the system must be accurately attributable. In an ideal
architecture, even information collection and notification should be
protected; this may be subject to engineering tradeoffs during the
design.
I2RS clients may be operating on behalf of other applications. While I2RS clients may be operating on behalf of other applications. While
those applications' identities are not need for authorization, each those applications' identities are not needed for authentication or
application should have a unique opaque identifier that can be authorization, each application should have a unique opaque
provided by the I2RS client to the I2RS agent for purposes of identifier that can be provided by the I2RS client to the I2RS agent
tracking attribution of operations to support functionality such as for purposes of tracking attribution of operations to support
accounting and troubleshooting. functionality such as accounting and troubleshooting.
4. Network Applications and I2RS Client 4.2. Authorization
An I2RS Client has a standardized interface that uses the I2RS All operations using I2RS, both observation and manipulation, should
protocol(s) to communicate with I2RS Agents. The interface between be subject to appropriate authorization controls. Such authorization
an I2RS client and the network applications is outside the scope of is based on the identity and assigned role of the I2RS client
I2RS. performing the operations and the I2RS agent in the network element.
When an I2RS Client interacts with multiple network applications, I2RS Agents, in performing information collection and manipulation,
that I2RS Client is behaving as a go-between and should indicate this will be acting on behalf of the I2RS clients. As such, each
to the I2RS Agents by, for example, specifying a secondary opaque operation authorization will be based on the lower of the two
identity to allow improved troubleshooting. permissions of the agent itself and of the authenticated client. The
mechanism by which this authorization is applied within the device is
outside of the scope of I2RS.
A network application that uses an I2RS client may also be considered The appropriate or necessary level of granularity for scope can
a routing element and include an I2RS agent for interactions. depend upon the particular I2RS Service and the implementation's
However, where the needed information and data models for that upper granularity. An approach to a similar access control problem is
interface differs from that of a conventional routing element, those defined in the NetConf Access Control Model[RFC6536]; it allows
models are, at least initially, out of scope for I2RS. arbitrary access to be specified for a data node instance identifier
while defining meaningful manipulable defaults. The ability to
specify one or more groups or roles that a particular I2RS Client
belongs and then define access controls in terms of those groups or
roles is expected. When a client is authenticated, its group or role
membership should be provided to the I2RS Agent. The set of access
control rules that an I2RS Agent uses would need to be either
provided via Local Config, exposed as an I2RS Service for
manipulation by authorized clients, or via some other method.
4.1. Example Network Application: Topology Manager 5. Network Applications and I2RS Client
One example of such an application is a Topology Manager. A Topology I2RS is expected to be used by network-oriented applications in
Manager includes an I2RS client that uses the I2RS data models and different architectures. While the interface between a network-
protocol to collect information about the state of the network by oriented application and the I2RS client is outside the scope of
communicating directly with one or more I2RS agents. From these I2RS I2RS, considering the different architectures is important to
agents, the Topology Manager collects routing configuration and sufficiently specify I2RS.
operational data. Most importantly, it collects information about
the routing system, including the contents of the IGP (e.g., IS-IS or
OSPF) and BGP data sets.
The Topology Manager may be embedded as a component of a larger In the simplest architecture, a network-oriented application has an
application. It would construct internal data structures and use the I2RS client as a library or driver for communication with routing
collected data to drive functions such as path computations or elements.
anomalous routing detection. Alternatively, the Topology Manager
could combine the I2RS-collected data with other information,
abstract a composite set, and provide a coherent picture of the
network state accessible via another interface. That interface might
use the same I2RS protocol and could use extensions to the I2RS data
models. Developing such mechanisms is outside the initial scope of
the I2RS work.
5. I2RS Agent Role and Functionality In the broker architecture, multiple network-oriented applications
communicate in an unspecified fashion to a broker application that
contains an I2RS Client. That broker application requires additional
functionality for authentication and authorization of the network-
oriented applications; such functionality is out of scope for I2RS
but similar considerations to those described in Section 4.2 do
apply. As discussed in Section 4.1, the broker I2RS Client should
determine distinct opaque identifiers for each network-oriented
application that is using it. The the broker I2RS Client can pass
along the appropriate value as a secondary identifier which can be
used for tracking attribution of operations.
In the third architecture, a routing element or network-oriented
application that uses an I2RS Client to access services on a
different routing element may also contain an I2RS agent to provide
services to other network-oriented applications. However, where the
needed information and data models for those services differs from
that of a conventional routing element, those models are, at least
initially, out of scope for I2RS. Below is an example of such a
network application
5.1. Example Network Application: Topology Manager
A Topology Manager includes an I2RS client that uses the I2RS data
models and protocol to collect information about the state of the
network by communicating directly with one or more I2RS agents. From
these I2RS agents, the Topology Manager collects routing
configuration and operational data, such as interface and label-
switched path (LSP) information. In addition, the Topology Manager
may collect link-state data in several ways - either via I2RS models,
by peering with BGP-LS[I-D.ietf-idr-ls-distribution] or listening
into the IGP.
The set of functionality and collected information that is the
Topology Manager may be embedded as a component of a larger
application, such as a path computation application. As a stand-
alone application, the Topology Manager could be useful to other
network applications by providing a coherent picture of the network
state accessible via another interface. That interface might use the
same I2RS protocol and could provide a topology service using
extensions to the I2RS data models.
6. I2RS Agent Role and Functionality
The I2RS Agent is part of a routing element. As such, it has The I2RS Agent is part of a routing element. As such, it has
relationships with that routing element as a whole, and with various relationships with that routing element as a whole, and with various
components of that routing element. components of that routing element.
5.1. Relationship to its Routing Element 6.1. Relationship to its Routing Element
A Routing Element may be implemented with a wide variety of different A Routing Element may be implemented with a wide variety of different
architectures: an integrated router, a split architecture, architectures: an integrated router, a split architecture,
distributed architecture, etc. The architecture does not need to distributed architecture, etc. The architecture does not need to
affect the general I2RS agent behavior. affect the general I2RS agent behavior.
For scalability and generality, the I2RS agent may be responsible for For scalability and generality, the I2RS agent may be responsible for
collecting and delivering large amounts of data from various parts of collecting and delivering large amounts of data from various parts of
the routing element. Those parts may or may not actually be part of the routing element. Those parts may or may not actually be part of
a single physical device. Thus, for scalability and robustness, it a single physical device. Thus, for scalability and robustness, it
is important that the architecture allow for a distributed set of is important that the architecture allow for a distributed set of
reporting components providing collected data from the I2RS agent reporting components providing collected data from the I2RS agent
back to the relevant I2RS clients. As currently envisioned, a given back to the relevant I2RS clients. As currently envisioned, a given
I2RS agent would have only one locus per I2RS service for I2RS agent would have only one locus per I2RS service for
manipulation of routing element state. manipulation of routing element state.
5.2. State Storage 6.2. I2RS State Storage
State modification requests are sent to the I2RS agent in a network State modification requests are sent to the I2RS agent in a routing
element by I2RS clients. The I2RS agent is responsible for applying element by I2RS clients. The I2RS agent is responsible for applying
these changes to the system. How much data must the I2RS Agent store these changes to the system, subject to the authorization discussed
about these state-modifying operations, and with what persistence? above. The I2RS agent will retain knowledge of the changes it has
There are range of possible answers. One extreme is where it stores applied, and the client on whose behalf it applied the changes. The
nothing, cannot indicate why or by whom state was placed into the I2RS agent will also store active subscriptions. These sets of data
routing element, and relies on clients reapplying things in all form the I2RS data store. This data is retained by the agent until
possible cases. The other extreme is where multiple clients' the state is removed by the client, overridden by some other
overlapping operations are stored and managed, as is done in the RIB operation such as CLI, or the device reboots. Meaningful logging of
for routes with a preference or priority to pick between the routes. the application and removal of changes is recommended. I2RS applied
changes to the routing element state will not be retained across
routing element reboot. The I2RS data store is not preserved across
routing element reboots; thus the I2RS agent will not attempt to
reapply such changes after a reboot.
In answering this question, this architecture tries to provide 6.2.1. I2RS Agent Failure
sufficient power to keep client operations effective, while still
being simple to implement in the I2RS Agent, and to observe
meaningfully during operation. The I2RS agent stores the set of
operations it has applied. Simply, the I2RS agent stores who did
what operation to which entity. New changes replace any data about
old ones. If an I2RS client does an operation to remove some state,
that state is removed and the I2RS agent stores no more information
about it. This allows any interested party to determine what the
current effect of I2RS on the system is, and why. Meaningful logging
is also recommended.
The I2RS Agent will not attempt to retain or reapply state across If it is possible for an I2RS Agent to fail independently of the
routing element reboot. Determination of whether state still applies associated routing element, the behavior for any associated ephemeral
depends heavily on the causes of reboots, and reapplication is at I2RS state needs to be clearly described. The I2RS state should be
least as likely to cause problems as it is to provide for correct preserved until the associated routing element has itself rebooted or
operation. [[Editor's note: This topics needs more discussion in the until the I2RS state is explicitly torn down. This is desirable
working group.]] since the I2RS Client has no way of learning that an I2RS Agent has
unexpected failed until that I2RS Agent has restarted; in the
interval between failure and recovery, the I2RS Client will be
assuming that its ephemeral state remains. If failure of the I2RS
agent causes the ephemeral I2RS state to be removed, then this should
be indicated via a capability.
5.2.1. Starting and Ending There are two different failure types that are possible and each has
different behavior.
An I2RS client applies changes via the I2RS protocol based on policy Unexpected failure: In this case, the I2RS Agent has unexpectedly
and other application inputs. While these changes may be of the form crashed and thus cannot notify its clients of anything. If an
"do this now, and leave it there forever", they are frequently driven I2RS Agent can crash separately from its associated routing
by other conditions which may have start times, stop times, or are element, then that I2RS Agent must cache each known I2RS Client.
only to be used under certain conditions. The I2RS interface When an I2RS Agent starts, it notifies each saved I2RS Client that
protocol could be designed to allow an I2RS Client to provide a wide the I2RS Agent is up and includes an agent-boot-count that
range of such conditional information to the I2RS Agent for indicates how many times the I2RS Agent has restarted since the
application. At the other extreme, the I2RS client could provide all associated routing element restarted. The agent-boot-count allows
such functionality based on its own clocking and network event an I2RS Client to determine if the I2RS Agent has restarted; if
reporting from the relevant I2RS Agents. so, the I2RS Client may need to resubscribe to notifications and
information streams. The I2RS Agent should also indicate whether
the I2RS ephemeral state was preserved in the Routing Element.
Given that the complexity of possible conditions is very large, and Graceful failure: In this case, the I2RS Agent can do specific
that some conditions may even cross network element boundaries, limited work as part of the process of being disabled. First, the
clearly some degree of handling must be provided on the I2RS client. I2RS Agent can optionally notify all its clients that their state
As such, in this architecture it is assumed that all the complexity is being torn down; if no such notification is sent, then that
associated with this should be left to the I2RS client. This ephemeral state is not torn down. Second, the I2RS Agent must
architectural view does mean that reliability of the communication notify all its cached clients that the agent is going down.
path between the I2RS client and I2RS agent is critical. [[Editor's
note: This requires more discussion in the working group.]]
5.2.2. Reversion 6.2.2. Starting and Ending
When an I2RS client applies changes via the I2RS protocol, those
changes are applied and left until removed or the routing element
reboots. The network application may make decisions about what to
request via I2RS based upon a variety of conditions that imply
different start times and stop times. That complexity is managed by
the network application and is not handled by I2RS.
6.2.3. Reversion
An I2RS Agent may decide that some state should no longer be applied. An I2RS Agent may decide that some state should no longer be applied.
An I2RS Client may instruct an Agent to remove state it has applied. An I2RS Client may instruct an Agent to remove state it has applied.
In all such cases, the state will revert to what it would have been In all such cases, the state will revert to what it would have been
without the I2RS; that state is generally whatever was specified via without the I2RS; that state is generally whatever was specified via
the CLI, NETCONF, SNMP, etc. I2RS Agents will not store multiple the CLI, NETCONF, SNMP, etc. I2RS Agents will not store multiple
alternative states, nor try to determine which one among such a alternative states, nor try to determine which one among such a
plurality it should fall back to. Thus, the model followed is not plurality it should fall back to. Thus, the model followed is not
like the RIB, where multiple routes are stored at different like the RIB, where multiple routes are stored at different
preferences. preferences.
An I2RS Client may register for notifications when state that was An I2RS Client may register for notifications, subject to its
applied by a particular I2RS Client is modified or removed. notification scope, regarding state modification or removal by a
particular I2RS Client.
5.3. Interactions with Local Config 6.3. Interactions with Local Config
As described above, local device configuration is considered to be Changes may originate from either Local Config or from I2RS. The
separate from the I2RS data store. Thus, changes may originate from modifications and data stored by I2RS are separate from the local
either source. Policy (i.e. comparisons between a CLI/SNMP/NETCONF device configuration, but conflicts between the two must be resolved
priority and a I2RS agent priority) can determine whether the local in a deterministic manner that respects operator-applied policy.
configuration should overwrite any state written by I2RS and That policy can determine whether Local Config overrides a particular
attributed to a particular I2RS Client or whether I2RS as attributed I2RS client's request or vice versa. To achieve this end, either by
to a particular I2RS Client can overwrite local configuration state. default Local Config always wins or, optionally, a routing element
may permit a priority to be configured on the device for the Local
Config mechanism. The policy mechanism in the later case is
comparing the I2RS client's priority with that priority assigned to
the Local Config.
Simply allowing the most recent state to prevail could cause race When the Local Config always wins, some communication between that
conditions where the final state is not repeatably deterministic. subsystem and the I2RS Agent is still necessary. That communication
One important aspect is that if CLI/SNMP/NETCONF changes data that is contains the details of each specific device configuration change
subject to monitoring or manipulating by I2RS, then the system must that the I2RS Agent is permitted to modify. In addition, when the
be instrumented enough to provide suitable I2RS notifications of system determines, that a client's I2RS state is preempted, the I2RS
these changes. agent must notify the affected I2RS agents; how the system determines
this is implementation-dependent.
5.4. Routing Components and Associated I2RS Services It is critical that policy based upon the source is used because the
For simplicity, each logical protocol or set of functionality that be resolution cannot be time-based. Simply allowing the most recent
compactly described in a separable information and data model is state to prevail could cause race conditions where the final state is
considered as a separate I2RS Service. A routing element need not not repeatably deterministic.
6.4. Routing Components and Associated I2RS Services
For simplicity, each logical protocol or set of functionality that
can be compactly described in a separable information and data model
is considered as a separate I2RS Service. A routing element need not
implement all routing components described nor provide the associated implement all routing components described nor provide the associated
I2RS services. The initial services included in the I2RS I2RS services. When a full implementation is not mandatory, an I2RS
architecture are as follows. Service should include a capability model so that implementations can
indicate which parts of the service are supported. Each I2RS Service
requires an information model that describes at least the following:
data that can be read, data that can be written, notifications that
can be subscribed to, and the capability model mentioned above.
5.4.1. Unicast and Multicast RIB and LFIB The initial services included in the I2RS architecture are as
follows.
Network elements concerned with routing IP maintain IP unicast RIBs. *************************** ************** *****************
Similarly, there are RIBs for IP Multicast, and a Label Information * I2RS Protocol * * * * Dynamic *
Base (LIB) for MPLS. The I2RS Agent needs to be able to read and * * * Interfaces * * Data & *
write these sets of data. The I2RS data model must include models * +--------+ +-------+ * * * * Statistics *
for this information. * | Client | | Agent | * ************** *****************
* +--------+ +-------+ *
* * ************** *************
*************************** * * * *
* Policy * * Base QoS *
******************** ******** * Templates * * Templates *
* +--------+ * * * * * *************
* BGP | BGP-LS | * * PIM * **************
* +--------+ * * *
******************** ******** ****************************
* MPLS +---------+ +-----+ *
********************************** * | RSVP-TE | | LDP | *
* IGPs +------+ +------+ * * +---------+ +-----+ *
* +--------+ | OSPF | | ISIS | * * +--------+ *
* | Common | +------+ +------+ * * | Common | *
* +--------+ * * +--------+ *
********************************** ****************************
In particular, with regard to writing this information, the I2RS **************************************************************
Agent should use the same mechanisms that the routing element already * RIB Manager *
uses to handle RIB input from multiple sources, so as to compatibly * +-------------------+ +---------------+ +------------+ *
change the system state. * | Unicast/multicast | | Policy-Based | | RIB Policy | *
* | RIBs & LIBs | | Routing | | Controls | *
* | route instances | | (ACLs, etc) | +------------+ *
* +-------------------+ +---------------+ *
**************************************************************
The multicast state added to the multicast RIB does not need to match Figure 2: Anticipated I2RS Services
to well-known protocol installed state. The I2RS Agent can create
arbitrary replication state in the RIB, subject to the advertised
capabilities of the routing element.
5.4.2. IGPs, BGP and Multicast Protocols There are relationships between different I2RS Services - whether
those be the need for the RIB to refer to specific interfaces, the
desire to refer to common complex types (e.g. links, nodes, IP
addresses), or the ability to refer to implementation-specific
functionality (e.g. pre-defined templates to be applied to interfaces
or for QoS behaviors that traffic is direct into).
Section Section 6.4.5 discussing information modeling constructs and
the range of relationship types that are applicable.
In addition to interacting with the consolidated RIB, the I2RS agent 6.4.1. Routing and Label Information Bases
may need to interact with the individual routing protocols on the
device. This interaction includes a number of different kinds of
operations:
o reading the various internal rib(s) of the routing protocol is Routing elements may maintain one or more Information Bases.
Examples include Routing Information Bases such as IPv4/IPv6 Unicast
or IPv4/IPv6 Multicast. Another such example includes the MPLS Label
Information Bases, per-platform- or per-interface." This
functionality, exposed via an I2RS Service, must interact smoothly
with the same mechanisms that the routing element already uses to
handle RIB input from multiple sources, so as to safely change the
system state. Conceptually, this can be handled by having the I2RS
Agent communicate with a RIB Manager as a separate routing source.
The point-to-multipoint state added to the RIB does not need to match
to well-known multicast protocol installed state. The I2RS Agent can
create arbitrary replication state in the RIB, subject to the
advertised capabilities of the routing element.
6.4.2. IGPs, BGP and Multicast Protocols
A separate I2RS Service can expose each routing protocol on the
device. Such I2RS services may include a number of different kinds
of operations:
o reading the various internal RIB(s) of the routing protocol is
often helpful for understanding the state of the network. often helpful for understanding the state of the network.
Directly writing these protocol-specific RIBs or databases is out Directly writing to these protocol-specific RIBs or databases is
of scope for I2RS. out of scope for I2RS.
o reading the various pieces of policy information the particular o reading the various pieces of policy information the particular
protocol instance is using to drive its operations. protocol instance is using to drive its operations.
o writing policy information such as interface attributes that are o writing policy information such as interface attributes that are
specific to the routing protocol or BGP policy that may indirectly specific to the routing protocol or BGP policy that may indirectly
manipulate attributes of routes carried in BGP. manipulate attributes of routes carried in BGP.
o writing routes or prefixes to be advertised via the protocol. o writing routes or prefixes to be advertised via the protocol.
skipping to change at page 15, line 4 skipping to change at page 19, line 36
o reading the various pieces of policy information the particular o reading the various pieces of policy information the particular
protocol instance is using to drive its operations. protocol instance is using to drive its operations.
o writing policy information such as interface attributes that are o writing policy information such as interface attributes that are
specific to the routing protocol or BGP policy that may indirectly specific to the routing protocol or BGP policy that may indirectly
manipulate attributes of routes carried in BGP. manipulate attributes of routes carried in BGP.
o writing routes or prefixes to be advertised via the protocol. o writing routes or prefixes to be advertised via the protocol.
o joining/removing interfaces from the multicast trees o joining/removing interfaces from the multicast trees
o subscribing to an information stream of route changes o subscribing to an information stream of route changes
o receiving notifications about peers coming up or going down o receiving notifications about peers coming up or going down
For example, the interaction with OSPF might include modifying the For example, the interaction with OSPF might include modifying the
local routing element's link metrics, announcing a locally-attached local routing element's link metrics, announcing a locally-attached
prefix, or reading some of the OSPF link-state database. However, prefix, or reading some of the OSPF link-state database. However,
direct modification of of the link-state database is NOT allowed to direct modification of of the link-state database MUST NOT allowed in
preserve network state consistency. order to preserve network state consistency.
5.4.3. MPLS 6.4.3. MPLS
The I2RS agent will need to interact with the protocols that create I2RS Services will be needed to expose the protocols that create
transport LSPs (e.g. LDP and RSVP-TE) as well as protocols (e.g. BGP, transport LSPs (e.g. LDP and RSVP-TE) as well as protocols (e.g. BGP,
LDP) that provide MPLS-based services (e.g. pseudowires, L3VPNs, LDP) that provide MPLS-based services (e.g. pseudowires, L3VPNs,
L2VPNs, etc). L2VPNs, etc). This should include all local information about LSPs
originating in, transiting, or terminating in this Routing Element.
5.4.4. Policy and QoS Mechanisms 6.4.4. Policy and QoS Mechanisms
Many network elements have separate policy and QoS mechanisms, Many network elements have separate policy and QoS mechanisms,
including knobs which affect local path computation and queue control including knobs which affect local path computation and queue control
capabilities. These capabilities vary widely across implementations, capabilities. These capabilities vary widely across implementations,
and I2RS cannot model the full range of information collection or and I2RS cannot model the full range of information collection or
manipulation of these attributes. A core set does need to be manipulation of these attributes. A core set does need to be
included in the I2RS data models and in the expected interfaces included in the I2RS information models and supported in the expected
between the I2RS Agent and the network element, in order to provide interfaces between the I2RS Agent and the network element, in order
basic capabilities and the hooks for future extensibility. to provide basic capabilities and the hooks for future extensibility.
[[Editor's note: This requires more discussion in the working
group.]]
6. I2RS Client Agent Interface By taking advantage of extensibility and sub-classing, information
models can specify use of a basic model that can be replaced by a
more detailed model.
6.1. Protocol Structure 6.4.5. Information Modeling, Device Variation, and Information
Relationships
One could view I2RS merely as a way to talk about the existing I2RS depends heavily on information models of the relevant aspects of
network management interfaces to a network element. That would be the Routing Elements to be manipulated. These models drive the data
quite limiting and would not meet the requirements elucidated models and protocol operations for I2RS. It is important that these
elsewhere. One could also view I2RS as a collection of protocols - informational models deal well with a wide variety of actual
some existing and some new - that meet the needs. While that could implementations of Routing Elements, as seen between different
be made to work, the complexity of such a mechanism would be quite products and different vendors. There are three ways that I2RS
high. One would need to develop means to coordinate information information models can address these variations: class or type
across a set of protocols that were not designed to work together. inheritance, optional features, and templating.
From a deployability perspective, this would not meet the goal of
simplicity. As a result, this architecture views the I2RS as an
interface supporting a single control and data exchange protocol.
Whether such a protocol is built upon extending existing mechanisms
or requires a new mechanism requires further investigation. That
protocol may use several underlying transports (TCP, SCTP, DCCP),
with suitable authentication and integrity protection mechanisms.
These different transports can support different types of
communication (e.g. control, reading, notifications, and information
collection) and different sets of data. Whatever transport is used
for the data exchange, it must also support suitable congestion
control mechanisms.
6.2. Channel 6.4.5.1. Managing Variation: Object Classes/Types and Inheritance
The uses of a single I2RS protocol does not imply that only one Information modeled by I2RS from a Routing Element can be described
channel of communication is required. There may be a range of in terms of classes or types or object. Different valid inheritance
reliability requirements, and to support the scaling there may need definitions can apply. What is appropriate for I2RS to use is not
to be channels originating from multiple sub-components of a routing determined in this architecture; for simplicity, class and subclass
element. These will all use the date exchange protocol, and will be used as the example terminology. This I2RS architecture does
establishment of additional channels for communication will be require the ability to address variation in Routing Elements by
coordinated between the I2RS client and the I2RS agent. allowing information models to define parent or base classes and
subclasses.
6.3. Negotiation The base or parent class defines the common aspects that all Routing
Elements are expected to support. Individual subclasses can
represent variations and additional capabilities. When applicable,
there may be several levels of refinement. The I2RS protocol can
then provide mechanisms to allow an I2RS client to determine which
classes a given I2RS Agent has available. Clients which only want
basic capabilities can operate purely in terms of base or parent
classes, while a client needing more details or features can work
with the supported sub-class(es).
Protocol support capabilities will vary across I2RS Clients and As part of I2RS information modeling, clear rules should be specified
Routing Elements supporting I2RS Agents. As such, capability for how the parent class and subclass can relate; for example, what
negotiation (such as which transports are supported beyond the changes a subclass can make to its parent? The description of such
minimum required to implement) will clearly be necessary. It is rules should be done so that it can apply across data modeling tools
until the I2RS data modeling language is selected.
6.4.5.1.1. Managing Variation: Optionality
I2RS Information Models must be clear about what aspects are
optional. For instance, must an instance of a class always contain a
particular data field X? If so, must the client provide a value for
X when creating the object or is there a well-defined default value?
From the Routing Element perspective, in the above example, is
support of X required so that values for X can be accepted and
processed? If not, how does the I2RS client determine whether the
I2RS agent can accept and apply values for X?
Optional behavior can also be extended to the ranges of values a
given piece of information can take, the length of strings, the
existence of particular events, and other aspects of information.
The information model needs to be clear about what is required of the
clients, what is required of agents, and what is permitted to each
one.
6.4.5.1.2. Managing Variation: Templating
A template is a collection of information to address a problem; it
cuts across the notions of class and object instances. A template
provides a set of defined values for a set of information fields and
can specify a set of values that must be provided to complete the
template. Further, a flexible template scheme may that some of the
defined values can be over-written.
For instance, assigning traffic to a particular service class might
be done by specifying a template Queueing with a parameter to
indicate Gold, Silver, or Best Effort. The details of how that is
carried out are not modeled. This does assume that the necessary
templates are made available on the Routing Element via some
mechanism other than I2RS. The idea is that by providing suitable
templates for tasks that need to be accomplished, with templates
implemented differently for different kinds of Routing Elements, the
client can easily interact with the Routing Element without concern
for the variations which are handled by values included in the
template.
If implementation variation can be exposed in other ways, templates
may not be needed. However, templates themselves could be objects
referenced in the protocol messages, with Routing Elements being
configured with the proper templates to complete the operation. This
is a topic for further discussion.
6.4.5.1.3. Object Relationships
Objects (in a Routing Element or otherwise) do not exist in
isolation. They are related to each other. One of the important
things a class definition does is represent the relationships between
instances of different classes. These relationships can be very
simple, or quite complicated. The following lists the information
relationships that the information models need to support.
[[Editors' note: All of these are for discussion, and it is expected
that the list may be changed during WG discussion.]]
6.4.5.1.3.1. Initialization
The simplest relationship is that one object instances is initialized
by copying another. For example, one may have an object instance
that represents the default setup for a tunnel, and all new tunnels
have fields copied from there if they are not set as part of
establishment. This is closely related to the templates discussed
above, but not identical. Since the relationship is only momentary
it is often not formally represented in modeling, but only captured
in the semantic description of the default object.
6.4.5.1.3.2. Correlation Identification
Often, it suffices to indicate in one object that it is related to a
second object, without having a strong binding between the two. So
an Identifier is used to represent the relationship. This can be
used to allow for late binding, or a weak binding that does not even
need to exist. A policy name in an object might indicate that if a
policy by that name exists, it is to be applied under some
circumstance. In modeling this is often represented by the type of
the value.
6.4.5.1.3.3. Object References
Sometimes the relationship between objects is stronger. A valid ARP
entry has to point to the active interface over which it was derived.
This is the classic meaning of an object reference in programming.
It can be used for relationships like containment or dependence.
This is usually represented by an explicit modeling link.
6.4.5.1.3.4. Active Reference
There is an even stronger form of coupling between objects if changes
in one of the two objects are always to be reflected in the state of
the other. For example, if a Tunnel has an MTU, and link MTU changes
need to immediately propagate to the Tunnel MTU, then the tunnel is
actively coupled to the link interface. This kind of active state
coupling implies some sort of internal bookkeeping to ensure
consistency, often conceptualized as a subscription model across
objects.
7. I2RS Client Agent Interface
7.1. One Control and Data Exchange Protocol
This I2RS Architecture presumes that there is one I2RS protocol for
control and data exchange. This helps meet the goal of simplicity
and thereby enhances deployability. Whether such a protocol is built
upon extending existing mechanisms or requires a new mechanism is
under active investigation. That protocol may use several underlying
transports (TCP, SCTP, DCCP), with suitable authentication and
integrity protection mechanisms. These different transports can
support different types of communication (e.g. control, reading,
notifications, and information collection) and different sets of
data. Whatever transport is used for the data exchange, it must also
support suitable congestion control mechanisms.
7.2. Communication Channels
Multiple communication channels and multiple types of communication
channels are required. There may be a range of requirements (e.g.
confidentiality, reliability), and to support the scaling there may
need to be channels originating from multiple sub-components of a
routing element and/or to multiple parts of an I2RS client. All such
communication channels will use the same higher level protocol. Use
of additional channels for communication will be coordinated between
the I2RS client and the I2RS agent.
7.3. Capability Negotiation
The support for different protocol capabilities and I2RS Services
will vary across I2RS Clients and Routing Elements supporting I2RS
Agents. Since each I2RS Service is required to include a capability
model (see Section 6.4), negotiation at the protocol level can be
restricted to protocol specifics and which I2RS Services are
supported.
Capability negotiation (such as which transports are supported beyond
the minimum required to implement) will clearly be necessary. It is
important that such negotiations be kept simple and robust, as such important that such negotiations be kept simple and robust, as such
mechanisms are often a source of difficulty in implementation and mechanisms are often a source of difficulty in implementation and
deployment. deployment.
Negotiation should be broken into several aspects, such as protocol The protocol capability negotiation can be segmented into the basic
capablities and I2RS services and model types supported. version negotiation (required to ensure basic communication), and the
more complex capability exchange which can take place within the base
protocol mechanisms. In particular, the more complex protocol and
mechanism negotiation can be addressed by defining information models
for both the I2RS Agent and the I2RS Client. These information
models can describe the various capability options. This can then
represent and be used to communicate important information about the
agent, and the capabilities thereof.
6.4. Identity and Security Role 7.4. Identity and Security Role
Each I2RS Client will have a unique identity; it can also have Each I2RS Client will have a unique identity; it can also have
secondary identities to be used for troubleshooting. A secondary secondary identities to be used for troubleshooting. A secondary
identity is merely a unique, opaque identifier that may be helpful in identity is merely a unique, opaque identifier that may be helpful in
troubleshooting. Via authentication and authorization mechanisms, troubleshooting. Via authentication and authorization mechanisms
the I2RS agent will have a specific scope for reading data, for based on the primary unique identity, the I2RS Client will have a
writing data, and limitations on the resources that can be consumed. specific scope for reading data, for writing data, and limitations on
The scopes need to specify both the data and the value ranges. the resources that can be consumed. The scopes need to specify both
the data and the value ranges.
6.4.1. Client Redundancy 7.4.1. Client Redundancy
I2RS must support client redundancy. At the simplest, this can be I2RS must support client redundancy. At the simplest, this can be
handled by having a primary and a backup network application that handled by having a primary and a backup network application that
both use the same client identity and can successfully authenticate both use the same client identity and can successfully authenticate
as such. Since I2RS does not require a continuous transport as such. Since I2RS does not require a continuous transport
connection and supports multiple transport sessions, this can provide connection and supports multiple transport sessions, this can provide
some basic redundancy. However, it does not address concerns for some basic redundancy. However, it does not address concerns for
troubleshooting and accountability about knowing which network troubleshooting and accountability about knowing which network
application is actually active. At a minimum, basic transport application is actually active. At a minimum, basic transport
information about each connection and time can be logged with the information about each connection and time can be logged with the
identity. Further discussion is necessary to determine whether identity.
additional client identification information is necessary.[[Editor's
note: This requires more discussion in the working group.]]
6.5. Connectivity 7.5. Connectivity
A client may or may not maintain an active communication channel with A client may or may not maintain an active communication channel with
an agent. Therefore, an agent may need to open a communication an agent. Therefore, an agent may need to open a communication
channel to the client to communicate previously requested channel to the client to communicate previously requested
information. The lack of an active communication channel does not information. The lack of an active communication channel does not
imply that the associated client is non-functional. When imply that the associated client is non-functional. When
communication is required, the agent or client can open a new communication is required, the agent or client can open a new
communication channel. communication channel.
State held by an agent that is owned by a client should not be State held by an agent that is owned by a client should not be
removed or cleaned up when a client is no longer communicating - even removed or cleaned up when a client is no longer communicating - even
if the agent cannot successfully open a new communication channel to if the agent cannot successfully open a new communication channel to
the client. the client.
There are three different assumptions that can apply to handling dead For many applications, it may be desirable to clean up state if a
clients. The first is that the network applications or management network application dies before removing the state it has created.
systems will detect a dead network application and either restart Typically, this is dealt with in terms of network application
that network application or clean up any state left behind. The redundancy. If stronger mechanisms are desired, mechanisms outside
second is to allow state expiration, expressed as a policy associated of I2RS may allow a supervisory network application to monitor I2RS
with the I2RS client's role. The state expiration could occur after clients, and based on policy known to the supervisor clean up state
there has been no successful communication channel to or from the if applications die. More complex mechanism instantiated in the I2RS
I2RS client for the policy-specified duration. The third is that the agent would add complications to the I2RS protocol and are thus left
client could explicitly request state clean-up if a particular for future work.
transport session is terminated.
6.6. Notifications Some examples of such a mechanism include the following. In one
option, the client could request state clean-up if a particular
transport session is terminated. The second is to allow state
expiration, expressed as a policy associated with the I2RS client's
role. The state expiration could occur after there has been no
successful communication channel to or from the I2RS client for the
policy-specified duration.
7.6. Notifications
As with any policy system interacting with the network, the I2RS As with any policy system interacting with the network, the I2RS
Agent needs to be able to receive notifications of changes in network Client needs to be able to receive notifications of changes in
state. Notifications here refers to changes which are unanticipated, network state. Notifications here refers to changes which are
represent events outside the control of the systems (such as unanticipated, represent events outside the control of the systems
interface failures on controlled devices), or are sufficiently sparse (such as interface failures on controlled devices), or are
as to be anomalous in some fashion. sufficiently sparse as to be anomalous in some fashion. A
notification may also be due to a regular event.
Such events may be of interest to multiple I2RS Clients controlling Such events may be of interest to multiple I2RS Clients controlling
data handled by an I2RS Agent, and to multiple other I2RS clients data handled by an I2RS Agent, and to multiple other I2RS clients
which are collecting information without exerting control. The which are collecting information without exerting control. The
architecture therefore requires that it be practical for I2RS Clients architecture therefore requires that it be practical for I2RS Clients
to register for a range of notifications, and for the I2R Agents to to register for a range of notifications, and for the I2RS Agents to
send notifications to a number of Clients. send notifications to a number of Clients. The I2RS Client should be
able to filter the specific notifications that will be received; the
specific types of events and filtering operations can vary by
information model and need to be specified as part of the information
model.
As the I2RS is developed, it is likely that a management information- The I2RS information model needs to include representation of these
model and data-model will be required to describe event notifications events. As discussed earlier, the capability information in the
for general or I2RS errors. model will allow I2RS clients to understand which events a given I2RS
Agent is capable of generating.
For performance and scaling by the I2RS client and general For performance and scaling by the I2RS client and general
information privacy, an I2RS Client needs to be able to register for information privacy, an I2RS Client needs to be able to register for
just the events it is interested in. It is also possible that I2RS just the events it is interested in. It is also possible that I2RS
might might provide a stream of notifications via a publish/subscribe might might provide a stream of notifications via a publish/subscribe
mechanism that is not amenable to having the I2RS agent do the mechanism that is not amenable to having the I2RS agent do the
filtering. filtering.
6.7. Information collection 7.7. Information collection
One of the other important aspects of the I2RS is that it is intended One of the other important aspects of the I2RS is that it is intended
to simplify collecting information about the state of network to simplify collecting information about the state of network
elements. This includes both getting a snapshot of a large amount of elements. This includes both getting a snapshot of a large amount of
data about the current state of the network element, and subscribing data about the current state of the network element, and subscribing
to a feed of the ongoing changes to the set of data or a subset to a feed of the ongoing changes to the set of data or a subset
thereof. This is considered architecturally separate from thereof. This is considered architecturally separate from
notifications due to the differences in information rate and total notifications due to the differences in information rate and total
volume. volume.
6.8. Multi-Headed Control 7.8. Multi-Headed Control
As was described earlier, an I2RS Agent interacts with multiple I2RS As was described earlier, an I2RS Agent interacts with multiple I2RS
Clients who are actively controlling the network element. From an Clients who are actively controlling the network element. From an
architecture and design perspective, the assumption is that by means architecture and design perspective, the assumption is that by means
outside of this system the data to be manipulated within the network outside of this system the data to be manipulated within the network
element is appropriately partitioned so that any given piece of element is appropriately partitioned so that any given piece of
information is only being manipulated by a single I2RS Client. information is only being manipulated by a single I2RS Client.
Nonetheless, unexpected interactions happen and two (or more) I2RS Nonetheless, unexpected interactions happen and two (or more) I2RS
clients may attempt to manipulate the same piece of data. This is clients may attempt to manipulate the same piece of data. This is
considered an error case. This architecture does not attempt to considered an error case. This architecture does not attempt to
determine what the right state of data is in such a collision Rather, determine what the right state of data should be when such a
the architecture mandates that there be decidable means by which I2RS collision happens. Rather, the architecture mandates that there be
Agents will handle the collisions. The current recommendation is to decidable means by which I2RS Agents handle the collisions. The
have a simple priority associated with each I2RS clients, and the mechanism for this is to have a simple priority associated with each
highest priority change remains in effect. In the case of priority I2RS clients, and the highest priority change remains in effect. In
ties, the first client whose attribution is associated with the data the case of priority ties, the first client whose attribution is
will keep control associated with the data will keep control.
In order for this to be useful for I2RS Clients, it is important that In order for this approach to multi-headed control to be useful for
it be possible for an I2RS Client to register for changes to any I2RS I2RS Clients, it is important that it be possible for an I2RS Client
manipulatable data that it may care about. The I2RS client may then to register for changes to any changes made by I2RS to data that it
may care about. This is included in the I2RS event mechanisms. This
also needs to apply to changes made by CLI/NETCONF/SNMP within the
write-scope of the I2RS Agent, as the same priority mechanism (even
if it is "CLI always wins") applies there. The I2RS client may then
respond to the situation as it sees fit. respond to the situation as it sees fit.
6.9. Transactions 7.9. Transactions
In the interest of simplicity, the I2RS architecture does not include In the interest of simplicity, the I2RS architecture does not include
multi-message atomicity and rollback mechanisms. Rather, it includes multi-message atomicity and rollback mechanisms. Rather, it includes
a small range of error handling for a set of operations included in a a small range of error handling for a set of operations included in a
single message. An I2RS Client may indicate one of the following single message. An I2RS Client may indicate one of the following
three error handling for a given message with multiple operations three error handling for a given message with multiple operations
which it sends to an I2RS Agent: which it sends to an I2RS Agent:
Perform all or none: This traditional SNMP semantic indicates that Perform all or none: This traditional SNMP semantic indicates that
other I2RS agent will keep enough state when handling a single other I2RS agent will keep enough state when handling a single
message to roll back the operations within that message. Either message to roll back the operations within that message. Either
all the operations will succeed, or none of them will be applied all the operations will succeed, or none of them will be applied
and an error message will report the single failure which caused and an error message will report the single failure which caused
the not to be applied. This is useful when there are, for them not to be applied. This is useful when there are, for
example, mutual dependencies across operations in the message. example, mutual dependencies across operations in the message.
Perform until error: In this case, the operations in the message Perform until error: In this case, the operations in the message
are applied in the specified order. When an error occurs, no are applied in the specified order. When an error occurs, no
further operations are applied, and an error is returned further operations are applied, and an error is returned
indicating the failure. This is useful if there are dependencies indicating the failure. This is useful if there are dependencies
among the operations and they can be topologically sorted. among the operations and they can be topologically sorted.
Perform all storing errors: In this case, the I2RS Agent will Perform all storing errors: In this case, the I2RS Agent will
attempt to perform all the operations in the message, and will attempt to perform all the operations in the message, and will
return error indications for each one that fails. This is useful return error indications for each one that fails. This is useful
when there is no dependency across the operation, or where the when there is no dependency across the operation, or where the
client would prefer to sort out the effect of errors on its own. client would prefer to sort out the effect of errors on its own.
In the interest of robustness and clarity of protocol state, the In the interest of robustness and clarity of protocol state, the
protocol will include an explicit reply to modification operations protocol will include an explicit reply to modification or write
even when they fully succeed. operations even when they fully succeed.
7. Manageability Considerations 8. Manageability Considerations
Manageability plays a key aspect in I2RS. Some initial examples Manageability plays a key aspect in I2RS. Some initial examples
include: include:
Resource Limitations: Using I2RS, applications can consume Resource Limitations: Using I2RS, applications can consume
resources, whether those be operations in a time-frame, entries in resources, whether those be operations in a time-frame, entries in
the RIB, stored operations to be triggered, etc. The ability to the RIB, stored operations to be triggered, etc. The ability to
set resource limits based upon authorization is important. set resource limits based upon authorization is important.
Configuration Interactions: The interaction of state installed via Configuration Interactions: The interaction of state installed via
the I2RS and via a router's configuration needs to be clearly the I2RS and via a router's configuration needs to be clearly
defined. As described in this architecture, a simple priority defined. As described in this architecture, a simple priority
that is configured can be used to express the desired policy. that is configured is used to provide sufficient policy
flexibility.
8. Security Considerations
This framework describes interfaces that clearly require serious
consideration of security. The ability to identify, authenticate and
authorize applications that wish to install state is necessary and
briefly described in Section 3.4. Security of communications from
the applications is also required as discussed in Section 6.1.
Scopes for reading and writing data specified in the context of the
data models and the value ranges are discussed briefly in
Section 6.4.
9. IANA Considerations 9. IANA Considerations
This document includes no request to IANA. This document includes no request to IANA.
10. Acknowledgements 10. Acknowledgements
Significant portions of this draft came from draft-ward-i2rs- Significant portions of this draft came from draft-ward-i2rs-
framework-00 and draft-atlas-i2rs-policy-framework-00. framework-00 and draft-atlas-i2rs-policy-framework-00.
The authors would like to thank Nitin Bahadur, Shane Amante, Ed The authors would like to thank Nitin Bahadur, Shane Amante, Ed
Crabbe, Ken Gray, Carlos Pignataro, Wes George, Joe Clarke, Juergen Crabbe, Ken Gray, Carlos Pignataro, Wes George, Ron Bonica, Joe
Schoenwalder, and Jamal Hadi Salim for their suggestions and review. Clarke, Juergen Schoenwalder, Jamal Hadi Salim, Scott Brim, and
Thomas Narten for their suggestions and review.
11. Informative References 11. Informative References
[I-D.atlas-i2rs-problem-statement] [I-D.ietf-i2rs-problem-statement]
Atlas, A., Nadeau, T., and D. Ward, "Interface to the Atlas, A., Nadeau, T., and D. Ward, "Interface to the
Routing System Problem Statement", draft-atlas-i2rs- Routing System Problem Statement", draft-ietf-i2rs-
problem-statement-01 (work in progress), July 2013. problem-statement-00 (work in progress), August 2013.
[I-D.ietf-idr-ls-distribution]
Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
Ray, "North-Bound Distribution of Link-State and TE
Information using BGP", draft-ietf-idr-ls-distribution-04
(work in progress), November 2013.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, March
2012.
Authors' Addresses Authors' Addresses
Alia Atlas Alia Atlas
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
USA USA
Email: akatlas@juniper.net Email: akatlas@juniper.net
skipping to change at page 21, line 18 skipping to change at page 29, line 23
Dave Ward Dave Ward
Cisco Systems Cisco Systems
Tasman Drive Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: wardd@cisco.com Email: wardd@cisco.com
Thomas D. Nadeau Thomas D. Nadeau
Juniper Networks Brocade
Email: tnadeau@juniper.net Email: tnadeau@lucidvision.com
 End of changes. 122 change blocks. 
464 lines changed or deleted 857 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/