tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7921

 
 
 

An Architecture for the Interface to the Routing System

Part 2 of 2, p. 20 to 40
Prev RFC Part

 


prevText      Top      ToC       Page 20 
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

Top      Up      ToC       Page 21 
   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 that 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 datastore.  This data is retained by the agent until
   the state is removed by the client, it is overridden by some other
   operation such as CLI, or the device reboots.  Meaningful logging of
   the application and removal of changes are recommended.  I2RS-applied
   changes to the routing element state will not be retained across
   routing element reboot.  The I2RS datastore 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, which may
   be 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 these two types of
   failures, the I2RS agent MUST support two different notifications: a
   notification for the I2RS agent terminating gracefully, and a
   notification for the I2RS agent starting up after an unexpected
   failure.  The two notifications are described below followed by a
   description of their use in unexpected failures and graceful
   shutdowns.

Top      Up      ToC       Page 22 
   NOTIFICATION_I2RS_AGENT_TERMINATING:   This notification reports that
      the associated I2RS agent is shutting down gracefully and that
      I2RS ephemeral state will be removed.  It can optionally include a
      timestamp indicating when the I2RS agent will shut down.  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.

   NOTIFICATION_I2RS_AGENT_STARTING:   This notification signals to the
      I2RS client(s) 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.  (Note: This
      notification will be sent by the I2RS agent to I2RS clients that
      are known by the I2RS agent after a reboot.  How the I2RS agent
      retains the knowledge of these I2RS clients is out of scope of
      this architecture.)

   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 shutdowns:   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.  If the I2RS agent restarts after a graceful
      termination, it will send a NOTIFICATION_I2RS_AGENT_STARTING to
      each cached I2RS client.

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.

Top      Up      ToC       Page 23 
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 Sections 1.2 and 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.  The
   deterministic manner is the result of general I2RS rules, system
   rules, knobs adjusted by operator-applied policy, and the rules
   associated with the YANG data model (often in "MUST" and "WHEN"
   clauses for dependencies).

   The operator-applied policy knobs can determine whether the Local
   Configuration overrides a particular I2RS client's request or vice
   versa.  Normally, most devices will have an operator-applied policy
   that will prioritize the I2RS client's ephemeral configuration
   changes so that ephemeral data overrides the Local Configuration.

   These operator-applied policy knobs can be implemented in many ways.
   One way is for the routing element to configure a priority on the
   Local Configuration and a priority on the I2RS client's write of the
   ephemeral configuration.  The I2RS mechanism would compare the I2RS
   client's priority to write with that priority assigned to the Local
   Configuration in order to determine whether Local Configuration or
   I2RS client's write of ephemeral data wins.

   To make sure the I2RS client's requests are what the operator
   desires, the I2RS data modules have a general rule that, by default,
   the Local Configuration always wins over the I2RS ephemeral
   configuration.

Top      Up      ToC       Page 24 
   The reason for this general rule is if there is no operator-applied
   policy to turn on I2RS ephemeral overwrites of Local Configuration,
   then the I2RS overwrites should not occur.  This general rule allows
   the I2RS agents to be installed in routing systems and the
   communication tested between I2RS clients and I2RS agents without the
   I2RS agent overwriting configuration state.  For more details, see
   the examples below.

   In the case when the I2RS ephemeral state always wins for a data
   model, if there is an I2RS ephemeral state value, it is installed
   instead of the Local Configuration state value.  The Local
   Configuration information is stored so that if/when an I2RS client
   removes I2RS ephemeral state, the Local Configuration state can be
   restored.

   When the Local Configuration always wins, some communication between
   that subsystem and the I2RS agent is still necessary.  As an I2RS
   agent connects to the routing subsystem, the I2RS agent must also
   communicate with the Local Configuration to exchange model
   information so the I2RS agent knows 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.3.1.  Examples of Local Configuration vs. I2RS Ephemeral Configuration

   A set of examples is useful in order to illustrated these
   architecture principles.  Assume there are three routers: Router A,
   Router B, and Router C.  There are two operator-applied policy knobs
   that these three routers must have regarding ephemeral state.

   o  Policy Knob 1: Ephemeral configuration overwrites Local
      Configuration.

   o  Policy Knob 2: Update of Local Configuration value supersedes and
      overwrites the ephemeral configuration.

