draft-atlas-i2rs-architecture-00.txt   draft-atlas-i2rs-architecture-01.txt 
Network Working Group A. Atlas Network Working Group A. Atlas
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Informational J. Halpern Intended status: Informational J. Halpern
Expires: December 30, 2013 Ericsson Expires: January 16, 2014 Ericsson
S. Hares S. Hares
ADARA ADARA
D. Ward D. Ward
Cisco Systems Cisco Systems
June 28, 2013 T. Nadeau
Juniper Networks
July 15, 2013
An Architecture for the Interface to the Routing System An Architecture for the Interface to the Routing System
draft-atlas-i2rs-architecture-00 draft-atlas-i2rs-architecture-01
Abstract Abstract
This document describes an architecture for a standard, programmatic This document describes an architecture for a standard, programmatic
interface for state transfer in and out of the Internet's routing interface for state transfer in and out of the Internet's routing
system. It describes the basic architecture, the components, and system. It describes the basic architecture, the components, and
their interfaces with particular focus on those to be standardized as their interfaces with particular focus on those to be standardized as
part of I2RS. part of I2RS.
Status of This Memo Status of This Memo
skipping to change at page 1, line 39 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 December 30, 2013. This Internet-Draft will expire on January 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 2, line 19 skipping to change at page 2, line 21
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Functional Overview . . . . . . . . . . . . . . . . . . . 3 1.1. Functional Overview . . . . . . . . . . . . . . . . . . . 3
1.2. Architectural Overview . . . . . . . . . . . . . . . . . 4 1.2. Architectural Overview . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Key Architectural Properties . . . . . . . . . . . . . . . . 9 3. Key Architectural Properties . . . . . . . . . . . . . . . . 9
3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Model-Driven Programmatic Interfaces . . . . . . . . . . 10 3.3. Model-Driven Programmatic Interfaces . . . . . . . . . . 9
3.4. Authorization and Authentication . . . . . . . . . . . . 10 3.4. Authorization and Authentication . . . . . . . . . . . . 10
4. Network Applications and I2RS Client . . . . . . . . . . . . 10 4. Network Applications and I2RS Client . . . . . . . . . . . . 10
4.1. Example Network Application: Topology Manager . . . . . . 11 4.1. Example Network Application: Topology Manager . . . . . . 11
5. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 11 5. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 11
5.1. Relationship to its Routing Element . . . . . . . . . . . 11 5.1. Relationship to its Routing Element . . . . . . . . . . . 11
5.2. State Storage . . . . . . . . . . . . . . . . . . . . . . 12 5.2. State Storage . . . . . . . . . . . . . . . . . . . . . . 12
5.2.1. Starting and Ending . . . . . . . . . . . . . . . . . 12 5.2.1. Starting and Ending . . . . . . . . . . . . . . . . . 12
5.2.2. Reversion . . . . . . . . . . . . . . . . . . . . . . 13 5.2.2. Reversion . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Interactions with Local Config . . . . . . . . . . . . . 13 5.3. Interactions with Local Config . . . . . . . . . . . . . 13
5.4. Routing Components and Associated I2RS Services . . . . . 13 5.4. Routing Components and Associated I2RS Services . . . . . 14
5.4.1. Unicast and Multicast RIB and LFIB . . . . . . . . . 14 5.4.1. Unicast and Multicast RIB and LFIB . . . . . . . . . 14
5.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 14 5.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 14
5.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 15 5.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 15
5.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 15 5.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 15
6. I2RS Client Agent Interface . . . . . . . . . . . . . . . . . 15 6. I2RS Client Agent Interface . . . . . . . . . . . . . . . . . 15
6.1. Protocol Structure . . . . . . . . . . . . . . . . . . . 15 6.1. Protocol Structure . . . . . . . . . . . . . . . . . . . 15
6.2. Channel . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.2. Channel . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 16 6.3. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 16
6.4. Identity and Security Role . . . . . . . . . . . . . . . 16 6.4. Identity and Security Role . . . . . . . . . . . . . . . 16
6.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 16 6.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 16
6.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 17 6.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 17
6.7. Information collection . . . . . . . . . . . . . . . . . 17 6.7. Information collection . . . . . . . . . . . . . . . . . 17
6.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 18 6.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 17
6.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 18 6.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 18
7. Manageability Considerations . . . . . . . . . . . . . . . . 19 7. Manageability Considerations . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
11. Informative References . . . . . . . . . . . . . . . . . . . 20 11. Informative References . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
Routers that form the Internet's routing infrastructure maintain Routers that form the Internet's routing infrastructure maintain
state at various layers of detail and function. For example, a state at various layers of detail and function. For example, a
typical router maintains a Routing Information Base (RIB), and typical router maintains a Routing Information Base (RIB), and
implements routing protocols such as OSPF, ISIS, BGP to exchange implements routing protocols such as OSPF, ISIS, 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 3, line 40 skipping to change at page 3, line 40
interface for transferring state into and out of the Internet's interface for transferring state into and out of the Internet's
routing system, and recognizes that the routing system and a router's routing system, and recognizes that the routing system and a router's
OS provide useful mechanisms that applications could harness to OS provide useful mechanisms that applications could harness to
accomplish application-level goals. 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. leveraging the existing routing system as much as desired.
The I2RS, and therefore this document, is specifically focused on an The I2RS, and therefore this document, are specifically focused on an
interface for routing and forwarding data. interface for routing and forwarding data.
1.1. Functional Overview 1.1. Functional Overview
There are four key aspects to the I2RS. First, the interface is a There are four key aspects to the I2RS. First, the interface is a
programmatic interface meaning that it is asynchronous and offers programmatic interface which needs to be asynchronous and offers
fast, interactive access. Second, the I2RS gives access to fast, interactive access. Second, the I2RS gives access to
information and state that is not usually configurable or modeled in information and state that is not usually configurable or modeled in
existing implementations or configuration protocols. Third, the I2RS existing implementations or configuration protocols. Third, the I2RS
gives applications the ability to learn additional, structured, gives applications the ability to learn additional, structured,
filterable information and events from the router. Fourth, the I2RS filterable information and events from the router. Fourth, the I2RS
will be data-model driven to facilitate extensibility and provide will be data-model driven to facilitate extensibility and provide
standard data-models to be used by network applications. 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.atlas-i2rs-problem-statement]. [I-D.atlas-i2rs-problem-statement].
Such an interface facilitates the specification of implicitly non- Such an interface facilitates the specification of implicitly non-
permanent state into the routing system, that can optionally be made permanent state into the routing system, that can optionally be made
permanent. In addition, the extraction of that information and permanent. In addition, the extraction of that information and
additional dynamic information from the routing system is a critical additional dynamic information from the routing system is a critical
component of the interface. A non-routing protocol or application component of the interface. A non-routing protocol or application
could inject state into a network element's OS via the state- could inject state into a routing element via the state-insertion
insertion aspects of the interface and that state could then be aspects of the I2RS and that state could then be distributed in a
distributed in a routing or signaling protocol. routing or signaling protocol and/or be used locally (e.g. to program
the co-located forwarding plane).
There are several types of information that the I2RS will facilitate There are several types of information that the I2RS will facilitate
an I2RS Client obtaining. These range from dynamic event an I2RS Client obtaining. These range from dynamic event
notifications (e.g. changes to a particular next-hop, interface up/ notifications (e.g. changes to a particular next-hop, interface up/
down, etc.)to information collection streams (statistics, topology, down, etc.)to information collection streams (statistics, topology,
route changes, etc) to simply read operations. The I2RS provides the route changes, etc) to simply read operations. The I2RS provides the
ability for an I2RS client to request filtered and thresholded ability for an I2RS client to request filtered and thresholded
information as well as events. information as well as events.
The existing mechanisms, such as SNMP and NetConf, that allow state The existing mechanisms, such as SNMP and NetConf, that allow state
to be written and read do not meet all of the key properties given in to be written and read do not meet all of the key properties given in
[I-D.atlas-i2rs-problem-statement] for I2RS. The overhead of [I-D.atlas-i2rs-problem-statement] for I2RS. The overhead of
infrastructure is also quite high and many MIBs do not, in definition infrastructure can be quite high and many MIBs do not, in definition
or practice, allow writing of state. There is also very limited or practice, allow writing of state. There is also very limited
capability to add new application-specific state to be distributed capability to add new application-specific state to be distributed
via the routing system. via the routing system.
ForCES is another data-model-driven method for writing state into a ForCES is another data-model-driven method for writing state into a
router, but its focus is on the forwarding plane. By focusing on the router, but its focus is on the forwarding plane. By focusing on the
forwarding plane, it requires that the forwarding plane be modeled forwarding plane, it requires that the forwarding plane be modeled
and programmable and ignores the existence and intelligence of the and programmable and ignores the existence and intelligence of the
router OS and routing system. ForCES provides a lower-level router OS and routing system. ForCES provides a lower-level
interface than I2RS is intended to address. interface than I2RS is intended to address.
skipping to change at page 7, line 6 skipping to change at page 7, line 6
I2RS Client: The I2RS client implements the I2RS protocol(s). It I2RS Client: The I2RS client implements the I2RS protocol(s). It
interacts with other elements of the policy, provisioning, and interacts with other elements of the policy, provisioning, and
configuration system by means outside of the scope of the I2RS configuration system by means outside of the scope of the I2RS
effort. It interacts with the I2RS clients to collect information effort. It interacts with the I2RS clients to collect information
from the routing and forwarding system. Based on the information from the routing and forwarding system. Based on the information
and the policy oriented interactions, the I2RS client may also and the policy oriented interactions, the I2RS client may also
interact with the I2RS agent to modify the state of the routing interact with the I2RS agent to modify the state of the routing
system the client interacts with to achieve operational goals. system the client interacts with to achieve operational goals.
As can be seen in Figure 1, an I2RS client can communicate with As can be seen in Figure 1, an I2RS client can communicate with
multiple I2RS agents. The application associated with an I2RS client multiple I2RS agents. An I2RS client may connect to one or more I2RS
may connect to one or more I2RS agents based upon its needs. agents based upon its needs. Similarly, an I2RS agent may
Similarly, an I2RS agent may communicate with multiple I2RS clients - communicate with multiple I2RS clients - whether to respond to their
whether to respond to their requests, to send notifications, etc. requests, to send notifications, etc. Timely notifications are
Timely notifications are critical so that several simultaneously critical so that several simultaneously operating applications have
operating applications have up-to-date information on the state of up-to-date information on the state of the network.
the network.
As can also be seen in Figure 1, an I2RS Agent may communicate with As can also be seen in Figure 1, an I2RS Agent may communicate with
multiple clients. Each client may send the agent a variety of write multiple clients. Each client may send the agent a variety of write
operations. The handling of this situation has been a source of operations. The handling of this situation has been a source of
discussion in the working group. In order to keep the protocol discussion in the working group. In order to keep the protocol
simple, the current view is that two clients should not be attempting simple, the current view is that two clients should not be attempting
to write (modify) the same piece of information. Such collisions may to write (modify) the same piece of information. Such collisions may
happen, but are considered error cases that should be resolved by the happen, but are considered error cases that should be resolved by the
network application layer. network applications and management systems.
Multiple I2RS clients may need to supply data into the same list Multiple I2RS clients may need to supply data into the same list
(e.g. a prefix or filter list); this is not considered an error and (e.g. a prefix or filter list); this is not considered an error and
must be correctly handled. must be correctly handled. The nuances so that writers do not
normally collide should be handled in the information models.
The architectural goal for the I2RS is that such errors should The architectural goal for the I2RS is that such errors should
produce predictable behaviors, and be reportable to interested produce predictable behaviors, and be reportable to interested
clients. The details of the associated policy is discussed in clients. The details of the associated policy is discussed in
Section 6.8. The same policy mechanism (simple priority per I2RS Section 6.8. The same policy mechanism (simple priority per I2RS
client) applies to interactions between the I2RS agent and the CLI/ client) applies to interactions between the I2RS agent and the CLI/
SNMP/NetConf as described in Section 5.3. SNMP/NetConf as described in Section 5.3.
In addition it can be noted that there may be indirect interactions In addition it must be noted that there may be indirect interactions
between write operations. Detection and avoidance of such between write operations. Detection and avoidance of such
interactions is outside the scope of the I2RS work and is left to interactions is outside the scope of the I2RS work and is left to
agent design and implementation for now. [[Editor's note: This topic agent design and implementation for now. [[Editor's note: This topic
needs more discussion in the working group.]] needs more discussion in the working group.]]
2. Terminology 2. Terminology
The following terminology is used in this document. The following terminology is used in this document.
agent or I2RS Agent: An I2RS agent provides the supported I2RS agent or I2RS Agent: An I2RS agent provides the supported I2RS
services to the local system's routing sub-systems. The I2RS services to the local system's routing sub-systems. The I2RS
agent understands the I2RS protocol and can be contacted by I2RS agent understands the I2RS protocol and can be contacted by I2RS
clients. clients.
client or I2RS Client: A client speaks the I2RS protocol to client or I2RS Client: A client speaks the I2RS protocol to
communicate with I2RS Agents and uses the I2RS services to communicate with I2RS Agents and uses the I2RS services to
accomplish a task as instructed by the client's local application. accomplish a task. An I2RS client can be seen as the part of an
An I2RS client can be seen as the part of an application that application that uses and supports I2RS and could be a software
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 its usage. The expectation is that a policies that control their usage. The expectation is that a
service will be represented by a data-model. For instance, 'RIB service will be represented by a data-model. For instance, 'RIB
service' could be an example of a service that gives access to service' could be an example of a service that gives access to
state held in a device's RIB. state held in a device's RIB.
read scope: The set of information which the I2RS client is read scope: The set of information which the I2RS client is
authorized to read. This access includes the permission to see authorized to read. This access includes the permission to see
the existence of data and the ability to retrieve the value of the existence of data and the ability to retrieve the value of
that data. that data.
write scope: The set of field values which the I2RS client is write scope: The set of field values which the I2RS client is
authorized to write (i.e. add, modify or delete). This access can authorized to write (i.e. add, modify or delete). This access can
restrict what fields can be modified or created, and what specific restrict what data can be modified or created, and what specific
value sets and ranges can be installed. value sets and ranges can be installed.
scope: When unspecified as either read scope or write scope, the scope: When unspecified as either read scope or write scope, the
term scope applies to both the read scope and write scope. term scope applies to both the read scope and write scope.
resources: A resource is an I2RS-specific use of memory, storage, resources: A resource is an I2RS-specific use of memory, storage,
or execution that a client may consume due to its I2RS operations. or execution that a client may consume due to its I2RS operations.
The amount of each such resource that a client may consume in the The amount of each such resource that a client may consume in the
context of a particular agent can be constrained. An example of context of a particular agent can be constrained based upon the
such a resource could include the number of notifications client's security role. An example of such a resource could
registered for. These are not protocol-specific resources or include the number of notifications registered for. These are not
network-specific resources. protocol-specific resources or network-specific resources.
role or security role: A security role specifies the scope, role or security role: A security role specifies the scope,
resources, priorities, etc. that a client or agent has. resources, priorities, etc. that a client or agent has.
identity: A client is associated with exactly one specific identity: A client is associated with exactly one specific
identity. State can be attributed to a particular identity. It identity. State can be attributed to a particular identity. It
is possible for multiple communication channels to use the same is possible for multiple communication channels to use the same
identity; in that case, the assumption is that the associated identity; in that case, the assumption is that the associated
client is coordinating such communication. client is coordinating such communication.
3. Key Architectural Properties 3. Key Architectural Properties
3.1. Simplicity 3.1. Simplicity
There have been many efforts over the years to improve the access to There have been many efforts over the years to improve the access to
the information known to the routing and forwarding system. Making the information known to the routing and forwarding system. Making
such information visible and usable to network management and 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. The span of information potentially related challenges in doing so. First, the span of information
available is very large. And the variation in the structure and potentially available is very large. Second, the variation both in
kinds of operations tends to introduce protocol complexity. the structure of the data and in the kinds of operations required
tends to introduce protocol complexity.
Having noted that, it is also critical to the utility of I2RS that it Having noted that, it is also critical to the utility of I2RS that it
be easily deployed and robust. Complexity in the protocol hinders be easily deployed and robust. Complexity in the protocol hinders
implementation, robustness, and deployability. Also, complexity in implementation, robustness, and deployability. Also, complexity in
the data models tends to actually make it harder to extend rather the data models frequently makes it harder to extend rather than
than easier. easier.
Thus, one of the key aims for I2RS is the keep the protocol and Thus, one of the key aims for I2RS is the keep the protocol and
modeling architecture simple. So for each architectural component or modeling architecture simple. So for each architectural component or
aspect, we ask ourselves "do we need this complexity, or is the aspect, we ask ourselves "do we need this complexity, or is the
behavior merely nice to have?" behavior merely nice to have?" Protocol parsimony is clearly a goal.
3.2. Extensibility 3.2. Extensibility
There are several ways that the scope of the I2RS work is being There are several ways that the scope of the I2RS work is being
restricted in the interests of achieving a deliverable and deployable restricted in the interests of achieving a deliverable and deployable
result. We are only looking at the models to be used over the single result. We are only working on the models to be used over the single
identified interface. We are only looking at modeling a subset of identified interface. We are only looking at modeling a subset of
the data of interest. And we are probably only representing a subset the data of interest. And we are probably only representing a subset
of the operations that may eventually be needed (although there is of the operations that may eventually be needed (although there is
some hope that we are closer on that aspect than others to what is some hope that we are closer on that aspect than others to what is
needed.) needed.) Thus, it is important to consider extensibility not only of
the underlying services' data models, but also of the primitives and
protocol operations.
At the same time, it is clearly desirable for the data models and At the same time, it is clearly desirable for the data models and
protocol operations we define in the I2RS to be useful the in more protocol operations we define in the I2RS to be useful the in more
general settings. It should be easy to integrate data models from general settings. It should be easy to integrate data models from
the I2RS with other data. Other work should be able to easily extend the I2RS with other data. Other work should be able to easily extend
it to represent additional aspects of the network elements or network it to represent additional aspects of the network elements or network
systems. Hence, the data model and protocol definitions need to be systems. Hence, the data model and protocol definitions need to be
designed to be highly extensible, preferably in a regular and simple designed to be highly extensible, preferably in a regular and simple
fashion. fashion.
skipping to change at page 10, line 6 skipping to change at page 10, line 4
At the same time, it is clearly desirable for the data models and At the same time, it is clearly desirable for the data models and
protocol operations we define in the I2RS to be useful the in more protocol operations we define in the I2RS to be useful the in more
general settings. It should be easy to integrate data models from general settings. It should be easy to integrate data models from
the I2RS with other data. Other work should be able to easily extend the I2RS with other data. Other work should be able to easily extend
it to represent additional aspects of the network elements or network it to represent additional aspects of the network elements or network
systems. Hence, the data model and protocol definitions need to be systems. Hence, the data model and protocol definitions need to be
designed to be highly extensible, preferably in a regular and simple designed to be highly extensible, preferably in a regular and simple
fashion. fashion.
3.3. Model-Driven Programmatic Interfaces 3.3. Model-Driven Programmatic Interfaces
A critical component of I2RS is the standard information and data A critical component of I2RS is the standard information and data
models with their associated semantics. While many routing protocols models with their associated semantics. While many components of the
are standardized, associated data models for them are not yet routing system are standardized, associated data models for them are
available. Instead, each router uses different information, not yet available. Instead, each router uses different information,
mechanisms, and CLI which makes a standard interface for use by different mechanisms, and different CLI which makes a standard
applications extremely cumbersome to develop and maintain. Well- interface for use by applications extremely cumbersome to develop and
known data modeling languages exist and may be used for defining the maintain. Well-known data modeling languages exist and may be used
necessary data models for I2RS. for defining the data models for I2RS.
There are several key benefits for I2RS in using model-driven There are several key benefits for I2RS in using model-driven
architecture and protocol(s). First, it allows for transferring architecture and protocol(s). First, it allows for transferring
data-models whose content is not explicitly implemented or data-models whose content is not explicitly implemented or
understood. Second, tools can automate checking and manipulating understood. Second, tools can automate checking and manipulating
data; this is particularly valuable for both extensibility and for data; this is particularly valuable for both extensibility and for
the ability to easily manipulate and check proprietary data-models. the ability to easily manipulate and check proprietary data-models.
The different services provided by I2RS can correspond to separate The different services provided by I2RS can correspond to separate
data-models. An I2RS agent can indicate which data-models are data-models. An I2RS agent may indicate which data-models are
supported. supported.
3.4. Authorization and Authentication 3.4. Authorization and Authentication
All control exchanges between the I2RS client and agent MUST be All control exchanges between the I2RS client and agent MUST be
authenticated and integrity protected (so that the contents cannot be authenticated and integrity protected (such that the contents cannot
changed without detection). Manipulation of the system has to be be changed without detection). Manipulation of the system must be
accurately attributable. Architecturally, even information accurately attributable. In an ideal architecture, even information
collection and notification should be protected, although this is collection and notification should be protected; this may be subject
subject to engineering tradeoffs during the design. to engineering tradeoffs during the design.
I2RS Agents, in performing information collection and manipulation, I2RS Agents, in performing information collection and manipulation,
will be acting on behalf of the I2RS clients. As such, they will will be acting on behalf of the I2RS clients. As such, they will
operate based on the lower of the two permissions of the agent itself operate based on the lower of the two permissions of the agent itself
and of the client. and of the client.
I2RS clients may be operating on behalf of other entities, in any one I2RS clients may be operating on behalf of other applications. While
of a range of broker models. While those identities are not need for those applications' identities are not need for authorization, each
authorization, they should still be provided by the I2RS client to application should have a unique opaque identifier that can be
the I2RS agent for purposes of tracking attribution of operations. provided by the I2RS client to the I2RS agent for purposes of
tracking attribution of operations.
4. Network Applications and I2RS Client 4. Network Applications and I2RS Client
An I2RS Client has a standardized interface that uses the I2RS An I2RS Client has a standardized interface that uses the I2RS
protocol(s) to communicate with I2RS Agents. The interface between protocol(s) to communicate with I2RS Agents. The interface between
an I2RS client and the network applications is outside the scope of an I2RS client and the network applications is outside the scope of
I2RS. I2RS.
When an I2RS Client interacts with multiple network applications, When an I2RS Client interacts with multiple network applications,
that I2RS Client is behaving as a broker and may indicate this to the that I2RS Client is behaving as a go-between and may indicate this to
I2RS Agents by, for example, specifying a secondary identity to allow the I2RS Agents by, for example, specifying a secondary opaque
improved troubleshooting. identity to allow improved troubleshooting.
A network application that uses an I2RS client may also be considered A network application that uses an I2RS client may also be considered
a routing element and include an I2RS agent for interactions. a routing element and include an I2RS agent for interactions.
However, where the needed information and data models for that upper However, where the needed information and data models for that upper
interface differs from that of a conventional routing element, those interface differs from that of a conventional routing element, those
models are, at least initially, out of scope for I2RS. models are, at least initially, out of scope for I2RS.
4.1. Example Network Application: Topology Manager 4.1. Example Network Application: Topology Manager
One example of such an application is a Topology Manager. Such an One example of such an application is a Topology Manager. Such an
skipping to change at page 12, line 10 skipping to change at page 12, line 10
affect the general I2RS agent behavior. affect the general I2RS agent behavior.
For scalability and generality, the I2RS agent may be responsible for For scalability and generality, the I2RS agent may be responsible for
collecting and delivering large amounts of data from various parts of collecting and delivering large amounts of data from various parts of
the routing element. Those parts may or may not actually be part of the routing element. Those parts may or may not actually be part of
a single physical device. Thus, for scalability and robustness, it a single physical device. Thus, for scalability and robustness, it
is important that the architecture allow for a distributed set of is important that the architecture allow for a distributed set of
reporting components providing collected data from the I2RS agent reporting components providing collected data from the I2RS agent
back to the relevant I2RS clients. As currently envisioned, a given back to the relevant I2RS clients. As currently envisioned, a given
I2RS agent would have only one locus per I2RS service for I2RS agent would have only one locus per I2RS service for
manipulation of routing element state; distributing the manipulations manipulation of routing element state.
would inducing complications and fragility instead of scalability and
robustness.
5.2. State Storage 5.2. State Storage
State modification requests are sent to the I2RS agent in a network State modification requests are sent to the I2RS agent in a network
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. One dimension of the storage for I2RS these changes to the system. How much data must the I2RS Agent store
Clients requests is how much data must the I2RS Agent store about about these state-modifying operations, and with what persistence?
this configuration, and with what persistence. There are range of There are range of possible answers. One extreme is where it stores
possible answers. One extreme is where it stores nothing, cannot nothing, cannot indicate why or by whom state was placed into the
indicate why or by whom state was placed into the routing element, routing element, and relies on clients reapplying things in all
and relies on clients reapplying things in all possible cases. The possible cases. The other extreme is where multiple clients'
other extreme is where multiple possibilities are stored and managed, overlapping operations are stored and managed, as is done in the RIB
as is done in the RIB for routes with a preference or priority to for routes with a preference or priority to pick between the routes.
pick between the routes. This architecture tries to provide
In answering this question, this architecture tries to provide
sufficient power to keep client operations effective, while still sufficient power to keep client operations effective, while still
being simple to implement in the I2RS Agent, and to observe being simple to implement in the I2RS Agent, and to observe
meaningfully during operation. meaningfully during operation. The I2RS agent stores the set of
operations it has applied. Simply, the I2RS agent stores who did
The I2RS agent stores the set of operations it has applied. Simply, what operation to which entity. New changes replace any data about
the I2RS agent stores who did what operation to which entity. New old ones. If an I2RS client does an operation to remove some state,
changes replace any data about old ones. If an I2RS client does an that state is removed and the I2RS agent stores no more information
operation to remove some state, that state is removed and the I2RS about it. This allows any interested party to determine what the
agent stores no more information about it. This allows any current effect of I2RS on the system is, and why. Meaningful logging
interested party to determine what the current effect of I2RS on the is also recommended.
system is, and why. Meaningful logging is also recommended.
The I2RS Agent will not attempt to retain or reapply state across The I2RS Agent will not attempt to retain or reapply state across
routing element reboot. Determination of whether state still applies routing element reboot. Determination of whether state still applies
depends heavily on the causes of reboots, and reapplication is at depends heavily on the causes of reboots, and reapplication is at
least as likely to cause problems as it is to provide for correct least as likely to cause problems as it is to provide for correct
operation. [[Editor's note: This topics needs more discussion in the operation. [[Editor's note: This topics needs more discussion in the
working group.]] working group.]]
5.2.1. Starting and Ending 5.2.1. Starting and Ending
skipping to change at page 13, line 14 skipping to change at page 13, line 12
only to be used under certain conditions. The I2RS interface only to be used under certain conditions. The I2RS interface
protocol could be designed to allow an I2RS Client to provide a wide protocol could be designed to allow an I2RS Client to provide a wide
range of such conditional information to the I2RS Agent for range of such conditional information to the I2RS Agent for
application. At the other extreme, the I2RS client could provide all application. At the other extreme, the I2RS client could provide all
such functionality based on its own clocking and network event such functionality based on its own clocking and network event
reporting from the relevant I2RS Agents. reporting from the relevant I2RS Agents.
Given that the complexity of possible conditions is very large, and Given that the complexity of possible conditions is very large, and
that some conditions may even cross network element boundaries, that some conditions may even cross network element boundaries,
clearly some degree of handling must be provided on the I2RS client. clearly some degree of handling must be provided on the I2RS client.
As such, this architecture takes the view that all the complexity As such, in this architecture it is assumed that all the complexity
associated with this should be left to the I2RS client. This associated with this should be left to the I2RS client. This
architectural view does mean that reliability of the communication architectural view does mean that reliability of the communication
path between the I2RS client and I2RS agent is critical. [[Editor's path between the I2RS client and I2RS agent is critical. [[Editor's
note: This requires more discussion in the working group.]] note: This requires more discussion in the working group.]]
5.2.2. Reversion 5.2.2. Reversion
An I2RS Agent may decide that some state should no longer be applied. An I2RS Agent may decide that some state should no longer be applied.
An I2RS Client may instruct an Agent to remove state it has applied. An I2RS Client may instruct an Agent to remove state it has applied.
In all such cases, the state will revert to what it would have been In all such cases, the state will revert to what it would have been
skipping to change at page 13, line 45 skipping to change at page 13, line 43
separate from the I2RS data store. Thus, changes may originate from separate from the I2RS data store. Thus, changes may originate from
either source. Policy (i.e. comparisons between a CLI/SNMP/NetConf either source. Policy (i.e. comparisons between a CLI/SNMP/NetConf
priority and a I2RS agent priority) can determine whether the local priority and a I2RS agent priority) can determine whether the local
configuration should overwrite any state written by I2RS and configuration should overwrite any state written by I2RS and
attributed to a particular I2RS Client or whether I2RS as attributed attributed to a particular I2RS Client or whether I2RS as attributed
to a particular I2RS Client can overwrite local configuration state. to a particular I2RS Client can overwrite local configuration state.
Simply allowing the most recent state to prevail could cause race Simply allowing the most recent state to prevail could cause race
conditions where the final state is not repeatably deterministic. conditions where the final state is not repeatably deterministic.
One important aspect is that if CLI/SNMP/NetConf changes data that is One important aspect is that if CLI/SNMP/NetConf changes data that is
subject to monitoring or manipulating by I2RS, then the system has to subject to monitoring or manipulating by I2RS, then the system must
be instrumented enough to provide suitable I2RS notifications of be instrumented enough to provide suitable I2RS notifications of
these changes. these changes.
5.4. Routing Components and Associated I2RS Services 5.4. Routing Components and Associated I2RS Services
For simplicity, each logical protocol or set of functionality that be For simplicity, each logical protocol or set of functionality that be
compactly described in a separable information and data model is compactly described in a separable information and data model is
considered as a separate I2RS Service. A routing element need not considered as a separate I2RS Service. A routing element need not
implement all routing components described nor provide the associated implement all routing components described nor provide the associated
I2RS services. The initial services included in the I2RS I2RS services. The initial services included in the I2RS
architecture are as follows. architecture are as follows.
5.4.1. Unicast and Multicast RIB and LFIB 5.4.1. Unicast and Multicast RIB and LFIB
Network elements concerned with routing IP maintain IP unicast RIBs. Network elements concerned with routing IP maintain IP unicast RIBs.
skipping to change at page 14, line 16 skipping to change at page 14, line 19
considered as a separate I2RS Service. A routing element need not considered as a separate I2RS Service. A routing element need not
implement all routing components described nor provide the associated implement all routing components described nor provide the associated
I2RS services. The initial services included in the I2RS I2RS services. The initial services included in the I2RS
architecture are as follows. architecture are as follows.
5.4.1. Unicast and Multicast RIB and LFIB 5.4.1. Unicast and Multicast RIB and LFIB
Network elements concerned with routing IP maintain IP unicast RIBs. Network elements concerned with routing IP maintain IP unicast RIBs.
Similarly, there are RIBs for IP Multicast, and a Label Information Similarly, there are RIBs for IP Multicast, and a Label Information
Base (LIB) for MPLS. The I2RS Agent needs to be able to read and Base (LIB) for MPLS. The I2RS Agent needs to be able to read and
write these sets of data. The I2RS data model has to include models write these sets of data. The I2RS data model must include models
for this information. for this information.
In particular, with regard to writing this information, the I2RS In particular, with regard to writing this information, the I2RS
Agent should use the same mechanisms that the routing element already Agent should use the same mechanisms that the routing element already
uses to handle RIB input from multiple sources, so as to compatibly uses to handle RIB input from multiple sources, so as to compatibly
change the system state. change the system state.
The multicast state added to the multicast RIB does not need to match The multicast state added to the multicast RIB does not need to match
to well-known protocol installed state. The I2RS Agent can create to well-known protocol installed state. The I2RS Agent can create
arbitrary replication state in the RIB, subject to the advertised arbitrary replication state in the RIB, subject to the advertised
capabilities of the routing element. capabilities of the routing element.
5.4.2. IGPs, BGP and Multicast Protocols 5.4.2. IGPs, BGP and Multicast Protocols
In addition to interacting with the consolidated RIB, the I2RS agent In addition to interacting with the consolidated RIB, the I2RS agent
needs to interact with the individual routing protocols on the may need to interact with the individual routing protocols on the
device. This interaction includes a number of different kinds of device. This interaction includes a number of different kinds of
operations: operations:
o reading the various internal rib(s) of the routing protocol is o reading the various internal rib(s) of the routing protocol is
often helpful for understanding the state of the network. often helpful for understanding the state of the network.
Directly writing these protocol-specific RIBs or databases is NOT Directly writing these protocol-specific RIBs or databases is out
part of the system. of scope for I2RS.
o reading the various pieces of policy information the particular o reading the various pieces of policy information the particular
protocol instance is using to drive its operations. protocol instance is using to drive its operations.
o writing policy information such as interface attributes that are o writing policy information such as interface attributes that are
specific to the routing protocol or BGP policy that may indirectly specific to the routing protocol or BGP policy that may indirectly
manipulate attributes of routes carried in BGP. manipulate attributes of routes carried in BGP.
o writing routes or prefixes to be advertised via the protocol. o writing routes or prefixes to be advertised via the protocol.
skipping to change at page 15, line 4 skipping to change at page 15, line 6
o reading the various pieces of policy information the particular o reading the various pieces of policy information the particular
protocol instance is using to drive its operations. protocol instance is using to drive its operations.
o writing policy information such as interface attributes that are o writing policy information such as interface attributes that are
specific to the routing protocol or BGP policy that may indirectly specific to the routing protocol or BGP policy that may indirectly
manipulate attributes of routes carried in BGP. manipulate attributes of routes carried in BGP.
o writing routes or prefixes to be advertised via the protocol. o writing routes or prefixes to be advertised via the protocol.
o joining/removing interfaces from the multicast trees o joining/removing interfaces from the multicast trees
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,
modifying the link-state database itself would clearly not be direct modification of of the link-state database is NOT allowed to
permitted; that could lead to inconsistency. preserve network state consistency.
5.4.3. MPLS 5.4.3. MPLS
The I2RS Agent will need to interact with the knobs that policy The I2RS Agent will need to interact with the knobs that policy
attributes that control LDP operation as well as RSVP-TE based LSPs. attributes that control LDP operation as well as RSVP-TE based LSPs.
To avoid duplication, the I2RS interface will not duplicate the path
computation and active path setup components of the PCE protocols.
5.4.4. Policy and QoS Mechanisms 5.4.4. Policy and QoS Mechanisms
Many network elements have separate policy and QoS mechanisms, Many network elements have separate policy and QoS mechanisms,
including knobs which affect local path computation and queue control including knobs which affect local path computation and queue control
capabilities. These capabilities vary widely across implementations, capabilities. These capabilities vary widely across implementations,
and I2RS cannot model the full range of information collection or and I2RS cannot model the full range of information collection or
manipulation of these attributes. A core set does need to be manipulation of these attributes. A core set does need to be
included in the I2RS data models and in the expected interfaces included in the I2RS data models and in the expected interfaces
between the I2RS Agent and the network element, in order to provide between the I2RS Agent and the network element, in order to provide
basic capabilities and the hooks for extensibility. basic capabilities and the hooks for future extensibility.
6. I2RS Client Agent Interface 6. I2RS Client Agent Interface
6.1. Protocol Structure 6.1. Protocol Structure
One could view I2RS merely as a way to talk about the existing One could view I2RS merely as a way to talk about the existing
network management interfaces to a network element. That would be network management interfaces to a network element. That would be
quite limiting, and would have trouble meeting the requirements quite limiting and would not meet the requirements elucidated
elucidated elsewhere. One could also view it as a collection of elsewhere. One could also view I2RS as a collection of protocols -
protocols, some existing and some new, that meet the needs. While some existing and some new - that meet the needs. While that could
that could be made to work, the complexity of such a mechanism would be made to work, the complexity of such a mechanism would be quite
be quite high. One would need to develop means to coordinate high. One would need to develop means to coordinate information
information across a set of protocols that were not designed to work across a set of protocols that were not designed to work together.
together. As a result, this architecture views the I2RS interface as From a deployability perspective, this would not meet the goal of
an interface supporting a single control and data exchange protocol. simplicity. As a result, this architecture views the I2RS interface
That protocol may use several underlying transports (TCP, SCTP, as an interface supporting a single control and data exchange
DCCP), with suitable authentication and integrity protection protocol. That protocol may use several underlying transports (TCP,
SCTP, DCCP), with suitable authentication and integrity protection
mechanisms. Whatever transport is used for the data exchange, it mechanisms. Whatever transport is used for the data exchange, it
must also support suitable congestion control mechanisms. must also support suitable congestion control mechanisms.
6.2. Channel 6.2. Channel
The uses of a single I2RS protocol does not imply that only one The uses of a single I2RS protocol does not imply that only one
channel of communication is needed. There may be a range of channel of communication is required. There may be a range of
reliability needs, and to support the scaling there may need to be reliability requirements, and to support the scaling there may need
channels from multiple parts of a routing element. These will all to be channels originating from multiple sub-components of a routing
use the date exchange protocol, and establishment of additional element. These will all use the date exchange protocol, and
channels for communication will be coordinated between the I2RS establishment of additional channels for communication will be
client and the I2RS agent. coordinated between the I2RS client and the I2RS agent.
6.3. Negotiation 6.3. Negotiation
Protocol support capabilities will vary across I2RS Clients and Protocol support capabilities will vary across I2RS Clients and
Routing Elements supporting I2RS Agents. As such, it is likely that Routing Elements supporting I2RS Agents. As such, capability
capability negotiation (such as which transports are supported beyond negotiation (such as which transports are supported beyond the
the minimum required to implement) will be necessary. It is minimum required to implement) will clearly be necessary. It is
important that such negotiations be kept simple and robust, as such important that such negotiations be kept simple and robust, as such
mechanisms are often a source of difficulty in implementation and mechanisms are often a source of difficulty in implementation and
deployment. deployment.
Negotiation should be broken into several aspects, such as protocol
capablities and I2RS services and model types supported.
6.4. Identity and Security Role 6.4. Identity and Security Role
Each I2RS Client will have an identity; it can also have secondary Each I2RS Client will have an identity; it can also have secondary
identities to be used for troubleshooting. Via authentication and identities to be used for troubleshooting. A secondary identity is
authorization mechanisms, the I2RS agent will have a specific scope merely a unique, opaque identifier that may be helpful in
for reading data, for writing data, and limitations on the resources troubleshooting. Via authentication and authorization mechanisms,
that can be consumed. The scopes need to specify both the data and the I2RS agent will have a specific scope for reading data, for
the value ranges. writing data, and limitations on the resources that can be consumed.
The scopes need to specify both the data and the value ranges.
6.5. Connectivity 6.5. Connectivity
A client does not need to maintain an active communication channel A client does not need to maintain an active communication channel
with an agent. Therefore, an agent may need to open a communication with an agent. Therefore, an agent may need to open a communication
channel to the client to communicate previously requested channel to the client to communicate previously requested
information. The lack of an active communication channel does not information. The lack of an active communication channel does not
imply that the associated client is non-functional. When imply that the associated client is non-functional. When
communication is required, the agent or client can open a new communication is required, the agent or client can open a new
communication channel. communication channel.
State held by an agent that is owned by a client should not be State held by an agent that is owned by a client should not be
removed or cleaned up when a client is no longer communicating - even removed or cleaned up when a client is no longer communicating - even
if the agent cannot successfully open a new communication channel to if the agent cannot successfully open a new communication channel to
the client. the client.
There are two different assumptions that can apply to handling dead There are three different assumptions that can apply to handling dead
clients. The first is that the network application layer will detect clients. The first is that the network applications or management
a dead network application and either restart that network systems will detect a dead network application and either restart
application or clean up any state left behind. The second is to that network application or clean up any state left behind. The
allow state expiration, expressed as a policy associated with the second is to allow state expiration, expressed as a policy associated
I2RS client's role. The state expiration could occur after there has with the I2RS client's role. The state expiration could occur after
been no successful communication channel to or from the I2RS client there has been no successful communication channel to or from the
for the policy-specified duration. I2RS client for the policy-specified duration. The third is that the
client could explicitly request state clean-up if a particular
transport session is terminated.
6.6. Notifications 6.6. Notifications
As with any policy system interacting with the network, the I2RS As with any policy system interacting with the network, the I2RS
Agent needs to be able to receive notifications of changes in network Agent needs to be able to receive notifications of changes in network
state. Notifications here refers to changes which are unanticipated, state. Notifications here refers to changes which are unanticipated,
represent events outside the control of the systems (such as represent events outside the control of the systems (such as
interface failures on controlled devices), or are sufficiently sparse interface failures on controlled devices), or are sufficiently sparse
as to be anomalous in some fashion. as to be anomalous in some fashion.
skipping to change at page 18, line 48 skipping to change at page 18, line 45
Perform all or none: This traditional SNMP semantic indicates that Perform all or none: This traditional SNMP semantic indicates that
other I2RS agent will keep enough state when handling a single other I2RS agent will keep enough state when handling a single
message to roll back the operations within that message. Either message to roll back the operations within that message. Either
all the operations will succeed, or none of them will be applied all the operations will succeed, or none of them will be applied
and an error message will report the single failure which caused and an error message will report the single failure which caused
the not to be applied. This is useful when there are, for the not to be applied. This is useful when there are, for
example, mutual dependencies across operations in the message. example, mutual dependencies across operations in the message.
Perform until error: In this case, the operations in the message Perform until error: In this case, the operations in the message
are applied in order. When an error occurs, no further operations are applied in the specified order. When an error occurs, no
are applied, and an error is returned indicating the failure. further operations are applied, and an error is returned
This is useful if there are dependencies among the operations and indicating the failure. This is useful if there are dependencies
they can be topologically sorted. among the operations and they can be topologically sorted.
Perform all: In this case, the I2RS Agent will attempt to perform Perform all: In this case, the I2RS Agent will attempt to perform
all the operations in the message, and will return error all the operations in the message, and will return error
indications for each one that fails. This is useful when there is indications for each one that fails. This is useful when there is
no dependency across the operation, or where the client would no dependency across the operation, or where the client would
prefer to sort out the effect of errors on its own. prefer to sort out the effect of errors on its own.
In the interest of robustness and clarity of protocol state, the In the interest of robustness and clarity of protocol state, the
protocol will include an explicit reply to modification operations protocol will include an explicit reply to modification operations
even when they fully succeed. even when they fully succeed.
skipping to change at page 19, line 48 skipping to change at page 19, line 45
data models and the value ranges are discussed briefly in data models and the value ranges are discussed briefly in
Section 6.4. Section 6.4.
9. IANA Considerations 9. IANA Considerations
This document includes no request to IANA. This document includes no request to IANA.
10. Acknowledgements 10. Acknowledgements
Significant portions of this draft came from draft-ward-i2rs- Significant portions of this draft came from draft-ward-i2rs-
framework-00 and draft-atlas-i2rs-policy-framework-00. The authors framework-00 and draft-atlas-i2rs-policy-framework-00.
would like to acknowledge Tom Nadeau, who was a co-author on draft-
ward-i2rs-framework-00.
The authors would like to thank Nitin Bahadur, Shane Amante, and Ken The authors would like to thank Nitin Bahadur, Shane Amante, Ed
Gray for their suggestions and review. Crabbe, and Ken Gray for their suggestions and review.
11. Informative References 11. Informative References
[I-D.atlas-i2rs-problem-statement] [I-D.atlas-i2rs-problem-statement]
Atlas, A., Nadeau, T., and D. Ward, "Interface to the Atlas, A., Nadeau, T., and D. Ward, "Interface to the
Routing System Problem Statement", draft-atlas-i2rs- Routing System Problem Statement", draft-atlas-i2rs-
problem-statement-00 (work in progress), February 2013. problem-statement-01 (work in progress), July 2013.
Authors' Addresses Authors' Addresses
Alia Atlas Alia Atlas
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
USA USA
Email: akatlas@juniper.net Email: akatlas@juniper.net
skipping to change at line 911 skipping to change at page 20, line 37
Email: shares@ndzh.com Email: shares@ndzh.com
Dave Ward Dave Ward
Cisco Systems Cisco Systems
Tasman Drive Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: wardd@cisco.com Email: wardd@cisco.com
Thomas D. Nadeau
Juniper Networks
Email: tnadeau@juniper.net
 End of changes. 57 change blocks. 
138 lines changed or deleted 147 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/