******************   *****************  *****************
    *  Application C *   * Application D *  * Application E *
    ******************   *****************  *****************
             ^                  ^                   ^
             |                  |                   |  
             |--------------|   |    |--------------|
                            |   |    |
                            v   v    v           
                          ***************
                          *  Client P   *
                          ***************
                               ^     ^
                               |     |-------------------------|
     ***********************   |      ***********************  |       
     *    Application A    *   |      *    Application B    *  |        
     *                     *   |      *                     *  |        
     *  +----------------+ *   |      *  +----------------+ *  |        
     *  |   Client A     | *   |      *  |   Client B     | *  |        
     *  +----------------+ *   |      *  +----------------+ *  |        
     ******* ^ *************   |      ***** ^ ****** ^ ******  |
             |                 |            |        |         |
             |   |-------------|            |        |   |-----|
             |   |   -----------------------|        |   |
             |   |   |                               |   |
************ v * v * v *********   ***************** v * v ********
*  +---------------------+     *   *  +---------------------+     *
*  |     Agent 1         |     *   *  |    Agent 2          |     *
*  +---------------------+     *   *  +---------------------+     *
*     ^        ^  ^   ^        *   *     ^        ^  ^   ^        *  
*     |        |  |   |        *   *     |        |  |   |        *  
*     v        |  |   v        *   *     v        |  |   v        *   
* +---------+  |  | +--------+ *   * +---------+  |  | +--------+ *   
* | Routing |  |  | | Local  | *   * | Routing |  |  | | Local  | *   
* |   and   |  |  | | Config | *   * |   and   |  |  | | Config | *  
* |Signaling|  |  | +--------+ *   * |Signaling|  |  | +--------+ *  
* +---------+  |  |         ^  *   * +---------+  |  |         ^  *  
*    ^         |  |         |  *   *    ^         |  |         |  *  
*    |    |----|  |         |  *   *    |    |----|  |         |  *  
*    v    |       v         v  *   *    v    |       v         v  *  
*  +----------+ +------------+ *   *  +----------+ +------------+ *  
*  |  Dynamic | |   Static   | *   *  |  Dynamic | |   Static   | *  
*  |  System  | |   System   | *   *  |  System  | |   System   | *  
*  |  State   | |   State    | *   *  |  State   | |   State    | *  
*  +----------+ +------------+ *   *  +----------+ +------------+ *  
*                              *   *                              *
*  Routing Element 1           *   *  Routing Element 2           *
********************************   ********************************

Figure 1: Architecture of I2RS clients and agents

Routing Element:

A Routing Element implements some subset of the routing system. It does not need to have a forwarding plane associated with it. Examples of Routing Elements can include:

• A router with a forwarding plane and RIB Manager that runs IS-IS, OSPF, BGP, PIM, etc.,
• A BGP speaker acting as a Route Reflector,
• An LSR that implements RSVP-TE, OSPF-TE, and PCEP and has a forwarding plane and associated RIB Manager,
• A server that runs IS-IS, OSPF, BGP and uses ForCES to control a remote forwarding plane,

A Routing Element may be locally managed, whether via CLI, SNMP, or NETCONF.

Routing and Signaling:

This block represents that portion of the Routing Element that implements part of the internet routing system. It includes not merely standardized protocols (i.e. IS-IS, OSPF, BGP, PIM, RSVP-TE, LDP, etc.), but also the RIB Manager layer.

Local Configuration:

is the black box behavior for interactions between the ephemeral state that I2RS installs into the routing element; and this Local Configuration is defined by this document and the behaviors specified by the I2RS protocol.

Dynamic System State:

An I2RS agent needs access to state on a routing element beyond what is contained in the routing subsystem. Such state may include various counters, statistics, flow data, and local events. This is the subset of operational state that is needed by network applications based on I2RS that is not contained in the routing and signaling information. How this information is provided to the I2RS agent is out of scope, but the standardized information and data models for what is exposed are part of I2RS.

Static System State:

An I2RS agent needs access to static state on a routing element beyond what is contained in the routing subsystem. An example of such state is specifying queueing behavior for an interface or traffic. How the I2RS agent modifies or obtains this information is out of scope, but the standardized information and data models for what is exposed are part of I2RS.

I2RS Agent:

See the definition in Section 2.

Application:

A network application that needs to observe the network or manipulate the network to achieve its service requirements.

I2RS Client:

See the definition in Section 2.

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 agents based upon its needs. Similarly, an I2RS agent may communicate with multiple I2RS clients - whether to respond to their requests, to send notifications, etc. Timely notifications are critical so that several simultaneously operating applications have up-to-date information on the state of the network.

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 operations. In order to keep the protocol simple, two clients should not attempt to write (modify) the same piece of information on an I2RS Agent. This is considered an error. However, such collisions may happen and section 7.8 (multi-headed control) describes how the I2RS agent resolves collision by first utilizing priority to resolve collisions, and second by servicing the requests in a first in, first served basis. The i2rs architecture includes this definition of behavior for this case simply for predictability not because this is an intended result. This predictability will simplify the error handling and suppress oscillations. If additional error cases beyond this simple treatment are required, these error cases should be resolved by the network applications and management systems.

In contrast, although multiple I2RS clients may need to supply data into the same list (e.g. a prefix or filter list), this is not considered an error and 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 produce predictable behaviors, and be reportable to interested clients. The details of the associated policy is discussed in Section 7.8. The same policy mechanism (simple priority per I2RS client) applies to interactions between the I2RS agent and the CLI/SNMP/NETCONF as described in Section 6.3.

In addition it must be noted that there may be indirect interactions between write operations. A basic example of this is when two different but overlapping prefixes are written with different forwarding behavior. Detection and avoidance of such interactions is outside the scope of the I2RS work and is left to agent design and implementation.

2. Terminology

The following terminology is used in this document.

agent or I2RS Agent:

An I2RS agent provides the supported I2RS services from the local system's routing sub-systems by interacting with the routing element to provide specified behavior. The I2RS agent understands the I2RS protocol and can be contacted by I2RS clients.

client or I2RS Client:

A client implements the I2RS protocol, uses it to communicate with I2RS Agents, and uses the I2RS services to accomplish a task. It interacts with other elements of the policy, provisioning, and configuration system by means outside of the scope of the I2RS effort. It interacts with the I2RS agents to collect information from the routing and forwarding system. Based on the information and the policy oriented interactions, the I2RS client may also interact with I2RS agents to modify the state of their associated routing systems to achieve operational goals. An I2RS client can be seen as the part of an application that uses and supports I2RS and could be a software library.

service or I2RS Service:

For the purposes of I2RS, a service refers to a set of related state access functions together with the policies that control their usage. The expectation is that a service will be represented by a data-model. For instance, 'RIB service' could be an example of a service that gives access to state held in a device's RIB.

read scope:

The read scope of an I2RS client within an I2RS agent is the set of information which the I2RS client is authorized to read within the I2RS agent. The read scope specifies the access restrictions to both see the existence of data and read the value of that data.

notification scope:

The set of events and associated information that the I2RS Client can request be pushed by the I2RS Agent. I2RS Clients have the ability to register for specific events and information streams, but must be constrained by the access restrictions associated with their notification scope.

write scope:

The set of field values which the I2RS client is authorized to write (i.e. add, modify or delete). This access can restrict what data can be modified or created, and what specific value sets and ranges can be installed.

scope:

When unspecified as either read scope, write scope, or notification scope, the term scope applies to the read scope, write scope, and notification scope.

resources:

A resource is an I2RS-specific use of memory, storage, 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 context of a particular agent may be constrained based upon the client's security role. An example of such a resource could include the number of notifications registered for. These are not protocol-specific resources or network-specific resources.

role or security role:

A security role specifies the scope, resources, priorities, etc. that a client or agent has. If a identity has multiple roles in the security system, the identity is permitted to perform any operations any of those roles permit. Multiple identities may use the same security role.

identity:

A client is associated with exactly one specific identity. State can be attributed to a particular identity. It is possible for multiple communication channels to use the same identity; in that case, the assumption is that the associated client is coordinating such communication.

Identity and scope:

A single identity can be associated with multiple roles. Each role has its own scope and an identity associated with multiple roles can use the combined scope of all its roles. More formally, each identity has:

a read-scope that is the logical OR of the read-scopes associated with its roles,

a write-scope that is the logical OR of the write-scopes associated with its roles, and

a notification-scope that is the logical OR of the notification-scopes associated with its roles.

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.

Groups:

NETCONF Network Access [RFC6536] uses the term group in terms of an Administrative group which supports 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