Top      Up      ToC       Page 25 
   For Policy Knob 1, the routers with an I2RS agent receiving a write
   for an ephemeral entry in a data model must consider the following:

   1.  Does the operator policy allow the ephemeral configuration
       changes to have priority over existing Local Configuration?

   2.  Does the YANG data model have any rules associated with the
       ephemeral configuration (such as the "MUST" or "WHEN" rule)?

   For this example, there is no "MUST" or "WHEN" rule in the data being
   written.

   The policy settings are:

               Policy Knob 1           Policy Knob 2
               ===================     ==================
   Router A    ephemeral has           ephemeral has
               priority                priority

   Router B    Local Configuration     Local Configuration
               has priority            has priority

   Router C    ephemeral has           Local Configuration
               priority                has priority

   Router A has the normal operator policy in Policy Knob 1 and Policy
   Knob 2 that prioritizes ephemeral configuration over Local
   Configuration in the I2RS agent.  An I2RS client sends a write to an
   ephemeral configuration value via an I2RS agent in Router A.  The
   I2RS agent overwrites the configuration value in the intended
   configuration, and the I2RS agent returns an acknowledgement of the
   write.  If the Local Configuration value changes, Router A stays with
   the ephemeral configuration written by the I2RS client.

   Router B's operator has no desire to allow ephemeral writes to
   overwrite Local Configuration even though it has installed an I2RS
   agent.  Router B's policy prioritizes the Local Configuration over
   the ephemeral write.  When the I2RS agent on Router B receives a
   write from an I2RS client, the I2RS agent will check the operator
   Policy Knob 1 and return a response to the I2RS client indicating the
   operator policy did not allow the overwriting of the Local
   Configuration.

   The Router B case demonstrates why the I2RS architecture sets the
   default to the Local Configuration wins.  Since I2RS functionality is
   new, the operator must enable it.  Otherwise, the I2RS ephemeral
   functionality is off.  Router B's operators can install the I2RS code
   and test responses without engaging the I2RS overwrite function.

Top      Up      ToC       Page 26 
   Router C's operator sets Policy Knob 1 for the I2RS clients to
   overwrite existing Local Configuration and Policy Knob 2 for the
   Local Configuration changes to update ephemeral state.  To understand
   why an operator might set the policy knobs this way, consider that
   Router C is under the control of an operator that has a back-end
   system that re-writes the Local Configuration of all systems at 11
   p.m. each night.  Any ephemeral change to the network is only
   supposed to last until 11 p.m. when the next Local Configuration
   changes are rolled out from the back-end system.  The I2RS client
   writes the ephemeral state during the day, and the I2RS agent on
   Router C updates the value.  At 11 p.m., the back-end configuration
   system updates the Local Configuration via NETCONF, and the I2RS
   agent is notified that the Local Configuration updated this value.
   The I2RS agent notifies the I2RS client that the value has been
   overwritten by the Local Configuration.  The I2RS client in this use
   case is a part of an application that tracks any ephemeral state
   changes to make sure all ephemeral changes are included in the next
   configuration run.

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.

Top      Up      ToC       Page 27 
   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)   |   +------------+ *
    *  +-------------------+  +---------------+                  *
    **************************************************************

                    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 directed into).
   Section 6.4.5 discusses information modeling constructs and the range
   of relationship types that are applicable.

Top      Up      ToC       Page 28 
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, per interface, or per context.  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.  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 the link-state database must not be allowed in
   order to preserve network state consistency.

Top      Up      ToC       Page 29 
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 that 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 subclassing, 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
   information 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.

