draft-atlas-i2rs-architecture-01.txt   draft-atlas-i2rs-architecture-02.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: January 16, 2014 Ericsson Expires: February 14, 2014 Ericsson
S. Hares S. Hares
ADARA ADARA
D. Ward D. Ward
Cisco Systems Cisco Systems
T. Nadeau T. Nadeau
Juniper Networks Juniper Networks
July 15, 2013 August 13, 2013
An Architecture for the Interface to the Routing System An Architecture for the Interface to the Routing System
draft-atlas-i2rs-architecture-01 draft-atlas-i2rs-architecture-02
Abstract Abstract
This document describes an architecture for a standard, programmatic This document describes an architecture for a standard, programmatic
interface for state transfer in and out of the Internet's routing interface for state transfer in and out of the Internet's routing
system. It describes the basic architecture, the components, and system. It describes the basic architecture, the components, and
their interfaces with particular focus on those to be standardized as their interfaces with particular focus on those to be standardized as
part of I2RS. part of I2RS.
Status of This Memo Status of This Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 16, 2014. This Internet-Draft will expire on February 14, 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 18 skipping to change at page 2, line 18
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Functional Overview . . . . . . . . . . . . . . . . . . . 3 1.1. 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 . . . . . . . . . . . . . . . . 8
3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Model-Driven Programmatic Interfaces . . . . . . . . . . 9 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 . . . . . . 10
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 . . . . . 14 5.4. Routing Components and Associated I2RS Services . . . . . 13
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 . . . . . . . . . . . . . . . . . . . . . . . . . 15 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.4.1. Client Redundancy . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 18
6.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 17 6.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 18
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 . . . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
11. Informative References . . . . . . . . . . . . . . . . . . . 19 11. Informative References . . . . . . . . . . . . . . . . . . . 20
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 43 skipping to change at page 3, line 44
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 as much as desired. leveraging the existing routing system as much as desired.
The I2RS, and therefore this document, are specifically focused on an The I2RS, and therefore this document, are specifically focused on an
interface for routing and forwarding data. interface for routing 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 which needs to be 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
skipping to change at page 4, line 30 skipping to change at page 4, line 32
the co-located forwarding plane). 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
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
infrastructure can be quite high and many MIBs do not, in definition
or practice, allow writing of state. There is also very limited
capability to add new application-specific state to be distributed
via the routing system.
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
forwarding plane, it requires that the forwarding plane be modeled
and programmable and ignores the existence and intelligence of the
router OS and routing system. ForCES provides a lower-level
interface than I2RS is intended to address.
1.2. Architectural Overview 1.2. Architectural Overview
The figure in Figure 1 shows the basic architecture for I2RS. Inside The figure in Figure 1 shows the basic architecture for I2RS. Inside
a Routing Element, the I2RS agent interacts with both the routing a Routing Element, the I2RS agent interacts with both the routing
subsystem and with local configuration. A network application uses subsystem and with local configuration. A network application uses
an I2RS client to communicate with one or more I2RS agents on their an I2RS client to communicate with one or more I2RS agents on their
routing elements. The scope of I2RS is to define the interactions routing elements. The scope of I2RS is to define the interactions
between the I2RS agent and the I2RS client and the associated proper between the I2RS agent and the I2RS client and the associated proper
behavior of the I2RS agent and I2RS client. behavior of the I2RS agent and I2RS client.
skipping to change at page 6, line 4 skipping to change at page 5, line 37
Routing Element: A Routing Element implements at least some portion Routing Element: A Routing Element implements at least some portion
of the routing system. It does not need to have a forwarding of the routing system. It does not need to have a forwarding
plane associated with it. Examples of Routing Elements can plane associated with it. Examples of Routing Elements can
include: include:
A router with a forwarding plane and RIB Manager that runs A router with a forwarding plane and RIB Manager that runs
ISIS, OSPF, BGP, PIM, etc. ISIS, OSPF, BGP, PIM, etc.
A server that runs BGP as a Route Reflector A server that runs BGP as a Route Reflector
An LSR that implements RSVP-TE, OSPF-TE, and PCEP and has a An LSR that implements RSVP-TE, OSPF-TE, and PCEP and has a
forwarding plane and associated RIB Manager. forwarding plane and associated RIB Manager.
A server that runs ISIS, OSPF, BGP and uses ForCES to control a A server that runs ISIS, OSPF, BGP and uses ForCES to control a
remote forwarding plane. remote forwarding plane.
A Routing Element may be locally managed, whether via CLI, SNMP, A Routing Element may be locally managed, whether via CLI, SNMP,
or NetConf. or NETCONF.
Routing: This block represents that portion of the Routing Element Routing: This block represents that portion of the Routing Element
that implements part of the Internet routing system. It includes that implements part of the Internet routing system. It includes
not merely standardized protocols (i.e. IS-IS, OSPF, BGP, PIM, not merely standardized protocols (i.e. IS-IS, OSPF, BGP, PIM,
RSVP-TE, LDP, etc.), but also the RIB Manager layer. RSVP-TE, LDP, etc.), but also the RIB Manager layer.
Local Config: A Routing Element will provide the ability to Local Config: A Routing Element will provide the ability to
configure and manage it. The Local Config may be provided via a configure and manage it. The Local Config may be provided via a
combination of CLI, NetConf, SNMP, etc. The black box behavior combination of CLI, NETCONF, SNMP, etc. The black box behavior
for interactions between the state that I2RS installs into the for interactions between the state that I2RS installs into the
routing element and the Local Config must be defined. routing element and the Local Config must be defined.
Dynamic System State: An I2RS agent needs access to state on a Dynamic System State: An I2RS agent needs access to state on a
routing element beyond what is contained in the routing subsystem. routing element beyond what is contained in the routing subsystem.
Such state may include various counters, statistics, and local Such state may include various counters, statistics, and local
events. How this information is provided to the I2RS agent is out events. How this information is provided to the I2RS agent is out
of scope, but the standardized information and data models for of scope, but the standardized information and data models for
what is exposed are part of I2RS. what is exposed are part of I2RS.
I2RS Agent: The I2RS agent implements the I2RS protocol(s) and I2RS Agent: The I2RS agent implements the I2RS protocol(s) and
interacts with the routing element to provide specified behavior. interacts with the routing element to provide specified behavior.
Application: A network application that needs to manipulate the Application: A network application that needs to manipulate the
network to achieve its service requirements. network to achieve its service requirements.
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 agents 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. An I2RS client may connect to one or more I2RS multiple I2RS agents. An I2RS client may connect to one or more I2RS
agents based upon its needs. Similarly, an I2RS agent may agents based upon its needs. Similarly, an I2RS agent may
communicate with multiple I2RS clients - whether to respond to their communicate with multiple I2RS clients - whether to respond to their
requests, to send notifications, etc. Timely notifications are requests, to send notifications, etc. Timely notifications are
skipping to change at page 7, line 32 skipping to change at page 7, line 15
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. The nuances so that writers do not must be correctly handled. The nuances so that writers do not
normally collide should be handled in the information models. 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 must be noted that there may be indirect interactions In addition it must be noted that there may be indirect interactions
between write operations. Detection and avoidance of such between write operations. 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.
skipping to change at page 9, line 5 skipping to change at page 8, line 30
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.
secondary identity: An I2RS Client may supply a secondary opaque
identity that is not interpreted by the I2RS Agent. An example
use is when the I2RS Client is a go-between for multiple
applications and it is necessary to track which application has
requested a particular operation.
3. Key Architectural Properties 3. Key Architectural Properties
3.1. Simplicity 3.1. Simplicity
There have been many efforts over the years to improve the access to There have been many efforts over the years to improve the access to
the information known to the routing and forwarding system. Making the information 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. First, the span of information related challenges in doing so. First, the span of information
potentially available is very large. Second, the variation both in potentially available is very large. Second, the variation both in
skipping to change at page 10, line 42 skipping to change at page 10, line 29
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 applications. While I2RS clients may be operating on behalf of other applications. While
those applications' identities are not need for authorization, each those applications' identities are not need for authorization, each
application should have a unique opaque identifier that can be application should have a unique opaque identifier that can be
provided by the I2RS client to the I2RS agent for purposes of provided by the I2RS client to the I2RS agent for purposes of
tracking attribution of operations. tracking attribution of operations to support functionality such as
accounting and troubleshooting.
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 go-between and may indicate this to that I2RS Client is behaving as a go-between and should indicate this
the I2RS Agents by, for example, specifying a secondary opaque to the I2RS Agents by, for example, specifying a secondary opaque
identity to allow 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. A Topology
Manager includes an I2RS client that uses the I2RS data models and
protocol to collect information about the state of the network by
communicating directly with one or more I2RS agents. From these I2RS
agents, the Topology Manager collects routing configuration and
operational data. Most importantly, it collects information about
the routing system, including the contents of the IGP (e.g., IS-IS or
OSPF) and BGP data sets.
One example of such an application is a Topology Manager. Such an The Topology Manager may be embedded as a component of a larger
application includes an I2RS client which uses the I2RS protocol to application. It would construct internal data structures and use the
collect information about the state of the network. The Topology collected data to drive functions such as path computations or
Manager would collect device and interface state from devices it anomalous routing detection. Alternatively, the Topology Manager
interacts with directly. It also collects routing configuration and could combine the I2RS-collected data with other information,
operation data from those devices. Most importantly, it collects abstract a composite set, and provide a coherent picture of the
information about the routing system, including the contents of the network state accessible via another interface. That interface might
IGP (e.g. IS-IS or OSPF) and BGP data sets. This information is use the same I2RS protocol and could use extensions to the I2RS data
provided to the I2RS client using the I2RS data models and protocols. models. Developing such mechanisms is outside the initial scope of
the I2RS work.
The Topology Manager may be an integral part of an application. It
would build internal data structures, and use the collected data to
drive applications like path computations or anomalous routing
detection. Alternatively, the Topology manager could combine the
I2RS collected data with other information, abstract the result, and
provide a coherent picture of the network state over another
interface. That interface might use the same I2RS protocols, and
could use extensions of the I2RS data models. Developing such
mechanisms is outside the initial scope of the I2RS work.
5. I2RS Agent Role and Functionality 5. I2RS Agent Role and Functionality
The I2RS Agent is part of a routing element. As such, it has The I2RS Agent is part of a routing element. As such, it has
relationships with that routing element as a whole, and with various relationships with that routing element as a whole, and with various
components of that routing element. components of that routing element.
5.1. Relationship to its Routing Element 5.1. Relationship to its Routing Element
A Routing Element may be implemented with a wide variety of different A Routing Element may be implemented with a wide variety of different
skipping to change at page 12, line 46 skipping to change at page 12, line 39
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
An I2RS client applies changes via the I2RS interface based on policy An I2RS client applies changes via the I2RS protocol based on policy
and other application inputs. While these changes may be of the form and other application inputs. While these changes may be of the form
"do this now, and leave it there forever", they are frequently driven "do this now, and leave it there forever", they are frequently driven
by other conditions which may have start times, stop times, or are by other conditions which may have start times, stop times, or are
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.
skipping to change at page 13, line 24 skipping to change at page 13, line 17
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
without the I2RS; that state is generally whatever was specified via without the I2RS; that state is generally whatever was specified via
the CLI, NetConf, SNMP, etc. I2RS Agents will not store multiple the CLI, NETCONF, SNMP, etc. I2RS Agents will not store multiple
alternative states, nor try to determine which one among such a alternative states, nor try to determine which one among such a
plurality it should fall back to. Thus, the model followed is not plurality it should fall back to. Thus, the model followed is not
like the RIB, where multiple routes are stored at different like the RIB, where multiple routes are stored at different
preferences. preferences.
An I2RS Client may register for notifications when state that was
applied by a particular I2RS Client is modified or removed.
5.3. Interactions with Local Config 5.3. Interactions with Local Config
As described above, local device configuration is considered to be As described above, local device configuration is considered to be
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 must 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
skipping to change at page 15, line 15 skipping to change at page 15, line 7
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,
direct modification of of the link-state database is NOT allowed to direct modification of of the link-state database is NOT allowed to
preserve network state consistency. 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 protocols that create
attributes that control LDP operation as well as RSVP-TE based LSPs. transport LSPs (e.g. LDP and RSVP-TE) as well as protocols (e.g. BGP,
LDP) that provide MPLS-based services (e.g. pseudowires, L3VPNs,
L2VPNs, etc).
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 future extensibility. basic capabilities and the hooks for future extensibility.
[[Editor's note: This requires more discussion in the working
group.]]
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 not meet the requirements elucidated quite limiting and would not meet the requirements elucidated
elsewhere. One could also view I2RS as a collection of protocols - elsewhere. One could also view I2RS as a collection of protocols -
some existing and some new - that meet the needs. While that could some existing and some new - that meet the needs. While that could
be made to work, the complexity of such a mechanism would be quite be made to work, the complexity of such a mechanism would be quite
high. One would need to develop means to coordinate information high. One would need to develop means to coordinate information
across a set of protocols that were not designed to work together. across a set of protocols that were not designed to work together.
From a deployability perspective, this would not meet the goal of From a deployability perspective, this would not meet the goal of
simplicity. As a result, this architecture views the I2RS interface simplicity. As a result, this architecture views the I2RS as an
as an interface supporting a single control and data exchange interface supporting a single control and data exchange protocol.
protocol. That protocol may use several underlying transports (TCP, Whether such a protocol is built upon extending existing mechanisms
SCTP, DCCP), with suitable authentication and integrity protection or requires a new mechanism requires further investigation. That
mechanisms. Whatever transport is used for the data exchange, it protocol may use several underlying transports (TCP, SCTP, DCCP),
must also support suitable congestion control mechanisms. with suitable authentication and integrity protection mechanisms.
These different transports can support different types of
communication (e.g. control, reading, notifications, and information
collection) and different sets of data. Whatever transport is used
for the data exchange, it must also support suitable congestion
control mechanisms.
6.2. Channel 6.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 required. There may be a range of channel of communication is required. There may be a range of
reliability requirements, and to support the scaling there may need reliability requirements, and to support the scaling there may need
to be channels originating from multiple sub-components of a routing to be channels originating from multiple sub-components of a routing
element. These will all use the date exchange protocol, and element. These will all use the date exchange protocol, and
establishment of additional channels for communication will be establishment of additional channels for communication will be
coordinated between the I2RS client and the I2RS agent. coordinated between the I2RS client and the I2RS agent.
6.3. Negotiation 6.3. Negotiation
skipping to change at page 16, line 25 skipping to change at page 16, line 27
minimum required to implement) will clearly 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 Negotiation should be broken into several aspects, such as protocol
capablities and I2RS services and model types supported. 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 a unique identity; it can also have
identities to be used for troubleshooting. A secondary identity is secondary identities to be used for troubleshooting. A secondary
merely a unique, opaque identifier that may be helpful in identity is merely a unique, opaque identifier that may be helpful in
troubleshooting. Via authentication and authorization mechanisms, troubleshooting. Via authentication and authorization mechanisms,
the I2RS agent will have a specific scope for reading data, for the I2RS agent will have a specific scope for reading data, for
writing data, and limitations on the resources that can be consumed. writing data, and limitations on the resources that can be consumed.
The scopes need to specify both the data and the value ranges. The scopes need to specify both the data and the value ranges.
6.5. Connectivity 6.4.1. Client Redundancy
A client does not need to maintain an active communication channel I2RS must support client redundancy. At the simplest, this can be
with an agent. Therefore, an agent may need to open a communication handled by having a primary and a backup network application that
both use the same client identity and can successfully authenticate
as such. Since I2RS does not require a continuous transport
connection and supports multiple transport sessions, this can provide
some basic redundancy. However, it does not address concerns for
troubleshooting and accountability about knowing which network
application is actually active. At a minimum, basic transport
information about each connection and time can be logged with the
identity. Further discussion is necessary to determine whether
additional client identification information is necessary.[[Editor's
note: This requires more discussion in the working group.]]
6.5. Connectivity
A client may or may not maintain an active communication channel 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.
skipping to change at page 18, line 50 skipping to change at page 19, line 19
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 the specified order. When an error occurs, no are applied in the specified order. When an error occurs, no
further operations are applied, and an error is returned further operations are applied, and an error is returned
indicating the failure. This is useful if there are dependencies indicating the failure. This is useful if there are dependencies
among the operations and they can be topologically sorted. among the operations and they can be topologically sorted.
Perform all: In this case, the I2RS Agent will attempt to perform Perform all storing errors: In this case, the I2RS Agent will
all the operations in the message, and will return error attempt to perform all the operations in the message, and will
indications for each one that fails. This is useful when there is return error indications for each one that fails. This is useful
no dependency across the operation, or where the client would when there is no dependency across the operation, or where the
prefer to sort out the effect of errors on its own. client would prefer to sort out the effect of errors on its own.
In the interest of robustness and clarity of protocol state, the In the interest of robustness and clarity of protocol state, the
protocol will include an explicit reply to modification operations protocol will include an explicit reply to modification operations
even when they fully succeed. even when they fully succeed.
7. Manageability Considerations 7. Manageability Considerations
Manageability plays a key aspect in I2RS. Some initial examples Manageability plays a key aspect in I2RS. Some initial examples
include: include:
skipping to change at page 19, line 48 skipping to change at page 20, line 23
9. IANA Considerations 9. IANA Considerations
This document includes no request to IANA. This document includes no request to IANA.
10. Acknowledgements 10. Acknowledgements
Significant portions of this draft came from draft-ward-i2rs- Significant portions of this draft came from draft-ward-i2rs-
framework-00 and draft-atlas-i2rs-policy-framework-00. framework-00 and draft-atlas-i2rs-policy-framework-00.
The authors would like to thank Nitin Bahadur, Shane Amante, Ed The authors would like to thank Nitin Bahadur, Shane Amante, Ed
Crabbe, and Ken Gray for their suggestions and review. Crabbe, Ken Gray, Carlos Pignataro, Wes George, Joe Clarke, Juergen
Schoenwalder, and Jamal Hadi Salim 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-01 (work in progress), July 2013. problem-statement-01 (work in progress), July 2013.
Authors' Addresses Authors' Addresses
 End of changes. 36 change blocks. 
80 lines changed or deleted 99 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/