Several key architectural properties for the I2RS protocol are elucidated below (simplicity, extensibility, and model-driven programmatic interfaces). However, some architecture properties such as performance and scaling are not described below because they are discussed in [I-D.ietf-i2rs-problem-statement], may may vary based on the particular use-cases.

3.1. Simplicity

There have been many efforts over the years to improve the access to the information available to the routing and forwarding system. Making such information visible and usable to network management and applications has many well-understood benefits. There are two related challenges in doing so. First, the quantity and diversity of information potentially available is very large. Second, the variation both in the structure of the data and in the kinds of operations required tends to introduce protocol complexity.

While the types of operations contemplated here are complex in their nature, it is critical that I2RS be easily deployable and robust. Adding complexity beyond what is needed to satisfy well known and understood requirements would hinder the ease of implementation, the robustness of the protocol, and the deployability of the protocol. Overly complex data models tend to ossify information sets by attempting to describe and close off every possible option, complicating extensibility.

Thus, one of the key aims for I2RS is the keep the protocol and modeling architecture simple. So for each architectural component or aspect, we ask ourselves "do we need this complexity, or is the behavior merely nice to have?" Protocol parsimony is clearly a goal.

3.2. Extensibility

Extensibility of the protocol and data model is very important. In particular, given the necessary scope limitations of the initial work, it is critical that the initial design include strong support for extensibility.

The scope of the I2RS work is being restricted in the interests of achieving a deliverable and deployable result. The I2RS Working Group is modeling only a subset of the data of interest. It is clearly desirable for the data models defined in the I2RS to be useful in more general settings. It should be easy to integrate data models from the I2RS with other data. Other work should be able to easily extend it to represent additional aspects of the network elements or network systems. This reinforces the criticality of designing the data models to be highly extensible, preferably in a regular and simple fashion.

The I2RS Working Group is defining operations for the I2RS protocol. It would be optimistic to assume that more and different ones may not be needed when the scope of I2RS increases. Thus, it is important to consider extensibility not only of the underlying services' data models, but also of the primitives and protocol operations.

3.3. Model-Driven Programmatic Interfaces

A critical component of I2RS is the standard information and data models with their associated semantics. While many components of the routing system are standardized, associated data models for them are not yet available. Instead, each router uses different information, different mechanisms, and different CLI which makes a standard interface for use by applications extremely cumbersome to develop and maintain. Well-known data modeling languages exist and may be used for defining the data models for I2RS.

There are several key benefits for I2RS in using model-driven architecture and protocol(s). First, it allows for transferring data-models whose content is not explicitly implemented or understood. Second, tools can automate checking and manipulating data; this is particularly valuable for both extensibility and for the ability to easily manipulate and check proprietary data-models.

The different services provided by I2RS can correspond to separate data-models. An I2RS agent may indicate which data-models are supported.

The purpose of the data model is to provide an definition of the information regarding the routing system that can be used in operational networks. If routing information is being modeled for the first time, a logical information model may be standardized prior to creating the data model.

4. Security Considerations

This I2RS architecture describes interfaces that clearly require serious consideration of security. As an architecture, I2RS has been designed to re-utilize existing protocols that carry network management information. Two of the existing protocols which the which may be re-used are NETCONF [RFC6241] and RESTCONF [I-D.ietf-netconf-restconf]. The I2RS protocol design process will be to specify additional requirements including security for these existing protocol in order to support the I2RS architecture. After an existing protocol, (e.g. NETCONF or RESTCONF) has been altered to fit the I2RS requirements, then it will be reviewed to determine if it meets the I2RS security requirements.

Due to the re-use strategy of the I2RS architecture, this security section describes the assumed security environment for I2RS with additional details on: a) identity and authentication, b) authorization, and c) client redundancy. Each protocol proposed for inclusion as an I2RS protocol will need to be evaluated for the security constraints of the protocol. The detailed requirements for the I2RS protocol and the I2RS security environment will be defined within these global security environments.

First, here is a brief description of the assumed security environment for I2RS. The I2RS Agent associated with a Routing Element is a trusted part of that Routing Element. For example, it may be part of a vendor-distributed signed software image for the entire Routing Element or it may be trusted signed application that an operator has installed. The I2RS Agent is assumed to have a separate authentication and authorization channel by which it can validate both the identity and permissions associated with an I2RS Client. To support numerous and speedy interactions between the I2RS Agent and I2RS Client, it is assumed that the I2RS Agent can also cache that particular I2RS Clients are trusted and their associated authorized scope. This implies that the permission information may be old either in a pull model until the I2RS Agent re-requests it, or in a push model until the authentication and authorization channel can notify the I2RS Agent of changes.