Top      Up      ToC       Page 30 
   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.  I2RS clients that 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 subclass(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 can a subclass 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.2.  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, each
   information model should provide information regarding the following
   questions:

   o  Is X required for the data field to be accepted and applied?

   o  If X is optional, then how does "X" as an optional portion of the
      data field interact with the required aspects of the data field?

   o  Does the data field have defaults for the mandatory portion of the
      field and the optional portions of the field?

   o  Is X required to be within a particular set of values (e.g.,
      range, length of strings)?

   The information model needs to be clear about what read or write
   values are set by the client and what responses or actions are
   required by the agent.  It is important to indicate what is required
   or optional in client values and agent responses/actions.

Top      Up      ToC       Page 31 
6.4.5.3.  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 allow some of the
   defined values to be overwritten.

   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 that 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.4.  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 sections list the
   information relationships that the information models need to
   support.

6.4.5.4.1.  Initialization

   The simplest relationship is that one object instance is initialized
   by copying another.  For example, one may have an object instance
   that represents the default setup for a tunnel, and all new tunnels
   have 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.

Top      Up      ToC       Page 32 
6.4.5.4.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 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.4.3.  Object References

   Sometimes the relationship between objects is stronger.  A valid ARP
   entry has to point to the active interface over which it was derived.
   This is the 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.4.4.  Active References

   There is an even stronger form of coupling between objects if changes
   in one of the two objects are always to be reflected in the state of
   the other.  For example, if a tunnel has an MTU (maximum transmit
   unit), and link MTU changes need to immediately propagate to the
   tunnel MTU, then the tunnel is actively coupled to the link
   interface.  This 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

7.1.  One Control and Data Exchange Protocol

   This I2RS architecture assumes a data-model-driven protocol where the
   data models are defined in YANG 1.1 [YANG1.1] and associated YANG
   based model documents [RFC6991], [RFC7223], [RFC7224], [RFC7277],
   [RFC7317].  Two of the protocols to be expanded to support the I2RS
   protocol are NETCONF [RFC6241] and RESTCONF [RESTCONF].  This helps
   meet the goal of simplicity and thereby enhances deployability.  The
   I2RS protocol may need to use several underlying transports (TCP,
   SCTP (Stream Control Transport Protocol), DCCP (Datagram Congestion
   Control Protocol)), 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

Top      Up      ToC       Page 33 
   data.  Whatever transport is used for the data exchange, it must also
   support suitable congestion-control mechanisms.  The transports
   chosen should be operator and implementor friendly to ease adoption.

   Each version of the I2RS protocol will specify the following: a)
   which transports may be used by the I2RS protocol, b) which
   transports are mandatory to implement, and c) which transports are
   optional to implement.

7.2.  Communication Channels

   Multiple communication channels and multiple types of communication
   channels are required.  There may be a range of requirements (e.g.,
   confidentiality, reliability), and to support the scaling, there may
   need to be channels originating from multiple subcomponents of a
   routing element and/or to multiple parts of an I2RS client.  All such
   communication channels will use the same higher-layer I2RS protocol
   (which combines secure transport and I2RS contextual information).
   The use of additional channels for communication will be coordinated
   between the I2RS client and the I2RS agent using this protocol.

   I2RS protocol communication may be delivered in-band via the routing
   system's data plane.  I2RS protocol communication might be delivered
   out-of-band via a management interface.  Depending on what operations
   are requested, it is possible for the I2RS protocol communication to
   cause the in-band communication channels to stop working; this could
   cause the I2RS agent to become unreachable across that communication
   channel.

7.3.  Capability Negotiation

   The support for different protocol capabilities and I2RS services
   will vary across I2RS clients and Routing Elements supporting I2RS
   agents.  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.

   The protocol capability negotiation can be segmented into the basic
   version negotiation (required to ensure basic communication), and the
   more complex capability exchange that can take place within the base
   protocol mechanisms.  In particular, the more complex protocol and

