draft-ietf-i2rs-architecture-03.txt   draft-ietf-i2rs-architecture-04.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: November 16, 2014 Ericsson Expires: December 25, 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
May 15, 2014 June 23, 2014
An Architecture for the Interface to the Routing System An Architecture for the Interface to the Routing System
draft-ietf-i2rs-architecture-03 draft-ietf-i2rs-architecture-04
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 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
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 November 16, 2014. This Internet-Draft will expire on December 25, 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
skipping to change at page 3, line 7 skipping to change at page 3, line 7
6.4.5.4. Object Relationships . . . . . . . . . . . . . . 23 6.4.5.4. Object Relationships . . . . . . . . . . . . . . 23
6.4.5.4.1. Initialization . . . . . . . . . . . . . . . 23 6.4.5.4.1. Initialization . . . . . . . . . . . . . . . 23
6.4.5.4.2. Correlation Identification . . . . . . . . . 23 6.4.5.4.2. Correlation Identification . . . . . . . . . 23
6.4.5.4.3. Object References . . . . . . . . . . . . . . 24 6.4.5.4.3. Object References . . . . . . . . . . . . . . 24
6.4.5.4.4. Active Reference . . . . . . . . . . . . . . 24 6.4.5.4.4. Active Reference . . . . . . . . . . . . . . 24
7. I2RS Client Agent Interface . . . . . . . . . . . . . . . . . 24 7. I2RS Client Agent Interface . . . . . . . . . . . . . . . . . 24
7.1. One Control and Data Exchange Protocol . . . . . . . . . 24 7.1. One Control and Data Exchange Protocol . . . . . . . . . 24
7.2. Communication Channels . . . . . . . . . . . . . . . . . 24 7.2. Communication Channels . . . . . . . . . . . . . . . . . 24
7.3. Capability Negotiation . . . . . . . . . . . . . . . . . 25 7.3. Capability Negotiation . . . . . . . . . . . . . . . . . 25
7.4. Identity and Security Role . . . . . . . . . . . . . . . 25 7.4. Identity and Security Role . . . . . . . . . . . . . . . 25
7.4.1. Client Redundancy . . . . . . . . . . . . . . . . . . 25 7.4.1. Client Redundancy . . . . . . . . . . . . . . . . . . 26
7.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 26 7.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 26
7.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 26 7.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 27
7.7. Information collection . . . . . . . . . . . . . . . . . 27 7.7. Information collection . . . . . . . . . . . . . . . . . 27
7.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 27 7.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 28
7.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 28 7.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 28
8. Manageability Considerations . . . . . . . . . . . . . . . . 28 8. Operational and Manageability Considerations . . . . . . . . 29
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
11. Informative References . . . . . . . . . . . . . . . . . . . 29 11. Informative References . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
Routers that form the Internet's routing infrastructure maintain Routers that form the internet routing infrastructure maintain state
state at various layers of detail and function. For example, a at various layers of detail and function. For example, a typical
typical router maintains a Routing Information Base (RIB), and router maintains a Routing Information Base (RIB), and implements
implements routing protocols such as OSPF, ISIS, and BGP to exchange routing protocols such as OSPF, ISIS, and BGP to exchange protocol
protocol state and other information about the state of the network state and other information about the state of the network with other
with other routers. routers.
Routers know how to convert all of this information into the Routers convert all of this information into forwarding entries which
forwarding operations that are installed in the forwarding plane. are then used to forward packets and flows between network elements.
The forwarding plane and the specified forwarding operations then The forwarding plane and the specified forwarding entries then
contain active state information that describes the expected and contain active state information that describes the expected and
observed operational behavior of the router and which is also needed observed operational behavior of the router and which is also needed
by the network applications. Network-oriented applications require by the network applications. Network-oriented applications require
easy access to this information to learn the network topology, to easy access to this information to learn the network topology, to
verify that programmed state is installed in the forwarding plane, to verify that programmed state is installed in the forwarding plane, to
measure the behavior of various flows, routes or forwarding entries, measure the behavior of various flows, routes or forwarding entries,
as well as to understand the configured and active states of the as well as to understand the configured and active states of the
router. 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 observation of the routing-related (I2RS) facilitates control and observation of the routing-related
state (for example, a Routing Element RIB manager's state), as well state (for example, a Routing Element RIB manager's state), as well
as enabling network-oriented applications to be built on top of 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 routing
routing system. This I2RS architecture recognizes that the routing system. This I2RS architecture recognizes that the routing system
system and a router's OS provide useful mechanisms that applications and a router's OS provide useful mechanisms that applications could
could harness to accomplish application-level goals. 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, and aspects of the information and data models for a variety of data, and aspects of the
I2RS solution may be useful in domain other than routing, I2RS and I2RS solution may be useful in domain other than routing, I2RS and
this document are specifically focused on an interface for routing this document are specifically focused on an interface for routing
data. 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 for atomic operations. Second is the
information and state that is frequently not directly configurable or access to structured information and state that is frequently not
modeled in existing implementations or configuration protocols. directly configurable or modeled in existing implementations or
Third is the ability to subscribe to structured, filterable event configuration protocols. Third is the ability to subscribe to
notifications from the router. Fourth, the operation of I2RS is to structured, filterable event notifications from the router. Fourth,
be data-model driven to facilitate extensibility and provide standard the operation of I2RS is to be data-model driven to facilitate
data-models to be used by network applications. extensibility and provide standard 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.ietf-i2rs-problem-statement]. [I-D.ietf-i2rs-problem-statement].
The I2RS facilitates obtaining information from the router. The I2RS The I2RS architecture facilitates obtaining information from the
provides the ability to not only read specific information, but also router. The I2RS architecture provides the ability to not only read
to subscribe to targeted information streams and filtered and specific information, but also to subscribe to targeted information
thresholded events. streams and filtered and thresholded events.
Such an interface also facilitates the injection of ephemeral state Such an interface also facilitates the injection of ephemeral state
into the routing system. A non-routing protocol or application could into the routing system. A non-routing protocol or application could
inject state into a routing element via the state-insertion inject state into a routing element via the state-insertion
functionality of the I2RS and that state could then be distributed in functionality of the I2RS and that state could then be distributed in
a routing or signaling protocol and/or be used locally (e.g. to a routing or signaling protocol and/or be used locally (e.g. to
program the co-located forwarding plane). I2RS will only permit program the co-located forwarding plane). I2RS will only permit
modification of state that would be safe, conceptually, to modify via modification of state that would be safe, conceptually, to modify via
local configuration; no direct manipulation of protocol-internal local configuration; no direct manipulation of protocol-internal
dynamically determined data is envisioned. dynamically determined data is envisioned.
skipping to change at page 5, line 17 skipping to change at page 5, line 17
Figure 1 shows the basic architecture for I2RS between applications Figure 1 shows the basic architecture for I2RS between applications
using I2RS, their associated I2RS Clients, and I2RS Agents. using I2RS, their associated I2RS Clients, and I2RS Agents.
Applications access I2RS services through I2RS clients. A single Applications access I2RS services through I2RS clients. A single
client can provide access to one or more applications. In the client can provide access to one or more applications. In the
figure, Clients A and B provide access to a single application, while figure, Clients A and B provide access to a single application, while
Client P provides access to multiple applications. Client P provides access to multiple applications.
Applications can access I2RS services through local or remote Applications can access I2RS services through local or remote
clients. In the figure, Applicatons A and B access I2RS services clients. In the figure, Applicatons A and B access I2RS services
through local clients, while Applications C, D and E access I2RS through local clients, while Applications C, D and E access I2RS
services through a remote client. services through a remote client. The details of how applications
communicate with a remote client is out of scope for I2RS.
An I2RS Client can access one or more I2RS agents. In the figure, 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 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 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 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
skipping to change at page 7, line 10 skipping to change at page 7, line 10
* Routing Element 1 * * Routing Element 2 * * 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 some subset of the Routing Element: A Routing Element implements some subset of the
routing system. It does not need to have a forwarding plane routing system. It does not need to have a forwarding plane
associated with it. Examples of Routing Elements can include: associated with it. Examples of Routing Elements can 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 BGP speaker acting 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, flow data,
events. This is the subset of operational state that is needed by and local events. This is the subset of operational state that is
network applications based on I2RS that is not contained in the needed by network applications based on I2RS that is not contained
routing and signaling information. How this information is in the routing and signaling information. How this information is
provided to the I2RS agent is out of scope, but the standardized provided to the I2RS agent is out of scope, but the standardized
information and data models for what is exposed are part of I2RS. information and data models for what is exposed are part of I2RS.
Static System State: An I2RS agent needs access to static state on Static System State: An I2RS agent needs access to static state on
a routing element beyond what is contained in the routing a routing element beyond what is contained in the routing
subsystem. An example of such state is specifying queueing subsystem. An example of such state is specifying queueing
behavior for an interface or traffic. How the I2RS agent modifies behavior for an interface or traffic. How the I2RS agent modifies
or obtains this information is out of scope, but the standardized or obtains this information is out of scope, but the standardized
information and data models for what is exposed are part of I2RS. information and data models for what is exposed are part of I2RS.
skipping to change at page 8, line 44 skipping to change at page 8, line 44
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
SNMP/NETCONF as described in Section 6.3. CLI/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 basic 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
skipping to change at page 9, line 23 skipping to change at page 9, line 23
contacted by I2RS clients. contacted by I2RS clients.
client or I2RS Client: A client implements the I2RS protocol, uses client or I2RS Client: A client implements the I2RS protocol, uses
it to 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. It interacts with other elements of the accomplish a task. It interacts with other elements of the
policy, provisioning, and configuration system by means outside of policy, provisioning, and configuration system by means outside of
the scope of the I2RS effort. It interacts with the I2RS agents the scope of the I2RS effort. It interacts with the I2RS agents
to collect information from the routing and forwarding system. to collect information from the routing and forwarding system.
Based on the information and the policy oriented interactions, the Based on the information and the policy oriented interactions, the
I2RS client may also interact with I2RS agents to modify the state I2RS client may also interact with I2RS agents to modify the state
of the routing system the client interacts with to achieve of their associated routing systems to achieve operational goals.
operational goals. An I2RS client can be seen as the part of an An I2RS client can be seen as the part of an application that uses
application that uses and supports I2RS and could be a software 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. The read scope specifies the access authorized to read. The read scope specifies the access
skipping to change at page 11, line 5 skipping to change at page 10, line 49
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.
Having noted that, it is also critical to the utility of I2RS that it While the types of operations contemplated here are complex in their
be easily deployable and robust. Complexity in the protocol hinders nature, it is critical that I2RS be easily deployable and robust.
implementation, robustness, and deployability. Also, data models Adding complexity beyond what is needed to satisfy well known and
complexity may complicate extensibility. understood requirements would hinder the ease of implementation, the
robustness of the protocol, and the deployability of the protocol.
Overly complex data models tend to ossify information sets by
attempting to describe and close off every possible option,
complicating extensibility.
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
Naturally, extensibility of the protocol and data model is very Naturally, extensibility of the protocol and data model is very
important. In particular, given the necessary scope limitations of important. In particular, given the necessary scope limitations of
skipping to change at page 13, line 5 skipping to change at page 13, line 5
particular requests. particular requests.
Different levels of integrity, confidentiality, and replay protection Different levels of integrity, confidentiality, and replay protection
are relevant for different aspects of I2RS. The primary are relevant for different aspects of I2RS. The primary
communication channel that is used for client authentication and then communication channel that is used for client authentication and then
used by the client to write data requires integrity, privacy and used by the client to write data requires integrity, privacy and
replay protection. Appropriate selection of a default required replay protection. Appropriate selection of a default required
transport protocol is the preferred way of meeting these transport protocol is the preferred way of meeting these
requirements. requirements.
Other communications via I2RS will not require integrity, Other communications via I2RS may 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 (as described in based upon information provided by an I2RS Client (as described in
Section 7.2). For example, a I2RS client may request notifications Section 7.2). For example, a I2RS client may request notifications
skipping to change at page 16, line 34 skipping to change at page 16, line 34
It is expected that an I2RS Agent may fail independently of the It is expected that an I2RS Agent may fail independently of the
associated routing element. This could happen because I2RS is associated routing element. This could happen because I2RS is
disabled on the routing element or because the I2RS Agent, a separate disabled on the routing element or because the I2RS Agent, a separate
process or even running on a separate processor, experiences an process or even running on a separate processor, experiences an
unexpected failure. Just as routing state learned from a failed unexpected failure. Just as routing state learned from a failed
source is removed, the ephemeral I2RS state will usually be removed source is removed, the ephemeral I2RS state will usually be removed
shortly after the failure is detected or as part of a graceful shortly after the failure is detected or as part of a graceful
shutdown process. To handle I2RS Agent failure, the I2RS Agent must shutdown process. To handle I2RS Agent failure, the I2RS Agent must
use two different notifications. use two different notifications.
NOTIFICIATON_I2RS_AGENT_STARTING: This notification identifies that NOTIFICATION_I2RS_AGENT_STARTING: This notification identifies that
the associated I2RS Agent has started. It includes an agent-boot- the associated I2RS Agent has started. It includes an agent-boot-
count that indicates how many times the I2RS Agent has restarted count that indicates how many times the I2RS Agent has restarted
since the associated routing element restarted. The agent-boot- since the associated routing element restarted. The agent-boot-
count allows an I2RS Client to determine if the I2RS Agent has count allows an I2RS Client to determine if the I2RS Agent has
restarted. restarted.
NOTIFICATION_I2RS_AGENT_TERMINATING: This notification reports that NOTIFICATION_I2RS_AGENT_TERMINATING: This notification reports that
the associated I2RS Agent is shutting down gracefully. Ephemeral the associated I2RS Agent is shutting down gracefully. Ephemeral
state will be removed. It can optionally include a timestamp state will be removed. It can optionally include a timestamp
indicating when the I2RS Agent will shutdown. Use of this indicating when the I2RS Agent will shutdown. Use of this
skipping to change at page 19, line 43 skipping to change at page 19, line 43
* +-------------------+ +---------------+ * * +-------------------+ +---------------+ *
************************************************************** **************************************************************
Figure 2: Anticipated I2RS Services Figure 2: Anticipated I2RS Services
There are relationships between different I2RS Services - whether There are relationships between different I2RS Services - whether
those be the need for the RIB to refer to specific interfaces, the 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 desire to refer to common complex types (e.g. links, nodes, IP
addresses), or the ability to refer to implementation-specific addresses), or the ability to refer to implementation-specific
functionality (e.g. pre-defined templates to be applied to interfaces functionality (e.g. pre-defined templates to be applied to interfaces
or for QoS behaviors that traffic is direct into). or for QoS behaviors that traffic is direct into). Section 6.4.5
Section Section 6.4.5 discussing information modeling constructs and discusses information modeling constructs and the range of
the range of relationship types that are applicable. relationship types that are applicable.
6.4.1. Routing and Label Information Bases 6.4.1. Routing and Label Information Bases
Routing elements may maintain one or more Information Bases. Routing elements may maintain one or more Information Bases.
Examples include Routing Information Bases such as IPv4/IPv6 Unicast Examples include Routing Information Bases such as IPv4/IPv6 Unicast
or IPv4/IPv6 Multicast. Another such example includes the MPLS Label or IPv4/IPv6 Multicast. Another such example includes the MPLS Label
Information Bases, per-platform- or per-interface." This Information Bases, per-platform- or per-interface." This
functionality, exposed via an I2RS Service, must interact smoothly functionality, exposed via an I2RS Service, must interact smoothly
with the same mechanisms that the routing element already uses to with the same mechanisms that the routing element already uses to
handle RIB input from multiple sources, so as to safely change the handle RIB input from multiple sources, so as to safely change the
skipping to change at page 20, line 50 skipping to change at page 20, line 50
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 the link-state database MUST NOT be 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.
LDP) that provide MPLS-based services (e.g. pseudowires, L3VPNs, BGP, 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.
6.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
skipping to change at page 22, line 9 skipping to change at page 22, line 9
represent variations and additional capabilities. When applicable, represent variations and additional capabilities. When applicable,
there may be several levels of refinement. The I2RS protocol can there may be several levels of refinement. The I2RS protocol can
then provide mechanisms to allow an I2RS client to determine which then provide mechanisms to allow an I2RS client to determine which
classes a given I2RS Agent has available. Clients which only want classes a given I2RS Agent has available. Clients which only want
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 can a subclass 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.2. 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, each From the Routing Element perspective, in the above example, each
skipping to change at page 24, line 28 skipping to change at page 24, line 28
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.
7. I2RS Client Agent Interface 7. I2RS Client Agent Interface
7.1. One Control and Data Exchange Protocol 7.1. One Control and Data Exchange Protocol
This I2RS Architecture presumes that there is one I2RS protocol for As agreed by the I2RS working group, this I2RS architecture assumes
control and data exchange. This helps meet the goal of simplicity that there is a single I2RS protocol for control and data exchange;
and thereby enhances deployability. Whether such a protocol is built that protocol will be based on NETCONF[RFC6241] and RESTCONF
upon extending existing mechanisms or requires a new mechanism is [I-D.ietf-netconf-restconf]. This helps meet the goal of simplicity
under active investigation. That protocol may use several underlying and thereby enhances deployability. That protocol may need to use
transports (TCP, SCTP, DCCP), with suitable authentication and several underlying transports (TCP, SCTP, DCCP), with suitable
integrity protection mechanisms. These different transports can authentication and integrity protection mechanisms. These different
support different types of communication (e.g. control, reading, transports can support different types of communication (e.g.
notifications, and information collection) and different sets of control, reading, notifications, and information collection) and
data. Whatever transport is used for the data exchange, it must also different sets of data. Whatever transport is used for the data
support suitable congestion control mechanisms. exchange, it must also support suitable congestion control
mechanisms. The transports chosen should be operator and implementor
friendly to ease adoption.
7.2. Communication Channels 7.2. Communication Channels
Multiple communication channels and multiple types of communication Multiple communication channels and multiple types of communication
channels are required. There may be a range of requirements (e.g. channels are required. There may be a range of requirements (e.g.
confidentiality, reliability), and to support the scaling there may confidentiality, reliability), and to support the scaling there may
need to be channels originating from multiple sub-components of a need to be channels originating from multiple sub-components of a
routing element and/or to multiple parts of an I2RS client. All such routing element and/or to multiple parts of an I2RS client. All such
communication channels will use the same higher level protocol. Use communication channels will use the same higher level protocol. Use
of additional channels for communication will be coordinated between of additional channels for communication will be coordinated between
the I2RS client and the I2RS agent. the I2RS client and the I2RS agent.
I2RS protocol communication can be delivered in-band via the routing
system's data plane. I2RS protocol communication might be delivered
out-of-band via a management interface. Depending on what operations
are requested, it is possible for the I2RS protocol communication to
cause the in-band communication channels to stop working; this could
cause the I2RS agent to become unreachable across that communication
channel.
7.3. Capability Negotiation 7.3. Capability Negotiation
The support for different protocol capabilities and I2RS Services The support for different protocol capabilities and I2RS Services
will vary across I2RS Clients and Routing Elements supporting I2RS will vary across I2RS Clients and Routing Elements supporting I2RS
Agents. Since each I2RS Service is required to include a capability Agents. Since each I2RS Service is required to include a capability
model (see Section 6.4), negotiation at the protocol level can be model (see Section 6.4), negotiation at the protocol level can be
restricted to protocol specifics and which I2RS Services are restricted to protocol specifics and which I2RS Services are
supported. supported.
Capability negotiation (such as which transports are supported beyond Capability negotiation (such as which transports are supported beyond
skipping to change at page 27, line 48 skipping to change at page 28, line 20
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 should be when such a determine what the right state of data should be when such a
collision happens. Rather, the architecture mandates that there be collision happens. Rather, the architecture mandates that there be
decidable means by which I2RS Agents handle the collisions. The decidable means by which I2RS Agents handle the collisions. The
mechanism for this is to have a simple priority associated with each mechanism for ensuring predictability is to have a simple priority
I2RS clients, and the highest priority change remains in effect. In associated with each I2RS clients, and the highest priority change
the case of priority ties, the first client whose attribution is remains in effect. In the case of priority ties, the first client
associated with the data will keep control. whose attribution is associated with the data will keep control.
In order for this approach to multi-headed control to be useful for In order for this approach to multi-headed control to be useful for
I2RS Clients, it is important that it be possible for an I2RS Client I2RS Clients, it is important that it be possible for an I2RS Client
to register for changes to any changes made by I2RS to data that it 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 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 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 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 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.
skipping to change at page 28, line 47 skipping to change at page 29, line 18
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 or write protocol will include an explicit reply to modification or write
operations even when they fully succeed. operations even when they fully succeed.
8. Manageability Considerations 8. Operational and Manageability Considerations
In order to facilitate troubleshooting of routing elements
implementing I2RS agents, those routing elements should provide for a
mechanism to show actively provisioned I2RS state and other I2RS
Agent internal information. Note that this information may contain
highly sensitive material subject to the Security Considerations of
any data models implemented by that Agent and thus must be protected
according to those considerations. Preferably, this mechanism should
use a different privileged means other than simply connecting as an
I2RS client to learn the data. Using a different mechanism should
improve traceability and failure management.
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
skipping to change at page 29, line 27 skipping to change at page 30, line 12
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, 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, Jeff Haas, Jamal Hadi Salim, Scott
Thomas Narten for their suggestions and review. Brim, Thomas Narten, Dean Bogdanovi, Tom Petch, Robert Raszuk, and
Sriganesh Kini 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-01 (work in progress), May 2014. problem-statement-03 (work in progress), June 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-05
(work in progress), November 2013. (work in progress), May 2014.
[I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando,
"RESTCONF Protocol", draft-ietf-netconf-restconf-00 (work
in progress), March 2014.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011.
[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.
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
Joel Halpern Joel Halpern
Ericsson Ericsson
Email: Joel.Halpern@ericsson.com Email: Joel.Halpern@ericsson.com
Susan Hares Susan Hares
Hickory Hill Consulting Hickory Hill Consulting
Email: shares@ndzh.com Email: shares@ndzh.com
 End of changes. 39 change blocks. 
87 lines changed or deleted 123 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/