draft-ietf-i2rs-architecture-07.txt   draft-ietf-i2rs-architecture-08.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: June 14, 2015 Ericsson Expires: July 11, 2015 Ericsson
S. Hares S. Hares
Huawei Huawei
D. Ward D. Ward
Cisco Systems Cisco Systems
T. Nadeau T. Nadeau
Brocade Brocade
December 11, 2014 January 7, 2015
An Architecture for the Interface to the Routing System An Architecture for the Interface to the Routing System
draft-ietf-i2rs-architecture-07 draft-ietf-i2rs-architecture-08
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 routing interface for state transfer in and out of the Internet routing
system. It describes the basic architecture, the components, and system. It describes the basic architecture, the components, and
their interfaces with particular focus on those to be standardized as their interfaces with particular focus on those to be standardized as
part of I2RS. part of the Interface to Routing System (I2RS).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 14, 2015. This Internet-Draft will expire on July 11, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 24 skipping to change at page 2, line 24
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Drivers for the I2RS Architecture . . . . . . . . . . . . 4 1.1. Drivers for the I2RS Architecture . . . . . . . . . . . . 4
1.2. Architectural Overview . . . . . . . . . . . . . . . . . 5 1.2. Architectural Overview . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Key Architectural Properties . . . . . . . . . . . . . . . . 10 3. Key Architectural Properties . . . . . . . . . . . . . . . . 10
3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Model-Driven Programmatic Interfaces . . . . . . . . . . 11 3.3. Model-Driven Programmatic Interfaces . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
4.1. Identity and Authentication . . . . . . . . . . . . . . . 13 4.1. Identity and Authentication . . . . . . . . . . . . . . . 13
4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 14
5. Network Applications and I2RS Client . . . . . . . . . . . . 14 4.3. Client Redundancy . . . . . . . . . . . . . . . . . . . . 14
5. Network Applications and I2RS Client . . . . . . . . . . . . 15
5.1. Example Network Application: Topology Manager . . . . . . 15 5.1. Example Network Application: Topology Manager . . . . . . 15
6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 15 6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 16
6.1. Relationship to its Routing Element . . . . . . . . . . . 15 6.1. Relationship to its Routing Element . . . . . . . . . . . 16
6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 16 6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 16
6.2.1. I2RS Agent Failure . . . . . . . . . . . . . . . . . 16 6.2.1. I2RS Agent Failure . . . . . . . . . . . . . . . . . 17
6.2.2. Starting and Ending . . . . . . . . . . . . . . . . . 17 6.2.2. Starting and Ending . . . . . . . . . . . . . . . . . 18
6.2.3. Reversion . . . . . . . . . . . . . . . . . . . . . . 17 6.2.3. Reversion . . . . . . . . . . . . . . . . . . . . . . 18
6.3. Interactions with Local Config . . . . . . . . . . . . . 18 6.3. Interactions with Local Config . . . . . . . . . . . . . 18
6.4. Routing Components and Associated I2RS Services . . . . . 18 6.4. Routing Components and Associated I2RS Services . . . . . 19
6.4.1. Routing and Label Information Bases . . . . . . . . . 19 6.4.1. Routing and Label Information Bases . . . . . . . . . 20
6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 20 6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 21
6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 20 6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 21
6.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 21 6.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 22
6.4.5. Information Modeling, Device Variation, and 6.4.5. Information Modeling, Device Variation, and
Information Relationships . . . . . . . . . . . . . . 21 Information Relationships . . . . . . . . . . . . . . 22
6.4.5.1. Managing Variation: Object Classes/Types and 6.4.5.1. Managing Variation: Object Classes/Types and
Inheritance . . . . . . . . . . . . . . . . . . . 21 Inheritance . . . . . . . . . . . . . . . . . . . 22
6.4.5.2. Managing Variation: Optionality . . . . . . . . . 22 6.4.5.2. Managing Variation: Optionality . . . . . . . . . 23
6.4.5.3. Managing Variation: Templating . . . . . . . . . 22 6.4.5.3. Managing Variation: Templating . . . . . . . . . 23
6.4.5.4. Object Relationships . . . . . . . . . . . . . . 23 6.4.5.4. Object Relationships . . . . . . . . . . . . . . 24
6.4.5.4.1. Initialization . . . . . . . . . . . . . . . 23 6.4.5.4.1. Initialization . . . . . . . . . . . . . . . 24
6.4.5.4.2. Correlation Identification . . . . . . . . . 23 6.4.5.4.2. Correlation Identification . . . . . . . . . 24
6.4.5.4.3. Object References . . . . . . . . . . . . . . 24 6.4.5.4.3. Object References . . . . . . . . . . . . . . 25
6.4.5.4.4. Active Reference . . . . . . . . . . . . . . 24 6.4.5.4.4. Active Reference . . . . . . . . . . . . . . 25
7. I2RS Client Agent Interface . . . . . . . . . . . . . . . . . 24 7. I2RS Client Agent Interface . . . . . . . . . . . . . . . . . 25
7.1. One Control and Data Exchange Protocol . . . . . . . . . 24 7.1. One Control and Data Exchange Protocol . . . . . . . . . 25
7.2. Communication Channels . . . . . . . . . . . . . . . . . 24 7.2. Communication Channels . . . . . . . . . . . . . . . . . 25
7.3. Capability Negotiation . . . . . . . . . . . . . . . . . 25 7.3. Capability Negotiation . . . . . . . . . . . . . . . . . 26
7.4. Identity and Security Role . . . . . . . . . . . . . . . 25 7.4. Scope Policy Specifications . . . . . . . . . . . . . . . 26
7.4.1. Client Redundancy . . . . . . . . . . . . . . . . . . 26 7.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 27
7.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 26
7.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 27 7.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 27
7.7. Information collection . . . . . . . . . . . . . . . . . 27 7.7. Information collection . . . . . . . . . . . . . . . . . 28
7.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 28 7.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 28
7.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 28 7.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 29
8. Operational and Manageability Considerations . . . . . . . . 29 8. Operational and Manageability Considerations . . . . . . . . 29
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
11. Informative References . . . . . . . . . . . . . . . . . . . 30 11. Informative References . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
Routers that form the internet routing infrastructure maintain state Routers that form the internet routing infrastructure maintain state
at various layers of detail and function. For example, a typical at various layers of detail and function. For example, a typical
router maintains a Routing Information Base (RIB), and implements router maintains a Routing Information Base (RIB), and implements
routing protocols such as OSPF, ISIS, and BGP to exchange protocol routing protocols such as OSPF, ISIS, and BGP to exchange
state and other information about the state of the network with other reachability information, topology information, protocol state, and
routers. other information about the state of the network with other routers.
Routers convert all of this information into forwarding entries which Routers convert all of this information into forwarding entries which
are then used to forward packets and flows between network elements. are then used to forward packets and flows between network elements.
The forwarding plane and the specified forwarding entries then The forwarding plane and the specified forwarding entries then
contain active state information that describes the expected and contain active state information that describes the expected and
observed operational behavior of the router and which is also needed observed operational behavior of the router and which is also needed
by the network applications. Network-oriented applications require by the network applications. Network-oriented applications require
easy access to this information to learn the network topology, to easy access to this information to learn the network topology, to
verify that programmed state is installed in the forwarding plane, to verify that programmed state is installed in the forwarding plane, to
measure the behavior of various flows, routes or forwarding entries, measure the behavior of various flows, routes or forwarding entries,
skipping to change at page 4, line 7 skipping to change at page 4, line 7
state (for example, a Routing Element RIB manager's state), as well state (for example, a Routing Element RIB manager's state), as well
as enabling network-oriented applications to be built on top of as enabling network-oriented applications to be built on top of
today's routed networks. The I2RS is a programmatic asynchronous today's routed networks. The I2RS is a programmatic asynchronous
interface for transferring state into and out of the internet routing interface for transferring state into and out of the internet routing
system. This I2RS architecture recognizes that the routing system system. This I2RS architecture recognizes that the routing system
and a router's OS provide useful mechanisms that applications could and a router's OS provide useful mechanisms that applications could
harness to accomplish application-level goals. harness to accomplish application-level goals.
Fundamental to the I2RS are clear data models that define the Fundamental to the I2RS are clear data models that define the
semantics of the information that can be written and read. The I2RS semantics of the information that can be written and read. The I2RS
provides a framework for registering for and requesting the provides a framework for registering and for requesting the
appropriate information for each particular application. The I2RS appropriate information for each particular application. The I2RS
provides a way for applications to customize network behavior while provides a way for applications to customize network behavior while
leveraging the existing routing system as desired. leveraging the existing routing system as desired.
Although the I2RS architecture is general enough to support Although the I2RS architecture is general enough to support
information and data models for a variety of data, and aspects of the information and data models for a variety of data, and aspects of the
I2RS solution may be useful in domain other than routing, I2RS and I2RS solution may be useful in domains other than routing, I2RS and
this document are specifically focused on an interface for routing this document are specifically focused on an interface for routing
data. data.
1.1. Drivers for the I2RS Architecture 1.1. Drivers for the I2RS Architecture
There are four key drivers that shape the I2RS architecture. First There are four key drivers that shape the I2RS architecture. First
is the need for an interface that is programmatic, asynchronous, and is the need for an interface that is programmatic, asynchronous, and
offers fast, interactive access for atomic operations. Second is the offers fast, interactive access for atomic operations. Second is the
access to structured information and state that is frequently not access to structured information and state that is frequently not
directly configurable or modeled in existing implementations or directly configurable or modeled in existing implementations or
skipping to change at page 10, line 14 skipping to change at page 10, line 14
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 may be constrained based upon the context of a particular agent may be constrained based upon the
client's security role. An example of such a resource could client's security role. An example of such a resource could
include the number of notifications registered for. These are not include the number of notifications registered for. These are not
protocol-specific resources or network-specific resources. protocol-specific resources or network-specific resources.
role or security role: A security role specifies the scope, role or security role: A security role specifies the scope,
resources, priorities, etc. that a client or agent has. resources, priorities, etc. that a client or agent has. Multiple
identities may use the same security role.
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 secondary identity: An I2RS Client may supply a secondary opaque
identity that is not interpreted by the I2RS Agent. An example identity that is not interpreted by the I2RS Agent. An example
use is when the I2RS Client is a go-between for multiple use is when the I2RS Client is a go-between for multiple
applications and it is necessary to track which application has applications and it is necessary to track which application has
requested a particular operation. requested a particular operation.
Groups: NETCONF Network Access [RFC6536] refers uses the term group
in terms of an Administrative group which supports support the
well-established distinction between a root account and other
types of less-privileged conceptual user accounts. Group still
refers to a single identity (e.g. root) which is shared by a group
of users.
3. Key Architectural Properties 3. Key Architectural Properties
Several key architectural properties for the I2RS protocol are Several key architectural properties for the I2RS protocol are
elucidated below (simplicity, extensibility, and model-driven elucidated below (simplicity, extensibility, and model-driven
programmatic interfaces). However, some architecture principles such programmatic interfaces). However, some architecture principles such
as performance and scaling are not described below because they are as performance and scaling are not described below because they are
discussed in [I-D.ietf-i2rs-problem-statement] and because the discussed in [I-D.ietf-i2rs-problem-statement] and because the
performance and scaling requires varies based on the particular use- performance and scaling requires varies based on the particular use-
cases. cases.
skipping to change at page 13, line 4 skipping to change at page 13, line 12
authentication and authorization for that communication is out of authentication and authorization for that communication is out of
scope; nothing prevents I2RS and a separate authentication and scope; nothing prevents I2RS and a separate authentication and
authorization channel from being used. Regardless of mechanism, an authorization channel from being used. Regardless of mechanism, an
I2RS Client that is acting as a broker is responsible for determining I2RS Client that is acting as a broker is responsible for determining
that applications using it are trusted and permitted to make the that applications using it are trusted and permitted to make the
particular requests. particular requests.
Different levels of integrity, confidentiality, and replay protection Different levels of integrity, confidentiality, and replay protection
are relevant for different aspects of I2RS. The primary are relevant for different aspects of I2RS. The primary
communication channel that is used for client authentication and then communication channel that is used for client authentication and then
used by the client to write data requires integrity, privacy and used by the client to write data requires integrity, confidentiality
replay protection. Appropriate selection of a default required and replay protection. Appropriate selection of a default required
transport protocol is the preferred way of meeting these transport protocol is the preferred way of meeting these
requirements. requirements.
Other communications via I2RS may not require integrity, Other communications via I2RS may not require integrity,
confidentiality, and replay protection. For instance, if an I2RS confidentiality, and replay protection. For instance, if an I2RS
Client subscribes to an information stream of prefix announcements Client subscribes to an information stream of prefix announcements
from OSPF, those may require integrity but probably not from OSPF, those may require integrity but probably not
confidentiality or replay protection. Similarly, an information confidentiality or replay protection. Similarly, an information
stream of interface statistics may not even require guaranteed stream of interface statistics may not even require guaranteed
delivery. In Section 7.2, more reasoning for multiple communication delivery. In Section 7.2, more reasoning for multiple communication
skipping to change at page 13, line 40 skipping to change at page 13, line 48
of the system must be accurately attributable. In an ideal of the system must be accurately attributable. In an ideal
architecture, even information collection and notification should be architecture, even information collection and notification should be
protected; this may be subject to engineering tradeoffs during the protected; this may be subject to engineering tradeoffs during the
design. design.
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 needed for authentication or those applications' identities are not needed for authentication or
authorization, each application should have a unique opaque authorization, each application should have a unique opaque
identifier that can be provided by the I2RS client to the I2RS agent identifier that can be provided by the I2RS client to the I2RS agent
for purposes of tracking attribution of operations to support for purposes of tracking attribution of operations to support
functionality such as accounting and troubleshooting. functionality such as troubleshooting and logging of network changes.
4.2. Authorization 4.2. Authorization
All operations using I2RS, both observation and manipulation, should All operations using I2RS, both observation and manipulation, should
be subject to appropriate authorization controls. Such authorization be subject to appropriate authorization controls. Such authorization
is based on the identity and assigned role of the I2RS client is based on the identity and assigned role of the I2RS client
performing the operations and the I2RS agent in the network element. performing the operations and the I2RS agent in the network element.
(Multiple Identities may use the same role).
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, each will be acting on behalf of the I2RS clients. As such, each
operation authorization will be based on the lower of the two operation authorization will be based on the lower of the two
permissions of the agent itself and of the authenticated client. The permissions of the agent itself and of the authenticated client. The
mechanism by which this authorization is applied within the device is mechanism by which this authorization is applied within the device is
outside of the scope of I2RS. outside of the scope of I2RS.
The appropriate or necessary level of granularity for scope can The appropriate or necessary level of granularity for scope can
depend upon the particular I2RS Service and the implementation's depend upon the particular I2RS Service and the implementation's
granularity. An approach to a similar access control problem is granularity. An approach to a similar access control problem is
defined in the NetConf Access Control Model[RFC6536]; it allows defined in the NetConf Access Control Model (NACM) [RFC6536]; it
arbitrary access to be specified for a data node instance identifier allows arbitrary access to be specified for a data node instance
while defining meaningful manipulable defaults. The ability to identifier while defining meaningful manipulable defaults. The
specify one or more groups or roles that a particular I2RS Client identity within NACM [RFC6536] can be specify as either a user name
belongs and then define access controls in terms of those groups or or a group user name (e.g. Root), and this name is linked a scope
roles is expected. When a client is authenticated, its group or role policy that contained in a a set of access control rules. Similarly,
membership should be provided to the I2RS Agent. The set of access it is expected the I2RS identity links to one role which has a scope
control rules that an I2RS Agent uses would need to be either policy specified by a set of access control rules. This scope policy
provided via Local Config, exposed as an I2RS Service for is can be provided via Local Config, exposed as an I2RS Service for
manipulation by authorized clients, or via some other method. manipulation by authorized clients, or via some other method (e.g.
AAA service)
When an I2RS client is authenticated, its identity is provided to the
I2RS Agent, and this identity links to a role which links to the
scope policy. Multiple identities may link to the same role (e.g
ability to read I2RS RIB).
4.3. Client Redundancy
I2RS must support client redundancy. At the simplest, this can be
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 the need for
troubleshooting and logging of network changes to be informed about
which network application is actually active. At a minimum, basic
transport information about each connection and time can be logged
with the identity.
5. Network Applications and I2RS Client 5. Network Applications and I2RS Client
I2RS is expected to be used by network-oriented applications in I2RS is expected to be used by network-oriented applications in
different architectures. While the interface between a network- different architectures. While the interface between a network-
oriented application and the I2RS client is outside the scope of oriented application and the I2RS client is outside the scope of
I2RS, considering the different architectures is important to I2RS, considering the different architectures is important to
sufficiently specify I2RS. sufficiently specify I2RS.
In the simplest architecture, a network-oriented application has an In the simplest architecture of direct access, a network-oriented
I2RS client as a library or driver for communication with routing application has an I2RS client as a library or driver for
elements. communication with routing elements.
In the broker architecture, multiple network-oriented applications In the broker architecture, multiple network-oriented applications
communicate in an unspecified fashion to a broker application that communicate in an unspecified fashion to a broker application that
contains an I2RS Client. That broker application requires additional contains an I2RS Client. That broker application requires additional
functionality for authentication and authorization of the network- functionality for authentication and authorization of the network-
oriented applications; such functionality is out of scope for I2RS oriented applications; such functionality is out of scope for I2RS
but similar considerations to those described in Section 4.2 do but similar considerations to those described in Section 4.2 do
apply. As discussed in Section 4.1, the broker I2RS Client should apply. As discussed in Section 4.1, the broker I2RS Client should
determine distinct opaque identifiers for each network-oriented determine distinct opaque identifiers for each network-oriented
application that is using it. The broker I2RS Client can pass along application that is using it. The broker I2RS Client can pass along
skipping to change at page 18, line 38 skipping to change at page 19, line 16
resolution cannot be time-based. Simply allowing the most recent resolution cannot be time-based. Simply allowing the most recent
state to prevail could cause race conditions where the final state is state to prevail could cause race conditions where the final state is
not repeatably deterministic. not repeatably deterministic.
6.4. Routing Components and Associated I2RS Services 6.4. Routing Components and Associated I2RS Services
For simplicity, each logical protocol or set of functionality that For simplicity, each logical protocol or set of functionality that
can be compactly described in a separable information and data model can be compactly described in a separable information and data model
is considered as a separate I2RS Service. A routing element need not is considered as a separate I2RS Service. A routing element need not
implement all routing components described nor provide the associated implement all routing components described nor provide the associated
I2RS services. When a full implementation is not mandatory, an I2RS I2RS services. I2RS Services should include a capability model so
Service should include a capability model so that implementations can that peers can determine which parts of the service are supported.
indicate which parts of the service are supported. Each I2RS Service Each I2RS Service requires an information model that describes at
requires an information model that describes at least the following: least the following: data that can be read, data that can be written,
data that can be read, data that can be written, notifications that notifications that can be subscribed to, and the capability model
can be subscribed to, and the capability model mentioned above. mentioned above.
The initial services included in the I2RS architecture are as The initial services included in the I2RS architecture are as
follows. follows.
*************************** ************** ***************** *************************** ************** *****************
* I2RS Protocol * * * * Dynamic * * I2RS Protocol * * * * Dynamic *
* * * Interfaces * * Data & * * * * Interfaces * * Data & *
* +--------+ +-------+ * * * * Statistics * * +--------+ +-------+ * * * * Statistics *
* | Client | | Agent | * ************** ***************** * | Client | | Agent | * ************** *****************
* +--------+ +-------+ * * +--------+ +-------+ *
skipping to change at page 22, line 30 skipping to change at page 23, line 30
Information model should provide information that: Information model should provide information that:
o Is X required for the data field to be accepted and applied? o Is X required for the data field to be accepted and applied?
o If X is optional, then how does "X" as an optional portion of data o If X is optional, then how does "X" as an optional portion of data
field interact with the required aspects of the data field? field interact with the required aspects of the data field?
o Does the data field have defaults for the mandatory portion of the o Does the data field have defaults for the mandatory portion of the
field and the optional portions of the field field and the optional portions of the field
o Is X required to be within a particular set of values (E.g. range, o Is X required to be within a particular set of values (e.g. range,
length of strings)? length of strings)?
The information model needs to be clear about what read or write The information model needs to be clear about what read or write
values are set by client and what responses or actions are required values are set by client and what responses or actions are required
by the agent. It is important to indicate what is required or by the agent. It is important to indicate what is required or
optional in client values and agent responses/actions. optional in client values and agent responses/actions.
6.4.5.3. Managing Variation: Templating 6.4.5.3. Managing Variation: Templating
A template is a collection of information to address a problem; it A template is a collection of information to address a problem; it
skipping to change at page 25, line 38 skipping to change at page 26, line 38
The protocol capability negotiation can be segmented into the basic The protocol capability negotiation can be segmented into the basic
version negotiation (required to ensure basic communication), and the version negotiation (required to ensure basic communication), and the
more complex capability exchange which can take place within the base more complex capability exchange which can take place within the base
protocol mechanisms. In particular, the more complex protocol and protocol mechanisms. In particular, the more complex protocol and
mechanism negotiation can be addressed by defining information models mechanism negotiation can be addressed by defining information models
for both the I2RS Agent and the I2RS Client. These information for both the I2RS Agent and the I2RS Client. These information
models can describe the various capability options. This can then models can describe the various capability options. This can then
represent and be used to communicate important information about the represent and be used to communicate important information about the
agent, and the capabilities thereof. agent, and the capabilities thereof.
7.4. Identity and Security Role 7.4. Scope Policy Specifications
Each I2RS Client will have a unique identity; it can also have
secondary identities to be used for troubleshooting. A secondary
identity is merely a unique, opaque identifier that may be helpful in
troubleshooting. Via authentication and authorization mechanisms
based on the primary unique identity, the I2RS Client will have a
specific scope for reading data, for writing data, and limitations on
the resources that can be consumed. The scopes need to specify both
the data and the value ranges.
7.4.1. Client Redundancy
I2RS must support client redundancy. At the simplest, this can be As section 4.1 and 4.2 describe, each I2RS Client will have a unique
handled by having a primary and a backup network application that identity and it may have a secondary identity (see section 2) to aid
both use the same client identity and can successfully authenticate in troubleshooting. As section 4 indicates, all authentication and
as such. Since I2RS does not require a continuous transport authorization mechanisms are based on the primary Identity which
connection and supports multiple transport sessions, this can provide links to a role with scope policy for for reading data, for writing
some basic redundancy. However, it does not address concerns for data, and limitations on the resources that can be consumed.
troubleshooting and accountability about knowing which network Specifications for scope policy need to specify the data and value
application is actually active. At a minimum, basic transport ranges for portion of scope policy.
information about each connection and time can be logged with the
identity.
7.5. Connectivity 7.5. Connectivity
A client may or may not maintain an active communication channel with A client may or may not maintain an active communication channel with
an agent. Therefore, an agent may need to open a communication an agent. Therefore, an agent may need to open a communication
channel to the client to communicate previously requested channel to the client to communicate previously requested
information. The lack of an active communication channel does not information. The lack of an active communication channel does not
imply that the associated client is non-functional. When imply that the associated client is non-functional. When
communication is required, the agent or client can open a new communication is required, the agent or client can open a new
communication channel. communication channel.
skipping to change at page 27, line 32 skipping to change at page 28, line 16
specific types of events and filtering operations can vary by specific types of events and filtering operations can vary by
information model and need to be specified as part of the information information model and need to be specified as part of the information
model. model.
The I2RS information model needs to include representation of these The I2RS information model needs to include representation of these
events. As discussed earlier, the capability information in the events. As discussed earlier, the capability information in the
model will allow I2RS clients to understand which events a given I2RS model will allow I2RS clients to understand which events a given I2RS
Agent is capable of generating. Agent is capable of generating.
For performance and scaling by the I2RS client and general For performance and scaling by the I2RS client and general
information privacy, an I2RS Client needs to be able to register for information confidentiality, an I2RS Client needs to be able to
just the events it is interested in. It is also possible that I2RS register for just the events it is interested in. It is also
might might provide a stream of notifications via a publish/subscribe possible that I2RS might provide a stream of notifications via a
mechanism that is not amenable to having the I2RS agent do the publish/subscribe mechanism that is not amenable to having the I2RS
filtering. agent do the filtering.
7.7. Information collection 7.7. Information collection
One of the other important aspects of the I2RS is that it is intended One of the other important aspects of the I2RS is that it is intended
to simplify collecting information about the state of network to simplify collecting information about the state of network
elements. This includes both getting a snapshot of a large amount of elements. This includes both getting a snapshot of a large amount of
data about the current state of the network element, and subscribing data about the current state of the network element, and subscribing
to a feed of the ongoing changes to the set of data or a subset to a feed of the ongoing changes to the set of data or a subset
thereof. This is considered architecturally separate from thereof. This is considered architecturally separate from
notifications due to the differences in information rate and total notifications due to the differences in information rate and total
 End of changes. 32 change blocks. 
95 lines changed or deleted 110 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/