Top      Up      ToC       Page 34 
   mechanism negotiation can be addressed by defining information models
   for both the I2RS agent and 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.  Scope Policy Specifications

   As Sections 4.1 and 4.2 describe, each I2RS client will have a unique
   identity and may have a secondary identity (see Section 2) to aid in
   troubleshooting.  As Section 4 indicates, all authentication and
   authorization mechanisms are based on the primary identity, which
   links to a role with scope policy for reading data, for writing data,
   and for limiting the resources that can be consumed.  The
   specifications for data scope policy (for read, write, or resources
   consumption) need to specify the data being controlled by the policy,
   and acceptable ranges of values for the data.

7.5.  Connectivity

   An I2RS client may or may not maintain an active communication
   channel with an I2RS agent.  Therefore, an I2RS 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 I2RS client is non-functional.
   When communication is required, the I2RS agent or I2RS client can
   open a new communication channel.

   State held by an I2RS agent that is owned by an I2RS 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.

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

   Some examples of such a mechanism include the following.  In one
   option, the client could request state cleanup if a particular
   transport session is terminated.  The second is to allow state
   expiration, expressed as a policy associated with the I2RS client's

Top      Up      ToC       Page 35 
   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.

7.6.  Notifications

   As with any policy system interacting with the network, the I2RS
   client needs to be able to receive notifications of changes in
   network state.  Notifications here refer to changes that 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 that
   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 I2RS agents to
   send notifications to a number of clients.  The I2RS client should be
   able to filter the specific notifications that will be received; the
   specific types of events and filtering operations can vary by
   information model and need to be specified as part of the information
   model.

   The I2RS information model needs to include representation of these
   events.  As discussed earlier, the capability information in the
   model will allow I2RS clients to understand which events a given I2RS
   agent is capable of generating.

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

7.7.  Information Collection

   One of the other important aspects of 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.

Top      Up      ToC       Page 36 
7.8.  Multi-headed Control

   As 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 should be when such a
   collision happens.  Rather, the architecture mandates that there be
   decidable means by which I2RS agents handle the collisions.  The
   mechanism for ensuring predictability is to have a simple priority
   associated with each I2RS client, and the highest priority change
   remains in effect.  In the case of priority ties, the first I2RS
   client whose attribution is associated with the data will keep
   control.

   In order for this approach to multi-headed control to be useful for
   I2RS clients, it is necessary that an I2RS client can register to
   receive notifications about changes made to writeable data, whose
   state is of specific interest to that I2RS client.  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.

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 methods of error handling for a given message with multiple
   operations that it sends to an I2RS agent:

   Perform all or none:  This traditional SNMP semantic indicates that
      the 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 that caused
      them not to be applied.  This is useful when there are, for
      example, mutual dependencies across operations in the message.

Top      Up      ToC       Page 37 
   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 when the I2RS
      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.

8.  Operational and Manageability Considerations

   In order to facilitate troubleshooting of routing elements
   implementing I2RS agents, the routing elements should provide for a
   mechanism to show actively provisioned I2RS state and other I2RS
   agent internal information.  Note that this information may contain
   highly sensitive material subject to the security considerations of
   any data models implemented by that agent and thus must be protected
   according to those considerations.  Preferably, this mechanism should
   use a different privileged means other than simply connecting as an
   I2RS client to learn the data.  Using a different mechanism should
   improve traceability and failure management.

   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
      I2RS and via a router's configuration needs to be clearly defined.
      As described in this architecture, a simple priority that is
      configured is used to provide sufficient policy flexibility.

   Traceability of Interactions:   The ability to trace the interactions
      of the requests received by the I2RS agent's and actions taken by
      the I2RS agents is needed so that operations can monitor I2RS
      agents during deployment, and troubleshoot software or network
      problems.

Top      Up      ToC       Page 38 
   Notification Subscription Service:  The ability for an I2RS client to
      subscribe to a notification stream pushed from the I2RS agent
      (rather than having I2RS client poll the I2RS agent) provides a
      more scalable notification handling for the I2RS agent-client
      interactions.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC7920]  Atlas, A., Ed., Nadeau, T., Ed., and D. Ward, "Problem
              Statement for the Interface to the Routing System",
              RFC 7920, DOI 10.17487/RFC7920, June 2016,
              <http://www.rfc-editor.org/info/rfc7920>.