Mutual authentication between the I2RS Client and I2RS Agent is required. An I2RS Client must be able to trust that the I2RS Agent is attached to the relevant Routing Element so that write/modify operations are correctly applied and so that information received from the I2RS Agent can be trusted by the I2RS Client.

An I2RS Client is not automatically trustworthy. Each I2RS Client is associated with identity with a set of scope limitations. Applications using the I2RSS should be aware of the scope limitations of that I2RS Client. If the I2RS Client is acting as a broker for multiple applications, then managing the security, authentication and authorization for that communication is out of scope; nothing prevents the broker from using I2RS protocol and a separate authentication and authorization channel from being used. Regardless of mechanism, an I2RS Client that is acting as a broker is responsible for determining that applications using it are trusted and permitted to make the particular requests.

Different levels of integrity, confidentiality, and replay protection are relevant for different aspects of I2RS. The primary communication channel that is used for client authentication and then used by the client to write data requires integrity, confidentiality and replay protection. Appropriate selection of a default required transport protocol is the preferred way of meeting these requirements.

Other communications via I2RS may not require integrity, confidentiality, and replay protection. For instance, if an I2RS Client subscribes to an information stream of prefix announcements from OSPF, those may require integrity but probably not confidentiality or replay protection. Similarly, an information stream of interface statistics may not even require guaranteed delivery. In Section 7.2, additional login regarding multiple communication channels and their use is provided. From the security perspective, it is critical to realize that an I2RS Agent may open a new communication channel based upon information provided by an I2RS Client (as described in Section 7.2). For example, an I2RS client may request notifications of certain events and the agent will open a communication channel to report such events. Therefore, to avoid an indirect attack, such a request must be done in the context of an authenticated and authorized client whose communications cannot have been altered.

4.1. Identity and Authentication

As discussed above, all control exchanges between the I2RS client and agent should be authenticated and integrity protected (such that the contents cannot be changed without detection). Further, manipulation of the system must be accurately attributable. In an ideal architecture, even information collection and notification should be protected; this may be subject to engineering tradeoffs during the design.

I2RS clients may be operating on behalf of other applications. While those applications' identities are not needed for authentication or authorization, each application should have a unique opaque identifier that can be provided by the I2RS client to the I2RS agent for purposes of tracking attribution of operations to support functionality such as troubleshooting and logging of network changes.

4.2. Authorization

All operations using I2RS, both observation and manipulation, should be subject to appropriate authorization controls. Such authorization is based on the identity and assigned role of the I2RS client performing the operations and the I2RS agent in the network element. Multiple Identities may use the same role(s). As noted in the definition of the identity and role above, if multiple roles are associated with an identity then the identity is authorized to perform any operation authorized by any of its roles.

I2RS Agents, in performing information collection and manipulation, will be acting on behalf of the I2RS clients. As such, each operation authorization will be based on the lower of the two permissions of the agent itself and of the authenticated client. The mechanism by which this authorization is applied within the device is outside of the scope of I2RS.

The appropriate or necessary level of granularity for scope can depend upon the particular I2RS Service and the implementation's granularity. An approach to a similar access control problem is defined in the NetConf Access Control Model (NACM) [RFC6536]; it allows arbitrary access to be specified for a data node instance identifier while defining meaningful manipulable defaults. The identity within NACM [RFC6536] can be specify as either a user name or a group user name (e.g. Root), and this name is linked a scope policy that is contained in a set of access control rules. Similarly, it is expected the I2RS identity links to one role which has a scope policy specified by a set of access control rules. This scope policy can be provided via Local Configuration, exposed as an I2RS Service for 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 belong to the same role; for example, such a role might be an Internal-Routes-Monitor that allows reading of the portion of the I2RS RIB associated with IP prefixes used for internal device addresses in the AS."

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

I2RS is expected to be used by network-oriented applications in different architectures. While the interface between a network-oriented application and the I2RS client is outside the scope of I2RS, considering the different architectures is important to sufficiently specify I2RS.

In the simplest architecture of direct access, a network-oriented application has an I2RS client as a library or driver for communication with routing elements.

