draft-ietf-i2rs-architecture-02.txt   draft-ietf-i2rs-architecture-03.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: August 16, 2014 Ericsson Expires: November 16, 2014 Ericsson
S. Hares S. Hares
Hickory Hill Consulting Hickory Hill Consulting
D. Ward D. Ward
Cisco Systems Cisco Systems
T. Nadeau T. Nadeau
Brocade Brocade
February 12, 2014 May 15, 2014
An Architecture for the Interface to the Routing System An Architecture for the Interface to the Routing System
draft-ietf-i2rs-architecture-02 draft-ietf-i2rs-architecture-03
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 August 16, 2014. This Internet-Draft will expire on November 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 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. Drivers for the I2RS Architecture . . . . . . . . . . . . 4 1.1. Drivers for the I2RS Architecture . . . . . . . . . . . . 4
1.2. Architectural Overview . . . . . . . . . . . . . . . . . 4 1.2. Architectural Overview . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Key Architectural Properties . . . . . . . . . . . . . . . . 10 3. Key Architectural Properties . . . . . . . . . . . . . . . . 10
3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Model-Driven Programmatic Interfaces . . . . . . . . . . 11 3.3. Model-Driven Programmatic Interfaces . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
4.1. Identity and Authentication . . . . . . . . . . . . . . . 12 4.1. Identity and Authentication . . . . . . . . . . . . . . . 13
4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 13
5. Network Applications and I2RS Client . . . . . . . . . . . . 13 5. Network Applications and I2RS Client . . . . . . . . . . . . 14
5.1. Example Network Application: Topology Manager . . . . . . 14 5.1. Example Network Application: Topology Manager . . . . . . 15
6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 14 6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 15
6.1. Relationship to its Routing Element . . . . . . . . . . . 15 6.1. Relationship to its Routing Element . . . . . . . . . . . 15
6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 15 6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 16
6.2.1. I2RS Agent Failure . . . . . . . . . . . . . . . . . 15 6.2.1. I2RS Agent Failure . . . . . . . . . . . . . . . . . 16
6.2.2. Starting and Ending . . . . . . . . . . . . . . . . . 16 6.2.2. Starting and Ending . . . . . . . . . . . . . . . . . 17
6.2.3. Reversion . . . . . . . . . . . . . . . . . . . . . . 16 6.2.3. Reversion . . . . . . . . . . . . . . . . . . . . . . 17
6.3. Interactions with Local Config . . . . . . . . . . . . . 17 6.3. Interactions with Local Config . . . . . . . . . . . . . 17
6.4. Routing Components and Associated I2RS Services . . . . . 17 6.4. Routing Components and Associated I2RS Services . . . . . 18
6.4.1. Routing and Label Information Bases . . . . . . . . . 18 6.4.1. Routing and Label Information Bases . . . . . . . . . 19
6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 19 6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 20
6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 19 6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 20
6.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 20 6.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 21
6.4.5. Information Modeling, Device Variation, and 6.4.5. Information Modeling, Device Variation, and
Information Relationships . . . . . . . . . . . . . . 20 Information Relationships . . . . . . . . . . . . . . 21
6.4.5.1. Managing Variation: Object Classes/Types and 6.4.5.1. Managing Variation: Object Classes/Types and
Inheritance . . . . . . . . . . . . . . . . . . . 20 Inheritance . . . . . . . . . . . . . . . . . . . 21
6.4.5.1.1. Managing Variation: Optionality . . . . . . . 21 6.4.5.2. Managing Variation: Optionality . . . . . . . . . 22
6.4.5.1.2. Managing Variation: Templating . . . . . . . 21 6.4.5.3. Managing Variation: Templating . . . . . . . . . 22
6.4.5.1.3. Object Relationships . . . . . . . . . . . . 22 6.4.5.4. Object Relationships . . . . . . . . . . . . . . 23
7. I2RS Client Agent Interface . . . . . . . . . . . . . . . . . 23 6.4.5.4.1. Initialization . . . . . . . . . . . . . . . 23
7.1. One Control and Data Exchange Protocol . . . . . . . . . 23 6.4.5.4.2. Correlation Identification . . . . . . . . . 23
7.2. Communication Channels . . . . . . . . . . . . . . . . . 23 6.4.5.4.3. Object References . . . . . . . . . . . . . . 24
7.3. Capability Negotiation . . . . . . . . . . . . . . . . . 23 6.4.5.4.4. Active Reference . . . . . . . . . . . . . . 24
7.4. Identity and Security Role . . . . . . . . . . . . . . . 24 7. I2RS Client Agent Interface . . . . . . . . . . . . . . . . . 24
7.4.1. Client Redundancy . . . . . . . . . . . . . . . . . . 24 7.1. One Control and Data Exchange Protocol . . . . . . . . . 24
7.2. Communication Channels . . . . . . . . . . . . . . . . . 24
7.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 24 7.3. Capability Negotiation . . . . . . . . . . . . . . . . . 25
7.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 25 7.4. Identity and Security Role . . . . . . . . . . . . . . . 25
7.7. Information collection . . . . . . . . . . . . . . . . . 26 7.4.1. Client Redundancy . . . . . . . . . . . . . . . . . . 25
7.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 26 7.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 26
7.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 27 7.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 26
8. Manageability Considerations . . . . . . . . . . . . . . . . 27 7.7. Information collection . . . . . . . . . . . . . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 7.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 27
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 7.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 28
11. Informative References . . . . . . . . . . . . . . . . . . . 28 8. Manageability Considerations . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
11. Informative References . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
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, and 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.
skipping to change at page 4, line 8 skipping to change at page 4, line 13
could harness to 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 desired. leveraging the existing routing system as desired.
Although the I2RS architecture is general enough to support Although the I2RS architecture is general enough to support
information and data models for a variety of data, the I2RS, and information and data models for a variety of data, and aspects of the
therefore this document, are specifically focused on an interface for I2RS solution may be useful in domain other than routing, I2RS and
routing data. this document are specifically focused on an interface for routing
data.
1.1. Drivers for the I2RS Architecture 1.1. Drivers for the I2RS Architecture
There are four key drivers that shape the I2RS architecture. First There are four key drivers that shape the I2RS architecture. First
is the need for an interface that is programmatic, asynchronous, and is the need for an interface that is programmatic, asynchronous, and
offers fast, interactive access. Second is the access to structured offers fast, interactive access. Second is the access to structured
information and state that is frequently not directly configurable or information and state that is frequently not directly configurable or
modeled in existing implementations or configuration protocols. modeled in existing implementations or configuration protocols.
Third is the ability to subscribe to structured, filterable event Third is the ability to subscribe to structured, filterable event
notifications from the router. Fourth, the operation of I2RS is to notifications from the router. Fourth, the operation of I2RS is to
skipping to change at page 5, line 23 skipping to change at page 5, line 32
Agent 1 provides services to Clients A, B and P while Agent 2 Agent 1 provides services to Clients A, B and P while Agent 2
provides services to only Clients B and P. provides services to only Clients B and P.
I2RS agents and clients communicate with one another using an I2RS agents and clients communicate with one another using an
asynchronous protocol. Therefore, a single client can post multiple asynchronous protocol. Therefore, a single client can post multiple
simultaneous requests, either to a single agent or to multiple simultaneous requests, either to a single agent or to multiple
agents. Furthermore, an agent can process multiple requests, either agents. Furthermore, an agent can process multiple requests, either
from a single client or from multiple clients, simultaneously. from a single client or from multiple clients, simultaneously.
The I2RS agent provides read and write access to selected data on the The I2RS agent provides read and write access to selected data on the
routing element that are organized into I2RS Services. routing element that are organized into I2RS Services. Section 4
Section Section 4 describes how access is mediated by authentication describes how access is mediated by authentication and access control
and access control mechanisms. In addition to read and write access, mechanisms. In addition to read and write access, the I2RS agent
the I2RS agent allows clients to subscribe to different types of allows clients to subscribe to different types of notifications about
notifications about events affecting different object instances. An events affecting different object instances. An example not related
example not related to the creation, modification or deletion of an to the creation, modification or deletion of an object instance is
object instance is when a next-hop in the RIB is resolved enough to when a next-hop in the RIB is resolved enough to be used or when a
be used or when a particular route is selected by the RIB Manager for particular route is selected by the RIB Manager for installation into
installation into the forwarding plane. Please see Section 7.6 and the forwarding plane. Please see Section 7.6 and Section 7.7 for
Section 7.7 for details. details.
The scope of I2RS is to define the interactions between the I2RS The scope of I2RS is to define the interactions between the I2RS
agent and the I2RS client and the associated proper behavior of the agent and the I2RS client and the associated proper behavior of the
I2RS agent and I2RS client. I2RS agent and I2RS client.
****************** ***************** ***************** ****************** ***************** *****************
* Application C * * Application D * * Application E * * Application C * * Application D * * Application E *
****************** ***************** ***************** ****************** ***************** *****************
^ ^ ^ ^ ^ ^
| | | | | |
skipping to change at page 6, line 26 skipping to change at page 6, line 35
* | Agent 1 | * * | Agent 2 | * * | Agent 1 | * * | Agent 2 | *
* +---------------------+ * * +---------------------+ * * +---------------------+ * * +---------------------+ *
* ^ ^ ^ ^ * * ^ ^ ^ ^ * * ^ ^ ^ ^ * * ^ ^ ^ ^ *
* | | | | * * | | | | * * | | | | * * | | | | *
* v | | v * * v | | v * * v | | v * * v | | v *
* +---------+ | | +--------+ * * +---------+ | | +--------+ * * +---------+ | | +--------+ * * +---------+ | | +--------+ *
* | Routing | | | | Local | * * | Routing | | | | Local | * * | Routing | | | | Local | * * | Routing | | | | Local | *
* | and | | | | Config | * * | and | | | | Config | * * | and | | | | Config | * * | and | | | | Config | *
* |Signaling| | | +--------+ * * |Signaling| | | +--------+ * * |Signaling| | | +--------+ * * |Signaling| | | +--------+ *
* +---------+ | | ^ * * +---------+ | | ^ * * +---------+ | | ^ * * +---------+ | | ^ *
* ^ | |scoped | * * ^ | |scoped | * * ^ | | | * * ^ | | | *
* | |----| | | * * | |----| | | * * | |----| | | * * | |----| | | *
* v | v v * * v | v v * * v | v v * * v | v v *
* +----------+ +------------+ * * +----------+ +------------+ * * +----------+ +------------+ * * +----------+ +------------+ *
* | Dynamic | | Static | * * | Dynamic | | Static | * * | Dynamic | | Static | * * | Dynamic | | Static | *
* | System | | System | * * | System | | System | * * | System | | System | * * | System | | System | *
* | State | | State | * * | State | | State | * * | State | | State | * * | State | | State | *
* +----------+ +------------+ * * +----------+ +------------+ * * +----------+ +------------+ * * +----------+ +------------+ *
* * * * * * * *
* Routing Element 1 * * Routing Element 2 * * Routing Element 1 * * Routing Element 2 *
******************************** ******************************** ******************************** ********************************
skipping to change at page 8, line 9 skipping to change at page 8, line 21
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. In order to keep the protocol simple, the current view operations. In order to keep the protocol simple, two clients should
is that two clients should not be attempting to write (modify) the not attempt to write (modify) the same piece of information on an
same piece of information. Such collisions may happen, but are I2RS Agent. This is considered an error. However, such collisions
considered error cases that should be resolved by the network may happen and section 7.8 (multi-headed control) describes how the
applications and management systems. I2RS agent resolves collision by first utilizing priority to resolve
collisions, and second by servicing the requests in a first in, first
served basis. The i2rs architecture includes this definition of
behavior for this case simply for predictability not because this is
an intended result. This predictability will simplify the error
handling and suppress oscillations. If additional error cases beyond
this simple treatment are required, these these error cases should be
resolved by the network applications and management systems.
In contrast, although multiple I2RS clients may need to supply data In contrast, although multiple I2RS clients may need to supply data
into the same list (e.g. a prefix or filter list), this is not into the same list (e.g. a prefix or filter list), this is not
considered an error and must be correctly handled. The nuances so considered an error and must be correctly handled. The nuances so
that writers do not normally collide should be handled in the that writers do not normally collide should be handled in the
information models. 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 7.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 6.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. A tivial example of this is when two between write operations. A basic example of this is when two
different but overlapping prefixes are written with different different but overlapping prefixes are written with different
forwarding behavior. Detection and avoidance of such interactions is forwarding behavior. Detection and avoidance of such interactions is
outside the scope of the I2RS work and is left to agent design and outside the scope of the I2RS work and is left to agent design and
implementation. 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
skipping to change at page 10, line 15 skipping to change at page 10, line 34
client is coordinating such communication. client is coordinating such communication.
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
Several key architectural properties for the I2RS protocol are
elucidated below (simplicity, extensibility, and model-driven
programmatic interfaces). However, some architecture principles such
as performance and scaling are not described below because they are
discussed in [I-D.ietf-i2rs-problem-statement] and because the
performance and scaling requires varies based on the particular use-
cases.
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 available to the routing and forwarding system. the information available to the routing and forwarding system.
Making 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 quantity and diversity of related challenges in doing so. First, the quantity and diversity of
information potentially available is very large. Second, the information potentially available is very large. Second, the
variation both in the structure of the data and in the kinds of variation both in the structure of the data and in the kinds of
operations required tends to introduce protocol complexity. operations required tends to introduce protocol complexity.
skipping to change at page 11, line 49 skipping to change at page 12, line 26
description of the assumed security environment for I2RS. The I2RS description of the assumed security environment for I2RS. The I2RS
Agent associated with a Routing Element is a trusted part of that Agent associated with a Routing Element is a trusted part of that
Routing Element. For example, it may be part of a vendor-distributed Routing Element. For example, it may be part of a vendor-distributed
signed software image for the entire Routing Element or it may be signed software image for the entire Routing Element or it may be
trusted signed application that an operator has installed. The I2RS trusted signed application that an operator has installed. The I2RS
Agent is assumed to have a separate authentication and authorization Agent is assumed to have a separate authentication and authorization
channel by which it can validate both the identity and permissions channel by which it can validate both the identity and permissions
associated with an I2RS Client. To support numerous and speedy associated with an I2RS Client. To support numerous and speedy
interactions between the I2RS Agent and I2RS Client, it is assumed interactions between the I2RS Agent and I2RS Client, it is assumed
that the I2RS Agent can also cache that particular I2RS Clients are that the I2RS Agent can also cache that particular I2RS Clients are
trusted and their associated authorized scope. This implies that trusted and their associated authorized scope. This implies that the
either in a pull model, the permission information may be old until permission information may be old either in a pull model until the
the I2RS Agent rerequests it, or in a push model, that the I2RS Agent re-requests it, or in a push model until the
authentication and authorization channel can notify the I2RS Agent of authentication and authorization channel can notify the I2RS Agent of
changes. changes.
An I2RS Client is not automatically trustworthy. It has identity An I2RS Client is not automatically trustworthy. It has identity
information and applications using that I2RS Client should be aware information and applications using that I2RS Client should be aware
of the scope limitations of that I2RS Client. If the I2RS Client is of the scope limitations of that I2RS Client. If the I2RS Client is
acting as a broker for multiple applications, managing the security, acting as a broker for multiple applications, managing the security,
authentication and authorization for that communication is out of authentication and authorization for that communication is out of
scope; nothing prevents I2RS and a separate authentication and scope; nothing prevents I2RS and a separate authentication and
authorization channel from being used. Regardless of mechanism, an authorization channel from being used. Regardless of mechanism, an
skipping to change at page 12, line 35 skipping to change at page 13, line 14
Other communications via I2RS will not require integrity, Other communications via I2RS will not require integrity,
confidentiality, and replay protection. For instance, if an I2RS confidentiality, and replay protection. For instance, if an I2RS
Client subscribes to an information stream of prefix announcements Client subscribes to an information stream of prefix announcements
from OSPF, those may require integrity but probably not from OSPF, those may require integrity but probably not
confidentiality or replay protection. Similarly, an information confidentiality or replay protection. Similarly, an information
stream of interface statistics may not even require guaranteed stream of interface statistics may not even require guaranteed
delivery. In Section 7.2, more reasoning for multiple communication delivery. In Section 7.2, more reasoning for multiple communication
channels is provided. From the security perspective, it is critical channels is provided. From the security perspective, it is critical
to realize that an I2RS Agent may open a new communication channel to realize that an I2RS Agent may open a new communication channel
based upon information provided by an I2RS Client; to avoid an based upon information provided by an I2RS Client (as described in
indirect attack, such a request must be done in the context of an Section 7.2). For example, a I2RS client may request notifications
authenticated and authorized client whose communications cannot have of certain events and the agent will open a communication channel to
been altered. report such events. Therefore, 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 4.1. Identity and Authentication
As discussed above, all control exchanges between the I2RS client and As discussed above, all control exchanges between the I2RS client and
agent should be authenticated and integrity protected (such that the agent should be authenticated and integrity protected (such that the
contents cannot be changed without detection). Further, manipulation contents cannot be changed without detection). Further, manipulation
of the system must be accurately attributable. In an ideal of the system must be accurately attributable. In an ideal
architecture, even information collection and notification should be architecture, even information collection and notification should be
protected; this may be subject to engineering tradeoffs during the protected; this may be subject to engineering tradeoffs during the
design. design.
skipping to change at page 14, line 9 skipping to change at page 14, line 39
elements. elements.
In the broker architecture, multiple network-oriented applications In the broker architecture, multiple network-oriented applications
communicate in an unspecified fashion to a broker application that communicate in an unspecified fashion to a broker application that
contains an I2RS Client. That broker application requires additional contains an I2RS Client. That broker application requires additional
functionality for authentication and authorization of the network- functionality for authentication and authorization of the network-
oriented applications; such functionality is out of scope for I2RS oriented applications; such functionality is out of scope for I2RS
but similar considerations to those described in Section 4.2 do but similar considerations to those described in Section 4.2 do
apply. As discussed in Section 4.1, the broker I2RS Client should apply. As discussed in Section 4.1, the broker I2RS Client should
determine distinct opaque identifiers for each network-oriented determine distinct opaque identifiers for each network-oriented
application that is using it. The the broker I2RS Client can pass application that is using it. The broker I2RS Client can pass along
along the appropriate value as a secondary identifier which can be the appropriate value as a secondary identifier which can be used for
used for tracking attribution of operations. tracking attribution of operations.
In the third architecture, a routing element or network-oriented In a third architecture, a routing element or network-oriented
application that uses an I2RS Client to access services on a application that uses an I2RS Client to access services on a
different routing element may also contain an I2RS agent to provide different routing element may also contain an I2RS agent to provide
services to other network-oriented applications. However, where the services to other network-oriented applications. However, where the
needed information and data models for those services differs from needed information and data models for those services differs from
that of a conventional routing element, those models are, at least that of a conventional routing element, those models are, at least
initially, out of scope for I2RS. Below is an example of such a initially, out of scope for I2RS. Below is an example of such a
network application network application
5.1. Example Network Application: Topology Manager 5.1. Example Network Application: Topology Manager
skipping to change at page 15, line 18 skipping to change at page 15, line 45
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. There may be multiple I2RS Agents
I2RS agent would have only one locus per I2RS service for within the same router. In such a case, they must have non-
manipulation of routing element state. overlapping sets of information which they manipulate.
6.2. I2RS State Storage 6.2. I2RS State Storage
State modification requests are sent to the I2RS agent in a routing 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, subject to the authorization discussed these changes to the system, subject to the authorization discussed
above. The I2RS agent will retain knowledge of the changes it has above. The I2RS agent will retain knowledge of the changes it has
applied, and the client on whose behalf it applied the changes. The applied, and the client on whose behalf it applied the changes. The
I2RS agent will also store active subscriptions. These sets of data I2RS agent will also store active subscriptions. These sets of data
form the I2RS data store. This data is retained by the agent until form the I2RS data store. This data is retained by the agent until
the state is removed by the client, overridden by some other the state is removed by the client, overridden by some other
operation such as CLI, or the device reboots. Meaningful logging of operation such as CLI, or the device reboots. Meaningful logging of
the application and removal of changes is recommended. I2RS applied the application and removal of changes is recommended. I2RS applied
changes to the routing element state will not be retained across changes to the routing element state will not be retained across
routing element reboot. The I2RS data store is not preserved across routing element reboot. The I2RS data store is not preserved across
routing element reboots; thus the I2RS agent will not attempt to routing element reboots; thus the I2RS agent will not attempt to
reapply such changes after a reboot. reapply such changes after a reboot.
6.2.1. I2RS Agent Failure 6.2.1. I2RS Agent Failure
If it is possible for an I2RS Agent to fail independently of the It is expected that an I2RS Agent may fail independently of the
associated routing element, the behavior for any associated ephemeral associated routing element. This could happen because I2RS is
I2RS state needs to be clearly described. The I2RS state should be disabled on the routing element or because the I2RS Agent, a separate
preserved until the associated routing element has itself rebooted or process or even running on a separate processor, experiences an
until the I2RS state is explicitly torn down. This is desirable unexpected failure. Just as routing state learned from a failed
since the I2RS Client has no way of learning that an I2RS Agent has source is removed, the ephemeral I2RS state will usually be removed
unexpected failed until that I2RS Agent has restarted; in the shortly after the failure is detected or as part of a graceful
interval between failure and recovery, the I2RS Client will be shutdown process. To handle I2RS Agent failure, the I2RS Agent must
assuming that its ephemeral state remains. If failure of the I2RS use two different notifications.
agent causes the ephemeral I2RS state to be removed, then this should
be indicated via a capability. NOTIFICIATON_I2RS_AGENT_STARTING: This notification identifies that
the associated I2RS Agent has started. It includes an agent-boot-
count that indicates how many times the I2RS Agent has restarted
since the associated routing element restarted. The agent-boot-
count allows an I2RS Client to determine if the I2RS Agent has
restarted.
NOTIFICATION_I2RS_AGENT_TERMINATING: This notification reports that
the associated I2RS Agent is shutting down gracefully. Ephemeral
state will be removed. It can optionally include a timestamp
indicating when the I2RS Agent will shutdown. Use of this
timestamp assumes that time synchronization has been done and the
timestamp should not have granularity finer than one second
because better accuracy of shutdown time is not guaranteed.
There are two different failure types that are possible and each has There are two different failure types that are possible and each has
different behavior. different behavior.
Unexpected failure: In this case, the I2RS Agent has unexpectedly Unexpected failure: In this case, the I2RS Agent has unexpectedly
crashed and thus cannot notify its clients of anything. If an crashed and thus cannot notify its clients of anything. Since
I2RS Agent can crash separately from its associated routing I2RS does not require a persistent connection between the I2RS
element, then that I2RS Agent must cache each known I2RS Client. Client and I2RS Agent, it is necessary to have a mechanism for the
When an I2RS Agent starts, it notifies each saved I2RS Client that I2RS Agent to notify I2RS Clients that had subscriptions or
the I2RS Agent is up and includes an agent-boot-count that written ephemeral state; such I2RS Clients should be cached by the
indicates how many times the I2RS Agent has restarted since the I2RS Agent's system in persistent storage. When the I2RS Agent
associated routing element restarted. The agent-boot-count allows starts, it should send a NOTIFICATION_I2RS_AGENT_STARTING to each
an I2RS Client to determine if the I2RS Agent has restarted; if cached I2RS Client.
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.
Graceful failure: In this case, the I2RS Agent can do specific Graceful failure: In this case, the I2RS Agent can do specific
limited work as part of the process of being disabled. First, the limited work as part of the process of being disabled. The I2RS
I2RS Agent can optionally notify all its clients that their state Agent Agent must send a NOTIFICATION_I2RS_AGENT_TERMINATING to all
is being torn down; if no such notification is sent, then that its cached I2RS Clients.
ephemeral state is not torn down. Second, the I2RS Agent must
notify all its cached clients that the agent is going down.
6.2.2. Starting and Ending 6.2.2. Starting and Ending
When an I2RS client applies changes via the I2RS protocol, those When an I2RS client applies changes via the I2RS protocol, those
changes are applied and left until removed or the routing element changes are applied and left until removed or the routing element
reboots. The network application may make decisions about what to reboots. The network application may make decisions about what to
request via I2RS based upon a variety of conditions that imply request via I2RS based upon a variety of conditions that imply
different start times and stop times. That complexity is managed by different start times and stop times. That complexity is managed by
the network application and is not handled by I2RS. the network application and is not handled by I2RS.
skipping to change at page 17, line 24 skipping to change at page 18, line 15
may permit a priority to be configured on the device for the Local may permit a priority to be configured on the device for the Local
Config mechanism. The policy mechanism in the later case is Config mechanism. The policy mechanism in the later case is
comparing the I2RS client's priority with that priority assigned to comparing the I2RS client's priority with that priority assigned to
the Local Config. the Local Config.
When the Local Config always wins, some communication between that When the Local Config always wins, some communication between that
subsystem and the I2RS Agent is still necessary. That communication subsystem and the I2RS Agent is still necessary. That communication
contains the details of each specific device configuration change contains the details of each specific device configuration change
that the I2RS Agent is permitted to modify. In addition, when the that the I2RS Agent is permitted to modify. In addition, when the
system determines, that a client's I2RS state is preempted, the I2RS system determines, that a client's I2RS state is preempted, the I2RS
agent must notify the affected I2RS agents; how the system determines agent must notify the affected I2RS clients; how the system
this is implementation-dependent. determines this is implementation-dependent.
It is critical that policy based upon the source is used because the It is critical that policy based upon the source is used because the
resolution cannot be time-based. Simply allowing the most recent resolution cannot be time-based. Simply allowing the most recent
state to prevail could cause race conditions where the final state is state to prevail could cause race conditions where the final state is
not repeatably deterministic. not repeatably deterministic.
6.4. Routing Components and Associated I2RS Services 6.4. Routing Components and Associated I2RS Services
For simplicity, each logical protocol or set of functionality that For simplicity, each logical protocol or set of functionality that
can be compactly described in a separable information and data model can be compactly described in a separable information and data model
skipping to change at page 19, line 44 skipping to change at page 20, line 44
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 MUST NOT allowed in direct modification of the link-state database MUST NOT be allowed in
order to preserve network state consistency. order to preserve network state consistency.
6.4.3. MPLS 6.4.3. MPLS
I2RS Services will be needed to expose 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). This should include all local information about LSPs L2VPNs, etc). This should include all local information about LSPs
originating in, transiting, or terminating in this Routing Element. originating in, transiting, or terminating in this Routing Element.
skipping to change at page 20, line 36 skipping to change at page 21, line 36
the Routing Elements to be manipulated. These models drive the data the Routing Elements to be manipulated. These models drive the data
models and protocol operations for I2RS. It is important that these models and protocol operations for I2RS. It is important that these
informational models deal well with a wide variety of actual informational models deal well with a wide variety of actual
implementations of Routing Elements, as seen between different implementations of Routing Elements, as seen between different
products and different vendors. There are three ways that I2RS products and different vendors. There are three ways that I2RS
information models can address these variations: class or type information models can address these variations: class or type
inheritance, optional features, and templating. inheritance, optional features, and templating.
6.4.5.1. Managing Variation: Object Classes/Types and Inheritance 6.4.5.1. Managing Variation: Object Classes/Types and Inheritance
Information modeled by I2RS from a Routing Element can be described Information modelled by I2RS from a Routing Element can be described
in terms of classes or types or object. Different valid inheritance in terms of classes or types or object. Different valid inheritance
definitions can apply. What is appropriate for I2RS to use is not definitions can apply. What is appropriate for I2RS to use is not
determined in this architecture; for simplicity, class and subclass determined in this architecture; for simplicity, class and subclass
will be used as the example terminology. This I2RS architecture does will be used as the example terminology. This I2RS architecture does
require the ability to address variation in Routing Elements by require the ability to address variation in Routing Elements by
allowing information models to define parent or base classes and allowing information models to define parent or base classes and
subclasses. subclasses.
The base or parent class defines the common aspects that all Routing The base or parent class defines the common aspects that all Routing
Elements are expected to support. Individual subclasses can Elements are expected to support. Individual subclasses can
skipping to change at page 21, line 13 skipping to change at page 22, line 13
basic capabilities can operate purely in terms of base or parent basic capabilities can operate purely in terms of base or parent
classes, while a client needing more details or features can work classes, while a client needing more details or features can work
with the supported sub-class(es). with the supported sub-class(es).
As part of I2RS information modeling, clear rules should be specified As part of I2RS information modeling, clear rules should be specified
for how the parent class and subclass can relate; for example, what for how the parent class and subclass can relate; for example, what
changes a subclass can make to its parent? The description of such changes a subclass can make to its parent? The description of such
rules should be done so that it can apply across data modeling tools rules should be done so that it can apply across data modeling tools
until the I2RS data modeling language is selected. until the I2RS data modeling language is selected.
6.4.5.1.1. Managing Variation: Optionality 6.4.5.2. Managing Variation: Optionality
I2RS Information Models must be clear about what aspects are I2RS Information Models must be clear about what aspects are
optional. For instance, must an instance of a class always contain a 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 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? X when creating the object or is there a well-defined default value?
From the Routing Element perspective, in the above example, is From the Routing Element perspective, in the above example, each
support of X required so that values for X can be accepted and Information model should provide information that:
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 o Is X required for the data field to be accepted and applied?
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 o If X is optional, then how does "X" as an optional portion of data
field interact with the required aspects of the data field?
o Does the data field have defaults for the mandatory portion of the
field and the optional portions of the field
o Is X required to be within a particular set of values (E.g. range,
length of strings)?
The information model needs to be clear about what read or write
values are set by client and what responses or actions are required
by the agent. It is important to indicate what is required or
optional in client values and agent responses/actions.
6.4.5.3. Managing Variation: Templating
A template is a collection of information to address a problem; it A template is a collection of information to address a problem; it
cuts across the notions of class and object instances. A template cuts across the notions of class and object instances. A template
provides a set of defined values for a set of information fields and 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 can specify a set of values that must be provided to complete the
template. Further, a flexible template scheme may that some of the template. Further, a flexible template scheme may that some of the
defined values can be over-written. defined values can be over-written.
For instance, assigning traffic to a particular service class might For instance, assigning traffic to a particular service class might
be done by specifying a template Queueing with a parameter to be done by specifying a template Queueing with a parameter to
skipping to change at page 22, line 11 skipping to change at page 23, line 17
client can easily interact with the Routing Element without concern client can easily interact with the Routing Element without concern
for the variations which are handled by values included in the for the variations which are handled by values included in the
template. template.
If implementation variation can be exposed in other ways, templates If implementation variation can be exposed in other ways, templates
may not be needed. However, templates themselves could be objects may not be needed. However, templates themselves could be objects
referenced in the protocol messages, with Routing Elements being referenced in the protocol messages, with Routing Elements being
configured with the proper templates to complete the operation. This configured with the proper templates to complete the operation. This
is a topic for further discussion. is a topic for further discussion.
6.4.5.1.3. Object Relationships 6.4.5.4. Object Relationships
Objects (in a Routing Element or otherwise) do not exist in Objects (in a Routing Element or otherwise) do not exist in
isolation. They are related to each other. One of the important isolation. They are related to each other. One of the important
things a class definition does is represent the relationships between things a class definition does is represent the relationships between
instances of different classes. These relationships can be very instances of different classes. These relationships can be very
simple, or quite complicated. The following lists the information simple, or quite complicated. The following lists the information
relationships that the information models need to support. relationships that the information models need to support.
[[Editors' note: All of these are for discussion, and it is expected [[Editors' note: All of these are for discussion, and it is expected
that the list may be changed during WG discussion.]] that the list may be changed during WG discussion.]]
6.4.5.1.3.1. Initialization 6.4.5.4.1. Initialization
The simplest relationship is that one object instances is initialized The simplest relationship is that one object instance is initialized
by copying another. For example, one may have an object instance by copying another. For example, one may have an object instance
that represents the default setup for a tunnel, and all new tunnels 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 have fields copied from there if they are not set as part of
establishment. This is closely related to the templates discussed establishment. This is closely related to the templates discussed
above, but not identical. Since the relationship is only momentary above, but not identical. Since the relationship is only momentary
it is often not formally represented in modeling, but only captured it is often not formally represented in modeling, but only captured
in the semantic description of the default object. in the semantic description of the default object.
6.4.5.1.3.2. Correlation Identification 6.4.5.4.2. Correlation Identification
Often, it suffices to indicate in one object that it is related to a 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 second object, without having a strong binding between the two. So
an Identifier is used to represent the relationship. This can be 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 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 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 policy by that name exists, it is to be applied under some
circumstance. In modeling this is often represented by the type of circumstance. In modeling this is often represented by the type of
the value. the value.
6.4.5.1.3.3. Object References 6.4.5.4.3. Object References
Sometimes the relationship between objects is stronger. A valid ARP Sometimes the relationship between objects is stronger. A valid ARP
entry has to point to the active interface over which it was derived. entry has to point to the active interface over which it was derived.
This is the classic meaning of an object reference in programming. This is the classic meaning of an object reference in programming.
It can be used for relationships like containment or dependence. It can be used for relationships like containment or dependence.
This is usually represented by an explicit modeling link. This is usually represented by an explicit modeling link.
6.4.5.1.3.4. Active Reference 6.4.5.4.4. Active Reference
There is an even stronger form of coupling between objects if changes 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 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 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 need to immediately propagate to the Tunnel MTU, then the tunnel is
actively coupled to the link interface. This kind of active state actively coupled to the link interface. This kind of active state
coupling implies some sort of internal bookkeeping to ensure coupling implies some sort of internal bookkeeping to ensure
consistency, often conceptualized as a subscription model across consistency, often conceptualized as a subscription model across
objects. objects.
skipping to change at page 28, line 30 skipping to change at page 29, line 35
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, Ron Bonica, Joe Crabbe, Ken Gray, Carlos Pignataro, Wes George, Ron Bonica, Joe
Clarke, Juergen Schoenwalder, Jamal Hadi Salim, Scott Brim, and Clarke, Juergen Schoenwalder, Jamal Hadi Salim, Scott Brim, and
Thomas Narten for their suggestions and review. Thomas Narten for their suggestions and review.
11. Informative References 11. Informative References
[I-D.ietf-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-ietf-i2rs- Routing System Problem Statement", draft-ietf-i2rs-
problem-statement-00 (work in progress), August 2013. problem-statement-01 (work in progress), May 2014.
[I-D.ietf-idr-ls-distribution] [I-D.ietf-idr-ls-distribution]
Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
Ray, "North-Bound Distribution of Link-State and TE Ray, "North-Bound Distribution of Link-State and TE
Information using BGP", draft-ietf-idr-ls-distribution-04 Information using BGP", draft-ietf-idr-ls-distribution-04
(work in progress), November 2013. (work in progress), November 2013.
[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, March Protocol (NETCONF) Access Control Model", RFC 6536, March
2012. 2012.
 End of changes. 40 change blocks. 
127 lines changed or deleted 163 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/