Network Working Group                                           A. Atlas
Internet-Draft                                          Juniper Networks
Intended status: Informational                                J. Halpern
Expires: February 17, August 14, 2014                                        Ericsson
                                                                S. Hares
                                                                   ADARA
                                                                 D. Ward
                                                           Cisco Systems
                                                               T. Nadeau
                                                        Juniper Networks
                                                         August 16, 2013
                                                                 Brocade
                                                       February 10, 2014

        An Architecture for the Interface to the Routing System
                    draft-ietf-i2rs-architecture-00
                    draft-ietf-i2rs-architecture-01

Abstract

   This document describes an architecture for a standard, programmatic
   interface for state transfer in and out of the Internet's routing
   system.  It describes the basic architecture, the components, and
   their interfaces with particular focus on those to be standardized as
   part of I2RS.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on February 17, August 14, 2014.

Copyright Notice

   Copyright (c) 2013 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Functional Overview . . . . . . .  Drivers for the I2RS Architecture . . . . . . . . . . . .   3   4
     1.2.  Architectural Overview  . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   7   8
   3.  Key Architectural Properties  . . . . . . . . . . . . . . . .   8  10
     3.1.  Simplicity  . . . . . . . . . . . . . . . . . . . . . . .   8  10
     3.2.  Extensibility . . . . . . . . . . . . . . . . . . . . . .   9  10
     3.3.  Model-Driven Programmatic Interfaces  . . . . . . . . . .   9
     3.4.  Authorization  11
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
     4.1.  Identity and Authentication . . . . . . . . . . . .  10
   4. . . .  12
     4.2.  Authorization . . . . . . . . . . . . . . . . . . . . . .  13
   5.  Network Applications and I2RS Client  . . . . . . . . . . . .  10
     4.1.  13
     5.1.  Example Network Application: Topology Manager . . . . . .  11
   5.  14
   6.  I2RS Agent Role and Functionality . . . . . . . . . . . . . .  11
     5.1.  14
     6.1.  Relationship to its Routing Element . . . . . . . . . . .  11
     5.2.  15
     6.2.  I2RS State Storage  . . . . . . . . . . . . . . . . . . .  15
       6.2.1.  I2RS Agent Failure  . . .  12
       5.2.1. . . . . . . . . . . . . . .  15
       6.2.2.  Starting and Ending . . . . . . . . . . . . . . . . .  12
       5.2.2.  16
       6.2.3.  Reversion . . . . . . . . . . . . . . . . . . . . . .  13
     5.3.  16
     6.3.  Interactions with Local Config  . . . . . . . . . . . . .  13
     5.4.  17
     6.4.  Routing Components and Associated I2RS Services . . . . .  13
       5.4.1.  Unicast and Multicast RIB  17
       6.4.1.  Routing and LFIB Label Information Bases . . . . . . . . .  14
       5.4.2.  18
       6.4.2.  IGPs, BGP and Multicast Protocols . . . . . . . . . .  14
       5.4.3.  19
       6.4.3.  MPLS  . . . . . . . . . . . . . . . . . . . . . . . .  15
       5.4.4.  19
       6.4.4.  Policy and QoS Mechanisms . . . . . . . . . . . . . .  15
   6.  I2RS Client Agent Interface  20
       6.4.5.  Information Modeling, Device Variation, and
               Information Relationships . . . . . . . . . . . . . .  20
         6.4.5.1.  Managing Variation: Object Classes/Types and
                   Inheritance . . .  15
     6.1.  Protocol Structure . . . . . . . . . . . . . . . .  20
           6.4.5.1.1.  Managing Variation: Optionality . . . .  15
     6.2.  Channel . . .  21
           6.4.5.1.2.  Managing Variation: Templating  . . . . . . .  21
           6.4.5.1.3.  Object Relationships  . . . . . . . . . . . .  22
   7.  I2RS Client Agent Interface . . . .  16
     6.3.  Negotiation . . . . . . . . . . . . .  23
     7.1.  One Control and Data Exchange Protocol  . . . . . . . . .  23
     7.2.  Communication Channels  .  16
     6.4.  Identity and Security Role . . . . . . . . . . . . . . .  16
       6.4.1.  Client Redundancy .  23
     7.3.  Capability Negotiation  . . . . . . . . . . . . . . . . .  16
     6.5.  Connectivity  23
     7.4.  Identity and Security Role  . . . . . . . . . . . . . . .  24
       7.4.1.  Client Redundancy . . . . . . .  17
     6.6.  Notifications . . . . . . . . . . .  24

     7.5.  Connectivity  . . . . . . . . . . .  17
     6.7.  Information collection . . . . . . . . . . .  24
     7.6.  Notifications . . . . . .  18
     6.8.  Multi-Headed Control . . . . . . . . . . . . . . . .  25
     7.7.  Information collection  . .  18
     6.9.  Transactions . . . . . . . . . . . . . . .  26
     7.8.  Multi-Headed Control  . . . . . . .  19
   7.  Manageability Considerations . . . . . . . . . . .  26
     7.9.  Transactions  . . . . . .  19
   8.  Security Considerations . . . . . . . . . . . . . . . .  27
   8.  Manageability Considerations  . . .  20 . . . . . . . . . . . . .  27
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20  28
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  20  28
   11. Informative References  . . . . . . . . . . . . . . . . . . .  20  28
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20  28