In the broker architecture, multiple network-oriented applications communicate in an unspecified fashion to a broker application that contains an I2RS Client. That broker application requires additional functionality for authentication and authorization of the network-oriented applications; such functionality is out of scope for I2RS but similar considerations to those described in Section 4.2 do apply. As discussed in Section 4.1, the broker I2RS Client should determine distinct opaque identifiers for each network-oriented application that is using it. The broker I2RS Client can pass along the appropriate value as a secondary identifier which can be used for tracking attribution of operations.

In a third architecture, a routing element or network-oriented application that uses an I2RS Client to access services on a different routing element may also contain an I2RS agent to provide services to other network-oriented applications. However, where the needed information and data models for those services differs from that of a conventional routing element, those models are, at least initially, out of scope for I2RS. Below is an example of such a network application

5.1. Example Network Application: 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, such as interface and label-switched path (LSP) information. In addition, the Topology Manager may collect link-state data in several ways - either via I2RS models, by peering with BGP-LS[I-D.ietf-idr-ls-distribution] or listening into the IGP.

The set of functionality and collected information that is the Topology Manager may be embedded as a component of a larger application, such as a path computation application. As a stand-alone application, the Topology Manager could be useful to other network applications by providing a coherent picture of the network state accessible via another interface. That interface might use the same I2RS protocol and could provide a topology service using extensions to the I2RS data models.

6. I2RS Agent Role and Functionality

The I2RS Agent is part of a routing element. As such, it has relationships with that routing element as a whole, and with various components of that routing element.

6.1. Relationship to its Routing Element

A Routing Element may be implemented with a wide variety of different architectures: an integrated router, a split architecture, distributed architecture, etc. The architecture does not need to affect the general I2RS agent behavior.

For scalability and generality, the I2RS agent may be responsible for collecting and delivering large amounts of data from various parts of the routing element. Those parts may or may not actually be part of a single physical device. Thus, for scalability and robustness, it is important that the architecture allow for a distributed set of reporting components providing collected data from the I2RS agent back to the relevant I2RS clients. There may be multiple I2RS Agents within the same router. In such a case, they must have non-overlapping sets of information which they manipulate.

To facilitate operations, deployment and troubleshooting, it is important that traceability of the requests received by I2RS Agent's and actions taken be supported via a common data model.

6.2. I2RS State Storage

State modification requests are sent to the I2RS agent in a routing element by I2RS clients. The I2RS agent is responsible for applying these changes to the system, subject to the authorization discussed above. The I2RS agent will retain knowledge of the changes it has applied, and the client on whose behalf it applied the changes. The I2RS agent will also store active subscriptions. These sets of data form the I2RS data store. This data is retained by the agent until the state is removed by the client, overridden by some other operation such as CLI, or the device reboots. Meaningful logging of the application and removal of changes is recommended. I2RS applied changes to the routing element state will not be retained across routing element reboot. The I2RS data store is not preserved across routing element reboots; thus the I2RS agent will not attempt to reapply such changes after a reboot.

6.2.1. I2RS Agent Failure

It is expected that an I2RS Agent may fail independently of the associated routing element. This could happen because I2RS is disabled on the routing element or because the I2RS Agent, a separate process or even running on a separate processor, experiences an unexpected failure. Just as routing state learned from a failed source is removed, the ephemeral I2RS state will usually be removed shortly after the failure is detected or as part of a graceful shutdown process. To handle I2RS Agent failure, the I2RS Agent must use two different notifications.

NOTIFICATION_I2RS_AGENT_STARTING:

This notification identifies that the associated I2RS Agent has started. It includes an agent-boot-count that indicates how many times the I2RS Agent has restarted since the associated routing element restarted. The agent-boot-count allows an I2RS Client to determine if the I2RS Agent has restarted.

NOTIFICATION_I2RS_AGENT_TERMINATING:

This notification reports that the associated I2RS Agent is shutting down gracefully. Ephemeral state will be removed. It can optionally include a timestamp indicating when the I2RS Agent will shutdown. Use of this timestamp assumes that time synchronization has been done and the timestamp should not have granularity finer than one second because better accuracy of shutdown time is not guaranteed.

There are two different failure types that are possible and each has different behavior.

Unexpected failure:

In this case, the I2RS Agent has unexpectedly crashed and thus cannot notify its clients of anything. Since I2RS does not require a persistent connection between the I2RS Client and I2RS Agent, it is necessary to have a mechanism for the I2RS Agent to notify I2RS Clients that had subscriptions or written ephemeral state; such I2RS Clients should be cached by the I2RS Agent's system in persistent storage. When the I2RS Agent starts, it should send a NOTIFICATION_I2RS_AGENT_STARTING to each cached I2RS Client.

Graceful failure:

In this case, the I2RS Agent can do specific limited work as part of the process of being disabled. The I2RS Agent must send a NOTIFICATION_I2RS_AGENT_TERMINATING to all its cached I2RS Clients.

6.2.2. Starting and Ending

When an I2RS client applies changes via the I2RS protocol, those changes are applied and left until removed or the routing element reboots. The network application may make decisions about what to request via I2RS based upon a variety of conditions that imply different start times and stop times. That complexity is managed by the network application and is not handled by I2RS.

6.2.3. Reversion

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. In all such cases, the state will revert to what it would have been without the I2RS client-agent interaction; that state is generally whatever was specified via the CLI, NETCONF, SNMP, etc. I2RS Agents will not store multiple alternative states, nor try to determine which one among such a plurality it should fall back to. Thus, the model followed is not like the RIB, where multiple routes are stored at different preferences. (For I2RS state in the presence of two I2RS clients, please see section 1.2 and section 7.8)

An I2RS Client may register for notifications, subject to its notification scope, regarding state modification or removal by a particular I2RS Client.

6.3. Interactions with Local Configuration

Changes may originate from either Local Configuration or from I2RS. The modifications and data stored by I2RS are separate from the local device configuration, but conflicts between the two must be resolved in a deterministic manner that respects operator-applied policy. That policy can determine whether Local Configuration overrides a particular I2RS client's request or vice versa. To achieve this end, either by default Local Configuration always wins or, optionally, a routing element may permit a priority to be configured on the device for the Local Configuration mechanism. The policy mechanism in the later case is comparing the I2RS client's priority with that priority assigned to the Local Configuration.

When the Local Configuration always wins, some communication between that subsystem and the I2RS Agent is still necessary. That communication contains the details of each specific device configuration change that the I2RS Agent is permitted to modify. In addition, when the system determines, that a client's I2RS state is preempted, the I2RS agent must notify the affected I2RS clients; how the system determines this is implementation-dependent.

It is critical that policy based upon the source is used because the resolution cannot be time-based. Simply allowing the most recent state to prevail could cause race conditions where the final state is not repeatably deterministic.

6.4. Routing Components and Associated I2RS Services

For simplicity, each logical protocol or set of functionality that can be compactly described in a separable information and data model is considered as a separate I2RS Service. A routing element need not implement all routing components described nor provide the associated I2RS services. I2RS Services should include a capability model so that peers can determine which parts of the service are supported. Each I2RS Service requires an information model that describes at least the following: data that can be read, data that can be written, notifications that can be subscribed to, and the capability model mentioned above.

The initial services included in the I2RS architecture are as follows.

***************************     **************    *****************
*      I2RS Protocol      *     *            *    *    Dynamic    *    
*                         *     * Interfaces *    *    Data &     *
*  +--------+  +-------+  *     *            *    *  Statistics   *
*  | Client |  | Agent |  *     **************    *****************
*  +--------+  +-------+  *
*                         *        **************    *************
***************************        *            *    *           *
                                   *  Policy    *    * Base QoS  *
********************    ********   *  Templates *    * Templates *   
*       +--------+ *    *      *   *            *    ************* 
*  BGP  | BGP-LS | *    * PIM  *   **************    
*       +--------+ *    *      *                     
********************    ********       ****************************
                                       * MPLS +---------+ +-----+ *
**********************************     *      | RSVP-TE | | LDP | *
*    IGPs      +------+ +------+ *     *      +---------+ +-----+ *
*  +--------+  | OSPF | |IS-IS | *     * +--------+               *
*  | Common |  +------+ +------+ *     * | Common |               *
*  +--------+                    *     * +--------+               *
**********************************     ****************************

**************************************************************
* RIB Manager                                                *
*  +-------------------+  +---------------+   +------------+ *
*  | Unicast/multicast |  | Policy-Based  |   | RIB Policy | *
*  | RIBs & LIBs       |  | Routing       |   | Controls   | *
*  | route instances   |  | (ACLs, etc)   |   +------------+ *
*  +-------------------+  +---------------+                  *
**************************************************************