9.2.  Informative References

   [I2RS-ENV-SEC]
              Migault, D., Ed., Halpern, J., and S. Hares, "I2RS
              Environment Security Requirements", Work in Progress,
              draft-ietf-i2rs-security-environment-reqs-01, April 2016.

   [I2RS-PROT-SEC]
              Hares, S., Migault, D., and J. Halpern, "I2RS Security
              Related Requirements", Work in Progress, draft-ietf-i2rs-
              protocol-security-requirements-06, May 2016.

   [RESTCONF] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", Work in Progress, draft-ietf-netconf-
              restconf-14, June 2016.

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <http://www.rfc-editor.org/info/rfc6241>.

   [RFC6536]  Bierman, A. and M. Bjorklund, "Network Configuration
              Protocol (NETCONF) Access Control Model", RFC 6536,
              DOI 10.17487/RFC6536, March 2012,
              <http://www.rfc-editor.org/info/rfc6536>.

Top      Up      ToC       Page 39 
   [RFC6991]  Schoenwaelder, J., Ed., "Common YANG Data Types",
              RFC 6991, DOI 10.17487/RFC6991, July 2013,
              <http://www.rfc-editor.org/info/rfc6991>.

   [RFC7223]  Bjorklund, M., "A YANG Data Model for Interface
              Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
              <http://www.rfc-editor.org/info/rfc7223>.

   [RFC7224]  Bjorklund, M., "IANA Interface Type YANG Module",
              RFC 7224, DOI 10.17487/RFC7224, May 2014,
              <http://www.rfc-editor.org/info/rfc7224>.

   [RFC7277]  Bjorklund, M., "A YANG Data Model for IP Management",
              RFC 7277, DOI 10.17487/RFC7277, June 2014,
              <http://www.rfc-editor.org/info/rfc7277>.

   [RFC7317]  Bierman, A. and M. Bjorklund, "A YANG Data Model for
              System Management", RFC 7317, DOI 10.17487/RFC7317, August
              2014, <http://www.rfc-editor.org/info/rfc7317>.

   [RFC7752]  Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
              S. Ray, "North-Bound Distribution of Link-State and
              Traffic Engineering (TE) Information Using BGP", RFC 7752,
              DOI 10.17487/RFC7752, March 2016,
              <http://www.rfc-editor.org/info/rfc7752>.

   [YANG1.1]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
              Work in Progress, draft-ietf-netmod-rfc6020bis-14, June
              2016.

Acknowledgements

   Significant portions of this draft came from "Interface to the
   Routing System Framework" (February 2013) and "A Policy Framework for
   the Interface to the Routing System" (February 2013).

   The authors would like to thank Nitin Bahadur, Shane Amante, Ed
   Crabbe, Ken Gray, Carlos Pignataro, Wes George, Ron Bonica, Joe
   Clarke, Juergen Schoenwalder, Jeff Haas, Jamal Hadi Salim, Scott
   Brim, Thomas Narten, Dean Bogdanovic, Tom Petch, Robert Raszuk,
   Sriganesh Kini, John Mattsson, Nancy Cam-Winget, DaCheng Zhang, Qin
   Wu, Ahmed Abro, Salman Asadullah, Eric Yu, Deborah Brungard, Russ
   Housley, Russ White, Charlie Kaufman, Benoit Claise, Spencer Dawkins,
   and Stephen Farrell for their suggestions and review.

Top      Up      ToC       Page 40 
Authors' Addresses

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

   Email: akatlas@juniper.net


   Joel Halpern
   Ericsson

   Email: Joel.Halpern@ericsson.com


   Susan Hares
   Huawei
   7453 Hickory Hill
   Saline, MI  48176
   United States

   Phone: +1 734-604-0332
   Email: shares@ndzh.com


   Dave Ward
   Cisco Systems
   Tasman Drive
   San Jose, CA  95134
   United States

   Email: wardd@cisco.com


   Thomas D. Nadeau
   Brocade

   Email: tnadeau@lucidvision.com