1.  Introduction

   Routers that form the Internet's routing infrastructure maintain
   state at various layers of detail and function.  For example, a
   typical router maintains a Routing Information Base (RIB), and
   implements routing protocols such as OSPF, ISIS, and BGP to exchange
   protocol state and other information about the state of the network
   with other routers.

   A router also has information that may be required for

   Routers know how to convert all of this information into the
   forwarding operations that are installed in the forwarding plane.
   The forwarding plane and the specified forwarding operations then
   contain active state information that describes the expected and
   observed operational behavior of the router and which is also needed
   by the network applications.  Network-oriented applications require
   easy access to understand this information to learn the network, network topology, to
   verify that programmed state is installed in the forwarding plane, to
   measure the behavior of various flows, routes or forwarding entries,
   as well as to understand the configured and active states of the
   router.  Furthermore, routers are typically
   configured with procedural or policy-based instructions that tell
   them how to convert all of this information into the forwarding
   operations that are installed in the forwarding plane.  It is also
   the active state information that describes the expected and observed
   operational behavior of the router.

   This document sets out an architecture for a common, standards-based
   interface to this information.  This Interface to the Routing System
   (I2RS) facilitates control and diagnosis observation of the routing-related
   state (for example, a Routing Element RIB manager's state, state), as well
   as enabling network network-oriented applications to be built on top of
   today's routed networks.  The I2RS is a programmatic asynchronous
   interface for transferring state into and out of the Internet's
   routing system, and system.  This I2RS architecture recognizes that the routing
   system and a router's OS provide useful mechanisms that applications
   could harness to accomplish application-level goals.

   Fundamental to the I2RS are clear data models that define the
   semantics of the information that can be written and read.  The I2RS
   provides a framework for registering for and requesting the
   appropriate information for each particular application.  The I2RS
   provides a way for applications to customize network behavior while
   leveraging the existing routing system as much as desired.

   The

   Although the I2RS architecture is general enough to support
   information and data models for a variety of data, the I2RS, and
   therefore this document, are specifically focused on an interface for
   routing data.

1.1.  Functional Overview  Drivers for the I2RS Architecture

   There are four key aspects to drivers that shape the I2RS.  First, I2RS architecture.  First
   is the need for an interface that is a
   programmatic interface which needs to be asynchronous programmatic, asynchronous, and
   offers fast, interactive access.  Second,  Second is the I2RS gives access to structured
   information and state that is frequently not usually directly configurable or
   modeled in existing implementations or configuration protocols.  Third, the I2RS
   gives applications
   Third is the ability to learn additional, subscribe to structured, filterable information and events event
   notifications from the router.  Fourth, the operation of I2RS
   will is to
   be data-model driven to facilitate extensibility and provide standard
   data-models to be used by network applications.

   I2RS is described as an asynchronous programmatic interface; interface, the key
   properties of which are described in Section 5 of
   [I-D.atlas-i2rs-problem-statement].
   [I-D.ietf-i2rs-problem-statement].

   The I2RS facilitates obtaining information from the router.  The I2RS
   provides the ability to not only read specific information, but also
   to subscribe to targeted information streams and filtered and
   thresholded events.

   Such an interface also facilitates the specification injection of implicitly non-
   permanent ephemeral state
   into the routing system, that can optionally be made
   permanent.  In addition, the extraction of that information and
   additional dynamic information from the routing system is a critical
   component of the interface. system.  A non-routing protocol or application could
   inject state into a routing element via the state-insertion
   aspects
   functionality of the I2RS and that state could then be distributed in
   a routing or signaling protocol and/or be used locally (e.g. to
   program the co-located forwarding plane).

   There are several types of information that the  I2RS will facilitate
   an I2RS Client obtaining.  These range from dynamic event
   notifications (e.g. changes to a particular next-hop, interface up/
   down, etc.)to information collection streams (statistics, topology,
   route changes, etc) to simply read operations.  The I2RS provides the
   ability for an I2RS client only permit
   modification of state that would be safe, conceptually, to request filtered and thresholded
   information as well as events. modify via
   local configuration; no direct manipulation of protocol-internal
   dynamically determined data is envisioned.

1.2.  Architectural Overview

   The figure in

   Figure 1 shows the basic architecture for I2RS.  Inside
   a Routing Element, the I2RS agent interacts with both the routing
   subsystem between applications
   using I2RS, their associated I2RS Clients, and with local configuration.  A network application uses
   an I2RS Agents.
   Applications access I2RS services through I2RS clients.  A single
   client can provide access to communicate with one or more I2RS agents on their
   routing elements.  The scope of I2RS is to define the interactions
   between applications.  In the I2RS agent
   figure, Clients A and the B provide access to a single application, while
   Client P provides access to multiple applications.

   Applications can access I2RS client and the associated proper
   behavior of services through local or remote
   clients.  In the figure, Applicatons A and B access I2RS agent services
   through local clients, while Applications C, D and E access I2RS
   services through a remote client.

          ***********************          ***********************
          *    Application A    *          *    Application B    *
          *                     *          *                     *
          *  +----------------+ *          *  +----------------+ *
          *  |   Client A     | *          *  |

   An I2RS Client can access one or more I2RS agents.  In the figure,
   Clients B     | *
          *  +----------------+ *          *  +----------------+ *
          ******* ^ *************          ***** ^ ****** ^ ******
                  |                              |        |
                  |       -----------------------|        |
                  |       |                               |
          ******* v ***** v ************   ************** v **********
          *  +----------------+        *   *  +----------------+     *
          *  |     Agent and P access I2RS Agents 1    |        *   *  |    Agent and 2.  Likewise, an I2RS Agent
   can provide service to one or more clients.  In the figure, I2RS
   Agent 1 provides services to Clients A, B and P while Agent 2     |     *
          *  +----------------+
   provides services to only Clients B and P.

   I2RS agents and clients communicate with one another using an
   asynchronous protocol.  Therefore, a single client can post multiple
   simultaneous requests, either to a single agent or to multiple
   agents.  Furthermore, an agent can process multiple requests, either
   from a single client or from multiple clients, simultaneously.

   The I2RS agent provides read and write access to selected data on the
   routing element that are organized into I2RS Services.
   Section Section 4 describes how access is mediated by authentication
   and access control mechanisms.  In addition to read and write access,
   the I2RS agent allows clients to subscribe to different types of
   notifications about events affecting different object instances.  An
   example not related to the creation, modification or deletion of an
   object instance is when a next-hop in the RIB is resolved enough to
   be used or when a particular route is selected by the RIB Manager for
   installation into the forwarding plane.  Please see Section 7.6 and
   Section 7.7 for details.

   The scope of I2RS is to define the interactions between the I2RS
   agent and the I2RS client and the associated proper behavior of the
   I2RS agent and I2RS client.

        ******************   *****************  *****************
        *  Application C *  +----------------+   * Application D *     ^        ^   ^  * Application E *
        ******************   *****************  *****************
                 ^                  ^                   ^       *
          *
                 |                  |                   |         *   *
                 |--------------|   |    |--------------|
                                |   |       *
          *     v    |
                                v         *   *   v        |    v
                              ***************
                              *  Client P   * ***********
                              ***************
                                   ^     ^
                                   |     |-------------------------|
         ***********************   |      ***********************  |  **********
         *    Application A    * ***********   | *********      *    Application B    *  |
         * Routing                     *   |      * Local                     *  |
         *  +----------------+ *   |      * Routing  +----------------+ *  |
         * Local  |   Client A     | *   |      *  |   Client B     | *  |
         *   and  +----------------+ *   |      * Config  +----------------+ *  |
         ******* ^ *************   |      ***** ^ ****** ^ ******  |
                 |                 |            |        |         |
                 |   |-------------|            |        |   |-----|
                 |   |   -----------------------|        |   |
                 |   |   |                               |   |
    ************ v * v * v *********   ***************** v * v ********
    *  +---------------------+     *   *   and  +---------------------+     *
    *  |     Agent 1         |     *   *  |    Agent 2          |     * Config*
    *  +---------------------+     *   *  +---------------------+     *
    *     ^        ^  ^   ^        *   *     ^        ^  ^   ^        *
    * *Signaling*     |  **********        |  |   |        *   * *Signaling*     | *********        |  |   |        *
    * **********     v        |  |   v        *   * ***********     v        |  |   v        *
    *       ************ +---------+  |  | +--------+ *   * +---------+  |  | +--------+ *      ***********
    * | Routing |  |  | | Local  | *   *  Dynamic | Routing |  |  | | Local  | *
    * |   and   |  |  | | Config | *   * Dynamic |   and   |  |  | | Config | *
    * |Signaling|  |  | +--------+ *   *  System |Signaling|  |  | +--------+ *
    * +---------+  |  |         ^  *   * System +---------+  |  |         ^  *
    *    ^         |  |scoped   |  *   *  State    ^         |  |scoped   |  *
    *    |    |----|  |         |  *   *    |    |----|  |         |  *
    *    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 at least some portion 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
         ISIS, OSPF, BGP, PIM, etc.

      *  A server that runs BGP 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 ISIS, 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 Config:   A Routing Element will provide the ability to
      configure and manage it.  The Local Config may be provided via a
      combination of CLI, NETCONF, SNMP, etc.  The black box behavior
      for interactions between the state that I2RS installs into the
      routing element and the Local Config must be defined.

   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, 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.

   I2RS Agent:   The

   Static System State:   An I2RS agent implements the I2RS protocol(s) and
      interacts with the routing element needs access to provide specified behavior. 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:   The I2RS client implements the I2RS protocol(s).  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 the I2RS agent to modify the state of   See the routing
      system the client interacts with to achieve operational goals. 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.  The handling of this situation has been a source of
   discussion in the working group.  In order to keep the protocol simple, the current view
   is that two clients should not be attempting to write (modify) the
   same piece of information.  Such collisions may happen, but are
   considered error cases that should be resolved by the network
   applications and management systems.

   Multiple

   In contrast, although multiple I2RS clients may need to supply data
   into the same list (e.g. a prefix or filter list); 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 6.8. 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 5.3. 6.3.

   In addition it must be noted that there may be indirect interactions
   between write operations.  A tivial 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 for now.  [[Editor's note: This topic
   needs more discussion in the working group.]]
   implementation.

2.  Terminology

   The following terminology is used in this document.

   agent or I2RS Agent:   An I2RS agent provides the supported I2RS
      services to from the local system's routing sub-systems. 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 speaks implements the I2RS protocol protocol, uses
      it to communicate with I2RS Agents Agents, and uses the I2RS services to
      accomplish a task.  An I2RS client can be seen as the part  It interacts with other elements of an
      application that uses and supports I2RS the
      policy, provisioning, and could be a software
      library.

   service or I2RS Service:   For configuration system by means outside of
      the purposes scope of I2RS, a service refers
      to a 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 the routing system the client interacts with 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 set of information which the I2RS client is
      authorized to read.  This access includes  The read scope specifies the permission access
      restrictions to both see the existence of data and the ability to retrieve 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 do so given be constrained by the access
      restrictions
      of 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 or scope, write scope, or
      notification scope, the term scope applies to both the read scope and 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 can 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.

   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.

   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.1.  Simplicity

   There have been many efforts over the years to improve the access to
   the information known 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 span 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.

   Having noted that, it is also critical to the utility of I2RS that it
   be easily deployed deployable and robust.  Complexity in the protocol hinders
   implementation, robustness, and deployability.  Also, complexity in
   the data models frequently makes it harder to extend rather than
   easier.
   complexity may complicate 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

   There are several ways

   Naturally, 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.  We are only working on the models to be used over the single
   identified interface.  We are only looking at  The I2RS Working
   Group is modeling a subset of
   the data of interest.  And we are probably only representing a subset of the operations that may eventually be needed (although there is
   some hope that we are closer on that aspect than others to what is
   needed.)  Thus, it is important to consider extensibility not only of
   the underlying services' data models, but also of the primitives and
   protocol operations.

   At the same time, it interest.  It is
   clearly desirable for the data models and
   protocol operations we define defined in the I2RS to be
   useful the 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.  Hence,  This reinforces the criticality of
   designing the data model and protocol definitions need to be
   designed 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.

3.4.  Authorization and Authentication

   All control exchanges between the

4.  Security Considerations

   This I2RS client and agent MUST be
   authenticated and integrity protected (such architecture describes interfaces that the contents cannot
   be changed without detection).  Manipulation clearly require
   serious consideration 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 Agents, in performing information collection and manipulation,
   will be acting on behalf security.  First, here is a brief
   description of the assumed security environment for I2RS.  The I2RS clients.  As such, they will
   operate based on the lower of the two permissions of the agent itself
   and
   Agent associated with a Routing Element is a trusted part of the client.

   I2RS clients that
   Routing Element.  For example, it may be operating on behalf part of other applications.  While
   those applications' identities are not need a vendor-distributed
   signed software image for authorization, each the entire Routing Element or it may be
   trusted signed application should that an operator has installed.  The I2RS
   Agent is assumed to have a unique opaque identifier that can be
   provided separate authentication and authorization
   channel by which it can validate both the identity and permissions
   associated with an I2RS client to Client.  To support numerous and speedy
   interactions between the I2RS agent for purposes of
   tracking attribution of operations to support functionality such as
   accounting and troubleshooting.

4.  Network Applications Agent and I2RS Client

   An I2RS Client has a standardized interface Client, it is assumed
   that uses the I2RS
   protocol(s) to communicate with Agent can also cache that particular I2RS Agents.  The interface between
   an Clients are
   trusted and their associated authorized scope.  This implies that
   either in a pull model, the permission information may be old until
   the I2RS client Agent rerequests it, or in a push model, that the
   authentication and authorization channel can notify the network applications I2RS Agent of
   changes.

   An I2RS Client is outside not automatically trustworthy.  It has identity
   information and applications using that I2RS Client should be aware
   of the scope limitations of
   I2RS.

   When an I2RS Client interacts with multiple network applications, that I2RS Client.  If the I2RS Client is behaving
   acting as a go-between and should indicate this
   to broker for multiple applications, managing the I2RS Agents by, security,
   authentication and authorization for example, specifying a secondary opaque
   identity to allow improved troubleshooting.

   A network application that uses an communication is out of
   scope; nothing prevents I2RS client may also be considered and a routing element separate authentication and include
   authorization channel from being used.  Regardless of mechanism, an
   I2RS agent Client that is acting as a broker is responsible for interactions.
   However, where determining
   that applications using it are trusted and permitted to make the needed information
   particular requests.

   Different levels of integrity, confidentiality, and data models replay protection
   are relevant for that upper
   interface differs from that of a conventional routing element, those
   models are, at least initially, out different aspects of scope for I2RS.

4.1.  Example Network Application: Topology Manager

   One example of such an application  The primary
   communication channel that is a Topology Manager.  A Topology
   Manager includes an I2RS used for client that uses authentication and then
   used by the I2RS client to write data models requires integrity, privacy and
   protocol to collect information about the state
   replay protection.  Appropriate selection of a default required
   transport protocol is the network by
   communicating directly with one or more I2RS agents.  From preferred way of meeting these
   requirements.

   Other communications via I2RS
   agents, the Topology Manager collects routing configuration will not require integrity,
   confidentiality, and
   operational data.  Most importantly, it collects replay protection.  For instance, if an I2RS
   Client subscribes to an information about
   the routing system, including the contents stream of the IGP (e.g., IS-IS or
   OSPF) and BGP data sets.

   The Topology Manager prefix announcements
   from OSPF, those may be embedded as a component of a larger
   application.  It would construct internal data structures and use the
   collected data to drive functions such as path computations require integrity but probably not
   confidentiality or
   anomalous routing detection.  Alternatively, the Topology Manager
   could combine the I2RS-collected data with other information,
   abstract a composite set, and provide a coherent picture replay protection.  Similarly, an information
   stream of the
   network state accessible via another interface.  That interface might
   use statistics may not even require guaranteed
   delivery.  In Section 7.2, more reasoning for multiple communication
   channels is provided.  From the same I2RS protocol and could use extensions security perspective, it is critical
   to the realize that an I2RS data
   models.  Developing Agent may open a new communication channel
   based upon information provided by an I2RS Client; to avoid an
   indirect attack, such mechanisms is outside a request must be done in the initial scope 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 work.

5.  I2RS Agent Role client and Functionality

   The I2RS Agent is part of a routing element.  As such, it has
   relationships with that routing element as a whole,
   agent should be authenticated and with various
   components of integrity protected (such that routing element.

5.1.  Relationship to its Routing Element

   A Routing Element may be implemented with a wide variety the
   contents cannot be changed without detection).  Further, manipulation
   of different
   architectures: the system must be accurately attributable.  In an integrated router, a split architecture,
   distributed ideal
   architecture, etc.  The architecture does not need to
   affect the general I2RS agent behavior.

   For scalability even information collection and generality, the I2RS agent notification should be
   protected; this may be responsible for
   collecting and delivering large amounts of data from various parts of subject to engineering tradeoffs during the routing element.  Those parts may or
   design.

   I2RS clients may not actually be part operating on behalf of
   a single physical device.  Thus, for scalability and robustness, it
   is important that the architecture allow other applications.  While
   those applications' identities are not needed for authentication or
   authorization, each application should have a distributed set of
   reporting components providing collected data from unique opaque
   identifier that can be provided by the I2RS agent
   back client to the relevant I2RS clients.  As currently envisioned, a given I2RS agent would have only one locus per I2RS service
   for
   manipulation purposes of routing element state.

5.2.  State Storage

   State modification requests are sent tracking attribution of operations to support
   functionality such as accounting and troubleshooting.

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 a the network
   element by element.

   I2RS clients.  The Agents, in performing information collection and manipulation,
   will be acting on behalf of the I2RS agent is responsible for applying
   these changes to clients.  As such, each
   operation authorization will be based on the system.  How much data must lower of the I2RS Agent store
   about these state-modifying operations, and with what persistence?
   There are range two
   permissions of possible answers.  One extreme is where it stores
   nothing, cannot indicate why or by whom state was placed into the
   routing element, agent itself and relies on clients reapplying things in all
   possible cases. of the authenticated client.  The other extreme
   mechanism by which this authorization is where multiple clients'
   overlapping operations are stored and managed, as applied within the device is done in
   outside of the RIB
   for routes with a preference scope of I2RS.

   The appropriate or priority to pick between necessary level of granularity for scope can
   depend upon the routes.

   In answering this question, this architecture tries particular I2RS Service and the implementation's
   granularity.  An approach to provide
   sufficient power a similar access control problem is
   defined in the NetConf Access Control Model[RFC6536]; it allows
   arbitrary access to keep client operations effective, be specified for a data node instance identifier
   while still
   being simple defining meaningful manipulable defaults.  The ability to implement in the
   specify one or more groups or roles that a particular I2RS Agent, Client
   belongs and then define access controls in terms of those groups or
   roles is expected.  When a client is authenticated, its group or role
   membership should be provided to observe
   meaningfully during operation.  The I2RS agent stores the I2RS Agent.  The set of
   operations it has applied.  Simply, the access
   control rules that an I2RS agent stores who did
   what operation Agent uses would need to which entity.  New changes replace any data about
   old ones.  If be either
   provided via Local Config, exposed as an I2RS client does an operation to remove Service for
   manipulation by authorized clients, or via some state,
   that state other method.

5.  Network Applications and I2RS Client

   I2RS is removed expected to be used by network-oriented applications in
   different architectures.  While the interface between a network-
   oriented application and the I2RS agent stores no more information
   about it.  This allows any interested party to determine what client is outside the
   current effect scope of I2RS on
   I2RS, considering the system is, and why.  Meaningful logging different architectures is also recommended.

   The I2RS Agent will not attempt important to retain
   sufficiently specify I2RS.

   In the simplest architecture, a network-oriented application has an
   I2RS client as a library or reapply state across driver for communication with routing element reboot.  Determination of whether state still applies
   depends heavily on
   elements.

   In the causes of reboots, and reapplication is at
   least as likely broker architecture, multiple network-oriented applications
   communicate in an unspecified fashion to cause problems as it 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 to provide out of scope for correct
   operation.  [[Editor's note: This topics needs more discussion I2RS
   but similar considerations to those described in Section 4.2 do
   apply.  As discussed in Section 4.1, the
   working group.]]

5.2.1.  Starting and Ending

   An broker I2RS client applies changes via Client should
   determine distinct opaque identifiers for each network-oriented
   application that is using it.  The the broker I2RS protocol based on policy
   and other application inputs.  While these changes may be of Client can pass
   along the form
   "do this now, and leave it there forever", they are frequently driven
   by other conditions appropriate value as a secondary identifier which may have start times, stop times, or are
   only to can be
   used under certain conditions.  The for tracking attribution of operations.

   In the third architecture, a routing element or network-oriented
   application that uses an I2RS interface
   protocol could be designed Client to allow access services on a
   different routing element may also contain an I2RS Client agent to provide a wide
   range of such conditional information
   services to the I2RS Agent for
   application.  At the other extreme, network-oriented applications.  However, where the I2RS client could provide all
   such functionality based on its own clocking
   needed information and network event
   reporting data models for those services differs from the relevant I2RS Agents.

   Given
   that the complexity of possible conditions is very large, and
   that some conditions may even cross network element boundaries,
   clearly some degree a conventional routing element, those models are, at least
   initially, out of handling must be provided on the I2RS client.
   As such, in this architecture it scope for I2RS.  Below is assumed an example of such a
   network application

5.1.  Example Network Application: Topology Manager

   A Topology Manager includes an I2RS client that all uses the complexity
   associated with this should be left I2RS data
   models and protocol to collect information about the I2RS client.  This
   architectural view does mean that reliability state of the communication
   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 between (LSP) information.  In addition, the Topology Manager
   may collect link-state data in several ways - either via I2RS client models,
   by peering with BGP-LS[I-D.ietf-idr-ls-distribution] or listening
   into the IGP.

   The set of functionality and I2RS agent collected information that is critical.  [[Editor's
   note: This requires more discussion in the working group.]]

5.2.2.  Reversion

   An I2RS Agent
   Topology Manager 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 embedded as a component of a larger
   application, such cases, as a path computation application.  As a stand-
   alone application, the state will revert Topology Manager could be useful to what it would have been
   without other
   network applications by providing a coherent picture of the I2RS; that network
   state is generally whatever was specified accessible via another interface.  That interface might use the CLI, NETCONF, SNMP, etc.
   same I2RS Agents will not store multiple
   alternative states, nor try to determine which one among such protocol and could provide a
   plurality it should fall back to.  Thus, the model followed is not
   like topology service using
   extensions to the RIB, where multiple routes are stored at different
   preferences.

   An I2RS Client may register for notifications when state that was
   applied by a particular data models.

6.  I2RS Client Agent Role and Functionality

   The I2RS Agent is modified or removed.

5.3.  Interactions with Local Config part of a routing element.  As described above, local device configuration is considered 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
   separate from 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 data store.  Thus, changes agent behavior.

   For scalability and generality, the I2RS agent may originate be responsible for
   collecting and delivering large amounts of data from
   either source.  Policy (i.e. comparisons between various parts of
   the routing element.  Those parts may or may not actually be part of
   a CLI/SNMP/NETCONF
   priority 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 priority) can determine whether
   back to the local
   configuration should overwrite any state written by relevant I2RS and
   attributed to clients.  As currently envisioned, a particular given
   I2RS Client or whether agent would have only one locus per I2RS as attributed service for
   manipulation of routing element state.

6.2.  I2RS State Storage

   State modification requests are sent to the I2RS agent in a particular routing
   element by I2RS Client can overwrite local configuration state.

   Simply allowing the most recent state to prevail could cause race
   conditions where the final state is not repeatably deterministic.
   One important aspect clients.  The I2RS agent is that if CLI/SNMP/NETCONF responsible for applying
   these changes data that is
   subject to monitoring or manipulating by I2RS, then the system must
   be instrumented enough system, subject to provide suitable the authorization discussed
   above.  The I2RS notifications agent will retain knowledge of
   these changes.

5.4.  Routing Components the changes it has
   applied, and Associated the client on whose behalf it applied the changes.  The
   I2RS Services
   For simplicity, each logical protocol or set agent will also store active subscriptions.  These sets of functionality that be
   compactly described in a separable information and data model
   form the I2RS data store.  This data is
   considered retained by the agent until
   the state is removed by the client, overridden by some other
   operation such as a separate CLI, or the device reboots.  Meaningful logging of
   the application and removal of changes is recommended.  I2RS Service.  A applied
   changes to the routing element need state will not
   implement all be retained across
   routing components described nor provide the associated
   I2RS services. element reboot.  The initial services included in the I2RS
   architecture are as follows.

5.4.1.  Unicast and Multicast RIB and LFIB

   Network elements concerned with data store is not preserved across
   routing IP maintain IP unicast RIBs.
   Similarly, there are RIBs for IP Multicast, and element reboots; thus the I2RS agent will not attempt to
   reapply such changes after a Label Information
   Base (LIB) reboot.

6.2.1.  I2RS Agent Failure

   If it is possible for MPLS.  The an I2RS Agent to fail independently of the
   associated routing element, the behavior for any associated ephemeral
   I2RS state needs to be able to read and
   write these sets of data. clearly described.  The I2RS data model must include models
   for this information.

   In particular, with regard to writing this information, state should be
   preserved until the associated routing element has itself rebooted or
   until the I2RS state is explicitly torn down.  This is desirable
   since the I2RS Client has no way of learning that an I2RS Agent should use has
   unexpected failed until that I2RS Agent has restarted; in the same mechanisms
   interval between failure and recovery, the I2RS Client will be
   assuming that its ephemeral state remains.  If failure of the routing element already
   uses to handle RIB input from multiple sources, so as to compatibly
   change I2RS
   agent causes the system state.

   The multicast ephemeral I2RS state added to be removed, then this should
   be indicated via a capability.

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

   Unexpected failure:   In this case, the multicast RIB does not need to match
   to well-known protocol installed state.  The I2RS Agent has unexpectedly
      crashed and thus cannot notify its clients of anything.  If an
      I2RS Agent can create
   arbitrary replication state in crash separately from its associated routing
      element, then that I2RS Agent must cache each known I2RS Client.
      When an I2RS Agent starts, it notifies each saved I2RS Client that
      the RIB, subject to I2RS Agent is up and includes an agent-boot-count that
      indicates how many times the advertised
   capabilities of I2RS Agent has restarted since the
      associated routing element.

5.4.2.  IGPs, BGP and Multicast Protocols

   In addition element restarted.  The agent-boot-count allows
      an I2RS Client to interacting with determine if the consolidated RIB, I2RS Agent has restarted; if
      so, the I2RS agent Client may need to interact with resubscribe to notifications and
      information streams.  The I2RS Agent should also indicate whether
      the individual routing protocols on I2RS ephemeral state was preserved in the
   device.  This interaction includes a number of different kinds of
   operations:

   o  reading Routing Element.

   Graceful failure:   In this case, the various internal rib(s) I2RS Agent can do specific
      limited work as part of the routing protocol is
      often helpful for understanding the state process of being disabled.  First, the network.
      Directly writing these protocol-specific RIBs or databases is out
      of scope for I2RS.

   o  reading the various pieces of policy information the particular
      protocol instance is using to drive
      I2RS Agent can optionally notify all its operations.

   o  writing policy information clients that their state
      is being torn down; if no such as interface attributes notification is sent, then that are
      specific to
      ephemeral state is not torn down.  Second, the routing protocol or BGP policy I2RS Agent must
      notify all its cached clients that may indirectly
      manipulate attributes of routes carried in BGP.

   o  writing routes or prefixes to be advertised via the protocol.

   o  joining/removing interfaces from the multicast trees
   o  subscribing to agent is going down.

6.2.2.  Starting and Ending

   When an information stream of route I2RS client applies changes

   o  receiving notifications about peers coming up or going down

   For example, via the interaction with OSPF might include modifying I2RS protocol, those
   changes are applied and left until removed or the
   local routing element's link metrics, announcing element
   reboots.  The network application may make decisions about what to
   request via I2RS based upon a locally-attached
   prefix, or reading some of the OSPF link-state database.  However,
   direct modification of variety of the link-state database conditions that imply
   different start times and stop times.  That complexity is NOT allowed to
   preserve managed by
   the network application and is not handled by I2RS.

6.2.3.  Reversion

   An I2RS Agent may decide that some state consistency.

5.4.3.  MPLS

   The should no longer be applied.
   An I2RS agent Client may instruct an Agent to remove state it has applied.
   In all such cases, the state will need revert to interact with what it would have been
   without the protocols I2RS; that create
   transport LSPs (e.g. LDP 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.

   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 Config

   Changes may originate from either Local Config 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 Config overrides a particular
   I2RS client's request or vice versa.  To achieve this end, either by
   default Local Config always wins or, optionally, a routing element
   may permit a priority to be configured on the device for the Local
   Config mechanism.  The policy mechanism in the later case is
   comparing the I2RS client's priority with that priority assigned to
   the Local Config.

   When the Local Config 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 agents; 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.  When a full implementation is not mandatory, an I2RS
   Service should include a capability model so that implementations can
   indicate 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 | | ISIS | *     * +--------+               *
    *  | Common |  +------+ +------+ *     * | Common |               *
    *  +--------+                    *     * +--------+               *
    **********************************     ****************************

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

                    Figure 2: Anticipated I2RS Services

   There are relationships between different I2RS Services - whether
   those be the need for the RIB to refer to specific interfaces, the
   desire to refer to common complex types (e.g. links, nodes, IP
   addresses), or the ability to refer to implementation-specific
   functionality (e.g. pre-defined templates to be applied to interfaces
   or for QoS behaviors that traffic is direct into).
   Section Section 6.4.5 discussing information modeling constructs and
   the range of relationship types that are applicable.

6.4.1.  Routing and Label Information Bases

   Routing elements may maintain one or more Information Bases.
   Examples include Routing Information Bases such as IPv4/IPv6 Unicast
   or IPv4/IPv6 Multicast.  Another such example includes the MPLS Label
   Information Bases, per-platform- or per-interface."  This
   functionality, exposed via an I2RS Service, must interact smoothly
   with the same mechanisms that the routing element already uses to
   handle RIB input from multiple sources, so as to safely change the
   system state.  Conceptually, this can be handled by having the I2RS
   Agent communicate with a RIB Manager as a separate routing source.

   The point-to-multipoint state added to the RIB does not need to match
   to well-known multicast protocol installed state.  The I2RS Agent can
   create arbitrary replication state in the RIB, subject to the
   advertised capabilities of the routing element.

6.4.2.  IGPs, BGP and Multicast Protocols

   A separate I2RS Service can expose each routing protocol on the
   device.  Such I2RS services may include a number of different kinds
   of operations:

   o  reading the various internal RIB(s) of the routing protocol is
      often helpful for understanding the state of the network.
      Directly writing to these protocol-specific RIBs or databases is
      out of scope for I2RS.

   o  reading the various pieces of policy information the particular
      protocol instance is using to drive its operations.

   o  writing policy information such as interface attributes that are
      specific to the routing protocol or BGP policy that may indirectly
      manipulate attributes of routes carried in BGP.

   o  writing routes or prefixes to be advertised via the protocol.

   o  joining/removing interfaces from the multicast trees

   o  subscribing to an information stream of route changes

   o  receiving notifications about peers coming up or going down

   For example, the interaction with OSPF might include modifying the
   local routing element's link metrics, announcing a locally-attached
   prefix, or reading some of the OSPF link-state database.  However,
   direct modification of of the link-state database MUST NOT allowed in
   order to preserve network state consistency.

6.4.3.  MPLS

   I2RS Services will be needed to expose the protocols that create
   transport LSPs (e.g. LDP and RSVP-TE) as well as protocols (e.g. BGP,
   LDP) that provide MPLS-based services (e.g. pseudowires, L3VPNs,
   L2VPNs, etc).  This should include all local information about LSPs
   originating in, transiting, or terminating in this Routing Element.

6.4.4.  Policy and QoS Mechanisms

   Many network elements have separate policy and QoS mechanisms,
   including knobs which affect local path computation and queue control
   capabilities.  These capabilities vary widely across implementations,
   and I2RS cannot model the full range of information collection or
   manipulation of these attributes.  A core set does need to be
   included in the I2RS information models and supported in the expected
   interfaces between the I2RS Agent and the network element, in order
   to provide basic capabilities and the hooks for future extensibility.

   By taking advantage of extensibility and sub-classing, information
   models can specify use of a basic model that can be replaced by a
   more detailed model.

6.4.5.  Information Modeling, Device Variation, and Information
        Relationships

   I2RS depends heavily on information models of the relevant aspects of
   the Routing Elements to be manipulated.  These models drive the data
   models and protocol operations for I2RS.  It is important that these
   informational models deal well with a wide variety of actual
   implementations of Routing Elements, as seen between different
   products and different vendors.  There are three ways that I2RS
   information models can address these variations: class or type
   inheritance, optional features, and templating.

6.4.5.1.  Managing Variation: Object Classes/Types and Inheritance

   Information modeled by I2RS from a Routing Element can be described
   in terms of classes or types or object.  Different valid inheritance
   definitions can apply.  What is appropriate for I2RS to use is not
   determined in this architecture; for simplicity, class and subclass
   will be used as the example terminology.  This I2RS architecture does
   require the ability to address variation in Routing Elements by
   allowing information models to define parent or base classes and
   subclasses.

   The base or parent class defines the common aspects that all Routing
   Elements are expected to support.  Individual subclasses can
   represent variations and additional capabilities.  When applicable,
   there may be several levels of refinement.  The I2RS protocol can
   then provide mechanisms to allow an I2RS client to determine which
   classes a given I2RS Agent has available.  Clients which only want
   basic capabilities can operate purely in terms of base or parent
   classes, while a client needing more details or features can work
   with the supported sub-class(es).

   As part of I2RS information modeling, clear rules should be specified
   for how the parent class and subclass can relate; for example, what
   changes a subclass can make to its parent?  The description of such
   rules should be done so that it can apply across data modeling tools
   until the I2RS data modeling language is selected.

6.4.5.1.1.  Managing Variation: Optionality

   I2RS Information Models must be clear about what aspects are
   optional.  For instance, must an instance of a class always contain a
   particular data field X?  If so, must the client provide a value for
   X when creating the object or is there a well-defined default value?
   From the Routing Element perspective, in the above example, is
   support of X required so that values for X can be accepted and
   processed?  If not, how does the I2RS client determine whether the
   I2RS agent can accept and apply values for X?

   Optional behavior can also be extended to the ranges of values a
   given piece of information can take, the length of strings, the
   existence of particular events, and other aspects of information.
   The information model needs to be clear about what is required of the
   clients, what is required of agents, and what is permitted to each
   one.

6.4.5.1.2.  Managing Variation: Templating

   A template is a collection of information to address a problem; it
   cuts across the notions of class and object instances.  A template
   provides a set of defined values for a set of information fields and
   can specify a set of values that must be provided to complete the
   template.  Further, a flexible template scheme may that some of the
   defined values can be over-written.

   For instance, assigning traffic to a particular service class might
   be done by specifying a template Queueing with a parameter to
   indicate Gold, Silver, or Best Effort.  The details of how that is
   carried out are not modeled.  This does assume that the necessary
   templates are made available on the Routing Element via some
   mechanism other than I2RS.  The idea is that by providing suitable
   templates for tasks that need to be accomplished, with templates
   implemented differently for different kinds of Routing Elements, the
   client can easily interact with the Routing Element without concern
   for the variations which are handled by values included in the
   template.

   If implementation variation can be exposed in other ways, templates
   may not be needed.  However, templates themselves could be objects
   referenced in the protocol messages, with Routing Elements being
   configured with the proper templates to complete the operation.  This
   is a topic for further discussion.

6.4.5.1.3.  Object Relationships

   Objects (in a Routing Element or otherwise) do not exist in
   isolation.  They are related to each other.  One of the important
   things a class definition does is represent the relationships between
   instances of different classes.  These relationships can be very
   simple, or quite complicated.  The following lists the information
   relationships that the information models need to support.
   [[Editors' note: All of these are for discussion, and RSVP-TE) as well as protocols (e.g. BGP,
   LDP) it is expected
   that provide MPLS-based services (e.g. pseudowires, L3VPNs,
   L2VPNs, etc).

5.4.4.  Policy the list may be changed during WG discussion.]]

6.4.5.1.3.1.  Initialization

   The simplest relationship is that one object instances is initialized
   by copying another.  For example, one may have an object instance
   that represents the default setup for a tunnel, and QoS Mechanisms

   Many network elements all new tunnels
   have separate fields copied from there if they are not set as part of
   establishment.  This is closely related to the templates discussed
   above, but not identical.  Since the relationship is only momentary
   it is often not formally represented in modeling, but only captured
   in the semantic description of the default object.

6.4.5.1.3.2.  Correlation Identification

   Often, it suffices to indicate in one object that it is related to a
   second object, without having a strong binding between the two.  So
   an Identifier is used to represent the relationship.  This can be
   used to allow for late binding, or a weak binding that does not even
   need to exist.  A policy and QoS mechanisms,
   including knobs name in an object might indicate that if a
   policy by that name exists, it is to be applied under some
   circumstance.  In modeling this is often represented by the type of
   the value.

6.4.5.1.3.3.  Object References

   Sometimes the relationship between objects is stronger.  A valid ARP
   entry has to point to the active interface over which affect local path computation and queue control
   capabilities.  These capabilities vary widely across implementations,
   and I2RS cannot model it was derived.
   This is the full range classic meaning of an object reference in programming.
   It can be used for relationships like containment or dependence.
   This is usually represented by an explicit modeling link.

6.4.5.1.3.4.  Active Reference

   There is an even stronger form of information collection or
   manipulation coupling between objects if changes
   in one of these attributes.  A core set does need the two objects are always to be
   included reflected in the I2RS data models and in the expected interfaces
   between state of
   the I2RS Agent other.  For example, if a Tunnel has an MTU, and link MTU changes
   need to immediately propagate to the network element, in order Tunnel MTU, then the tunnel is
   actively coupled to provide
   basic capabilities and the hooks for future extensibility.
   [[Editor's note: link interface.  This requires more discussion in the working
   group.]]

6. kind of active state
   coupling implies some sort of internal bookkeeping to ensure
   consistency, often conceptualized as a subscription model across
   objects.

7.  I2RS Client Agent Interface

6.1.  Protocol Structure

7.1.  One could view I2RS merely as a way to talk about the existing
   network management interfaces to a network element.  That would be
   quite limiting Control and would not meet the requirements elucidated
   elsewhere.  One could also view Data Exchange Protocol

   This I2RS as a collection of protocols -
   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
   high.  One would need to develop means to coordinate information
   across a set of protocols Architecture presumes that were not designed to work together.
   From a deployability perspective, this would not there is one I2RS protocol for
   control and data exchange.  This helps meet the goal of
   simplicity.  As a result, this architecture views the I2RS as an
   interface supporting a single control simplicity
   and data exchange protocol. thereby enhances deployability.  Whether such a protocol is built
   upon extending existing mechanisms or requires a new mechanism requires further is
   under active investigation.  That protocol may use several underlying
   transports (TCP, SCTP, DCCP), 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

   The uses of a single I2RS protocol does not imply that only one
   channel

7.2.  Communication Channels

   Multiple communication channels and multiple types of communication is
   channels are required.  There may be a range of
   reliability requirements, requirements (e.g.
   confidentiality, reliability), and to support the scaling there may
   need to be channels originating from multiple sub-components of a
   routing
   element.  These element and/or to multiple parts of an I2RS client.  All such
   communication channels will all use the date exchange protocol, and
   establishment same higher level protocol.  Use
   of additional channels for communication will be coordinated between
   the I2RS client and the I2RS agent.

6.3.

7.3.  Capability Negotiation

   Protocol

   The support for different protocol capabilities and I2RS Services
   will vary across I2RS Clients and Routing Elements supporting I2RS
   Agents.  As such,  Since each I2RS Service is required to include a capability
   model (see Section 6.4), negotiation at the protocol level can be
   restricted to protocol specifics and which I2RS Services are
   supported.

   Capability negotiation (such as which transports are supported beyond
   the minimum required to implement) will clearly be necessary.  It is
   important that such negotiations be kept simple and robust, as such
   mechanisms are often a source of difficulty in implementation and
   deployment.

   Negotiation should

   The protocol capability negotiation can be broken segmented into several aspects, such as the basic
   version negotiation (required to ensure basic communication), and the
   more complex capability exchange which can take place within the base
   protocol mechanisms.  In particular, the more complex protocol
   capablities and
   mechanism negotiation can be addressed by defining information models
   for both the I2RS services Agent and model types supported.

6.4. the I2RS Client.  These information
   models can describe the various capability options.  This can then
   represent and be used to communicate important information about the
   agent, and the capabilities thereof.

7.4.  Identity and Security Role

   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, mechanisms
   based on the primary unique identity, the I2RS agent 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.

6.4.1.

7.4.1.  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 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.

7.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
   information.  The lack of an active communication channel does not
   imply that the associated client is non-functional.  When
   communication is required, the agent or client can open a new
   communication channel.

   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
   if the agent cannot successfully open a new communication channel to
   the client.

   There are three different assumptions that can apply

   For many applications, it may be desirable to handling dead
   clients.  The first is that clean up state if a
   network application dies before removing the state it has created.
   Typically, this is dealt with in terms of network applications or management
   systems will detect application
   redundancy.  If stronger mechanisms are desired, mechanisms outside
   of I2RS may allow a dead supervisory network application to monitor I2RS
   clients, and either restart
   that network application or based on policy known to the supervisor clean up any state
   if applications die.  More complex mechanism instantiated in the I2RS
   agent would add complications to the I2RS protocol and are thus left behind.
   for future work.

   Some examples of such a mechanism include the following.  In one
   option, the client could request state clean-up if a particular
   transport session is terminated.  The second is to allow state
   expiration, expressed as a policy associated with the I2RS client's
   role.  The state expiration could occur after there has been no
   successful communication channel to or from the
   I2RS client for the policy-specified duration.  The third is that the I2RS client could explicitly request state clean-up if a particular
   transport session is terminated.

6.6. for the
   policy-specified duration.

7.6.  Notifications

   As with any policy system interacting with the network, the I2RS
   Agent
   Client needs to be able to receive notifications of changes in
   network state.  Notifications here refers to changes which are
   unanticipated, represent events outside the control of the systems
   (such as interface failures on controlled devices), or are
   sufficiently sparse as to be anomalous in some fashion.  A
   notification may also be due to a regular event.

   Such events may be of interest to multiple I2RS Clients controlling
   data handled by an I2RS Agent, and to multiple other I2RS clients
   which are collecting information without exerting control.  The
   architecture therefore requires that it be practical for I2RS Clients
   to register for a range of notifications, and for the I2R I2RS Agents to
   send notifications to a number of Clients.

   As the  The I2RS is developed, it is likely Client should be
   able to filter the specific notifications that a management information- will be received; the
   specific types of events and filtering operations can vary by
   information model and data-model will need to be required specified as part of the information
   model.

   The I2RS information model needs to describe event notifications
   for general or include representation of these
   events.  As discussed earlier, the capability information in the
   model will allow I2RS errors. clients to understand which events a given I2RS
   Agent is capable of generating.

   For performance and scaling by the I2RS client and general
   information privacy, an I2RS Client needs to be able to register for
   just the events it is interested in.  It is also possible that I2RS
   might might provide a stream of notifications via a publish/subscribe
   mechanism that is not amenable to having the I2RS agent do the
   filtering.

6.7.

7.7.  Information collection

   One of the other important aspects of the I2RS is that it is intended
   to simplify collecting information about the state of network
   elements.  This includes both getting a snapshot of a large amount of
   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
   thereof.  This is considered architecturally separate from
   notifications due to the differences in information rate and total
   volume.

6.8.

7.8.  Multi-Headed Control

   As was described earlier, an I2RS Agent interacts with multiple I2RS
   Clients who are actively controlling the network element.  From an
   architecture and design perspective, the assumption is that by means
   outside of this system the data to be manipulated within the network
   element is appropriately partitioned so that any given piece of
   information is only being manipulated by a single I2RS Client.

   Nonetheless, unexpected interactions happen and two (or more) I2RS
   clients may attempt to manipulate the same piece of data.  This is
   considered an error case.  This architecture does not attempt to
   determine what the right state of data is in should be when such a
   collision happens.  Rather, the architecture mandates that there be
   decidable means by which I2RS Agents will handle the collisions.  The current recommendation
   mechanism for this is to have a simple priority associated with each
   I2RS clients, and the highest priority change remains in effect.  In
   the case of priority ties, the first client whose attribution is
   associated with the data will keep control control.

   In order for this approach to multi-headed control to be useful for
   I2RS Clients, it is important that it be possible for an I2RS Client
   to register for changes to any changes made by I2RS
   manipulatable to data that it
   may care about.  This is included in the I2RS event mechanisms.  This
   also needs to apply to changes made by CLI/NETCONF/SNMP within the
   write-scope of the I2RS Agent, as the same priority mechanism (even
   if it is "CLI always wins") applies there.  The I2RS client may then
   respond to the situation as it sees fit.

6.9.

7.9.  Transactions

   In the interest of simplicity, the I2RS architecture does not include
   multi-message atomicity and rollback mechanisms.  Rather, it includes
   a small range of error handling for a set of operations included in a
   single message.  An I2RS Client may indicate one of the following
   three error handling for a given message with multiple operations
   which it sends to an I2RS Agent:

   Perform all or none:   This traditional SNMP semantic indicates that
      other I2RS agent will keep enough state when handling a single
      message to roll back the operations within that message.  Either
      all the operations will succeed, or none of them will be applied
      and an error message will report the single failure which caused
      the
      them not to be applied.  This is useful when there are, for
      example, mutual dependencies across 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
      further operations are applied, and an error is returned
      indicating the failure.  This is useful if there are dependencies
      among the operations and they can be topologically sorted.

   Perform all storing errors:   In this case, the I2RS Agent will
      attempt to perform all the operations in the message, and will
      return error indications for each one that fails.  This is useful
      when there is no dependency across the operation, or where the
      client would prefer to sort out the effect of errors on its own.

   In the interest of robustness and clarity of protocol state, the
   protocol will include an explicit reply to modification or write
   operations even when they fully succeed.

7.

8.  Manageability Considerations

   Manageability plays a key aspect in I2RS.  Some initial examples
   include:

   Resource Limitations:   Using I2RS, applications can consume
      resources, whether those be operations in a time-frame, entries in
      the RIB, stored operations to be triggered, etc.  The ability to
      set resource limits based upon authorization is important.

   Configuration Interactions:   The interaction of state installed via
      the I2RS and via a router's configuration needs to be clearly
      defined.  As described in this architecture, a simple priority
      that is configured can be is used to express the desired policy.

8.  Security Considerations

   This framework describes interfaces that clearly require serious
   consideration of security.  The ability to identify, authenticate and
   authorize applications that wish to install state is necessary and
   briefly described in Section 3.4.  Security of communications from
   the applications is also required as discussed in Section 6.1.
   Scopes for reading and writing data specified in the context of the
   data models and the value ranges are discussed briefly in
   Section 6.4. provide sufficient policy
      flexibility.

9.  IANA Considerations

   This document includes no request to IANA.

10.  Acknowledgements

   Significant portions of this draft came from draft-ward-i2rs-
   framework-00 and draft-atlas-i2rs-policy-framework-00.

   The authors would like to thank Nitin Bahadur, Shane Amante, Ed
   Crabbe, Ken Gray, Carlos Pignataro, Wes George, Ron Bonica, Joe
   Clarke, Juergen Schoenwalder, and Jamal Hadi Salim Salim, Scott Brim, and
   Thomas Narten for their suggestions and review.

11.  Informative References

   [I-D.atlas-i2rs-problem-statement]

   [I-D.ietf-i2rs-problem-statement]
              Atlas, A., Nadeau, T., and D. Ward, "Interface to the
              Routing System Problem Statement", draft-atlas-i2rs-
              problem-statement-01 draft-ietf-i2rs-
              problem-statement-00 (work in progress), August 2013.

   [I-D.ietf-idr-ls-distribution]
              Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
              Ray, "North-Bound Distribution of Link-State and TE
              Information using BGP", draft-ietf-idr-ls-distribution-04
              (work in progress), July November 2013.

   [RFC6536]  Bierman, A. and M. Bjorklund, "Network Configuration
              Protocol (NETCONF) Access Control Model", RFC 6536, March
              2012.

Authors' Addresses

   Alia Atlas
   Juniper Networks
   10 Technology Park Drive
   Westford, MA  01886
   USA

   Email: akatlas@juniper.net
   Joel Halpern
   Ericsson

   Email: Joel.Halpern@ericsson.com

   Susan Hares
   ADARA

   Email: shares@ndzh.com

   Dave Ward
   Cisco Systems
   Tasman Drive
   San Jose, CA  95134
   USA

   Email: wardd@cisco.com

   Thomas D. Nadeau
   Juniper Networks
   Brocade

   Email: tnadeau@juniper.net tnadeau@lucidvision.com