summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7921.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7921.txt')
-rw-r--r--doc/rfc/rfc7921.txt2243
1 files changed, 2243 insertions, 0 deletions
diff --git a/doc/rfc/rfc7921.txt b/doc/rfc/rfc7921.txt
new file mode 100644
index 0000000..bf9e77a
--- /dev/null
+++ b/doc/rfc/rfc7921.txt
@@ -0,0 +1,2243 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) A. Atlas
+Request for Comments: 7921 Juniper Networks
+Category: Informational J. Halpern
+ISSN: 2070-1721 Ericsson
+ S. Hares
+ Huawei
+ D. Ward
+ Cisco Systems
+ T. Nadeau
+ Brocade
+ June 2016
+
+
+ An Architecture for the Interface to the Routing System
+
+Abstract
+
+ This document describes the IETF architecture for a standard,
+ programmatic interface for state transfer in and out of the Internet
+ routing system. It describes the high-level architecture, the
+ building blocks of this high-level architecture, and their
+ interfaces, with particular focus on those to be standardized as part
+ of the Interface to the Routing System (I2RS).
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7921.
+
+
+
+
+
+
+
+
+
+
+
+
+Atlas, et al. Informational [Page 1]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+Copyright Notice
+
+ Copyright (c) 2016 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atlas, et al. Informational [Page 2]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 1.1. Drivers for the I2RS Architecture ..........................5
+ 1.2. Architectural Overview .....................................6
+ 2. Terminology ....................................................11
+ 3. Key Architectural Properties ...................................13
+ 3.1. Simplicity ................................................13
+ 3.2. Extensibility .............................................14
+ 3.3. Model-Driven Programmatic Interfaces ......................14
+ 4. Security Considerations ........................................15
+ 4.1. Identity and Authentication ...............................17
+ 4.2. Authorization .............................................18
+ 4.3. Client Redundancy .........................................19
+ 4.4. I2RS in Personal Devices ..................................19
+ 5. Network Applications and I2RS Client ...........................19
+ 5.1. Example Network Application: Topology Manager .............20
+ 6. I2RS Agent Role and Functionality ..............................20
+ 6.1. Relationship to Its Routing Element .......................20
+ 6.2. I2RS State Storage ........................................21
+ 6.2.1. I2RS Agent Failure .................................21
+ 6.2.2. Starting and Ending ................................22
+ 6.2.3. Reversion ..........................................23
+ 6.3. Interactions with Local Configuration .....................23
+ 6.3.1. Examples of Local Configuration vs. I2RS
+ Ephemeral Configuration ............................24
+ 6.4. Routing Components and Associated I2RS Services ...........26
+ 6.4.1. Routing and Label Information Bases ................28
+ 6.4.2. IGPs, BGP, and Multicast Protocols .................28
+ 6.4.3. MPLS ...............................................29
+ 6.4.4. Policy and QoS Mechanisms ..........................29
+ 6.4.5. Information Modeling, Device Variation, and
+ Information Relationships ..........................29
+ 6.4.5.1. Managing Variation: Object
+ Classes/Types and Inheritance .............29
+ 6.4.5.2. Managing Variation: Optionality ...........30
+ 6.4.5.3. Managing Variation: Templating ............31
+ 6.4.5.4. Object Relationships ......................31
+ 6.4.5.4.1. Initialization .................31
+ 6.4.5.4.2. Correlation Identification .....32
+ 6.4.5.4.3. Object References ..............32
+ 6.4.5.4.4. Active References ..............32
+ 7. I2RS Client Agent Interface ....................................32
+ 7.1. One Control and Data Exchange Protocol ....................32
+ 7.2. Communication Channels ....................................33
+ 7.3. Capability Negotiation ....................................33
+ 7.4. Scope Policy Specifications ...............................34
+ 7.5. Connectivity ..............................................34
+
+
+
+Atlas, et al. Informational [Page 3]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+ 7.6. Notifications .............................................35
+ 7.7. Information Collection ....................................35
+ 7.8. Multi-headed Control ......................................36
+ 7.9. Transactions ..............................................36
+ 8. Operational and Manageability Considerations ...................37
+ 9. References .....................................................38
+ 9.1. Normative References ......................................38
+ 9.2. Informative References ....................................38
+ Acknowledgements ..................................................39
+ Authors' Addresses ................................................40
+
+1. Introduction
+
+ Routers that form the Internet 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, IS-IS, and BGP to exchange
+ reachability information, topology information, protocol state, and
+ other information about the state of the network with other routers.
+
+ Routers convert all of this information into forwarding entries,
+ which are then used to forward packets and flows between network
+ elements. The forwarding plane and the specified forwarding entries
+ then contain active state information that describes the expected and
+ observed operational behavior of the router and that is also needed
+ by the network applications. Network-oriented applications require
+ easy access to this information to learn the 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. Network-oriented applications also require easy access to an
+ interface, which will allow them to program and control state related
+ to forwarding.
+
+ 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 observation of the routing-related
+ state (for example, a Routing Element RIB manager's state), as well
+ as enabling 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 routing
+ system. This I2RS architecture recognizes that the routing system
+ and a router's Operating System (OS) provide useful mechanisms that
+ applications could harness to accomplish application-level goals.
+ These network-oriented applications can leverage the I2RS
+ programmatic interface to create new ways to combine retrieving
+ Internet routing data, analyzing this data, and setting state within
+ routers.
+
+
+
+Atlas, et al. Informational [Page 4]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+ Fundamental to I2RS are clear data models that define the semantics
+ of the information that can be written and read. I2RS provides a way
+ for applications to customize network behavior while leveraging the
+ existing routing system as desired. I2RS provides a framework for
+ applications (including controller applications) to register and to
+ request the appropriate information for each particular application.
+
+ Although the I2RS architecture is general enough to support
+ information and data models for a variety of data, and aspects of the
+ I2RS solution may be useful in domains other than routing, I2RS and
+ this document are specifically focused on an interface for routing
+ data.
+
+ Security is a concern for any new I2RS. Section 4 provides an
+ overview of the security considerations for the I2RS architecture.
+ The detailed requirements for I2RS protocol security are contained in
+ [I2RS-PROT-SEC], and the detailed security requirements for
+ environment in which the I2RS protocol exists are contained in
+ [I2RS-ENV-SEC].
+
+1.1. Drivers for the I2RS Architecture
+
+ There are four key drivers that shape the I2RS architecture. First
+ is the need for an interface that is programmatic and asynchronous
+ and that offers fast, interactive access for atomic operations.
+ Second is the access to structured information and state that is
+ frequently not directly configurable or modeled in existing
+ implementations or configuration protocols. Third is the ability to
+ subscribe to structured, filterable event notifications from the
+ router. Fourth, the operation of I2RS 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, the key
+ properties of which are described in Section 5 of [RFC7920].
+
+ The I2RS architecture facilitates obtaining information from the
+ router. The I2RS architecture provides the ability to not only read
+ specific information, but also to subscribe to targeted information
+ streams, filtered events, and thresholded events.
+
+ Such an interface also facilitates the injection of ephemeral state
+ into the routing system. Ephemeral state on a router is the state
+ that does not survive the reboot of a routing device or the reboot of
+ the software handling the I2RS software on a routing device. A non-
+ routing protocol or application could inject state into a routing
+ element via the state-insertion functionality of I2RS and that state
+ could then be distributed in a routing or signaling protocol and/or
+
+
+
+Atlas, et al. Informational [Page 5]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+ be used locally (e.g., to program the co-located forwarding plane).
+ I2RS will only permit modification of state that would be possible to
+ modify via Local Configuration; no direct manipulation of protocol-
+ internal, dynamically determined data is envisioned.
+
+1.2. Architectural Overview
+
+ Figure 1 shows the basic architecture for I2RS between applications
+ using I2RS, their associated I2RS clients, and I2RS agents.
+ Applications access I2RS services through I2RS clients. A single
+ I2RS client can provide access to one or more applications. This
+ figure also shows the types of data models associated with the
+ routing system (dynamic configuration, static configuration, Local
+ Configuration, and routing and signaling configuration) that the I2RS
+ agent data models may access or augment.
+
+ Figure 1 is similar to Figure 1 in [RFC7920], but the figure in this
+ document shows additional detail on how the applications utilize I2RS
+ clients to interact with I2RS agents. It also shows a logical view
+ of the data models associated with the routing system rather than a
+ functional view (RIB, Forwarding Information Base (FIB), topology,
+ policy, routing/signaling protocols, etc.)
+
+ In Figure 1, Clients A and B each provide access to a single
+ application (Applications A and B, respectively), while Client P
+ provides access to multiple applications.
+
+ Applications can access I2RS services through local or remote
+ clients. A local client operates on the same physical box as the
+ routing system. In contrast, a remote client operates across the
+ network. In the figure, Applications A and B access I2RS services
+ through local clients, while Applications C, D, and E access I2RS
+ services through a remote client. The details of how applications
+ communicate with a remote client is out of scope for I2RS.
+
+ An I2RS client can access one or more I2RS agents. In Figure 1,
+ Clients B and P access I2RS agents 1 and 2. Likewise, an I2RS agent
+ can provide service to one or more clients. In this 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.
+
+
+
+
+
+Atlas, et al. Informational [Page 6]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+ The I2RS agent provides read and write access to selected data on the
+ routing element that are organized into I2RS services. Section 4
+ describes how access is mediated by authentication and access control
+ mechanisms. Figure 1 shows I2RS agents being able to write ephemeral
+ static state (e.g., RIB entries) and to read from dynamic static
+ (e.g., MPLS Label Switched Path Identifier (LSP-ID) or number of
+ active BGP peers).
+
+ 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. One example of a notification
+ of such an event (which is unrelated to an object creation,
+ modification or deletion) is when a next hop in the RIB is resolved
+ in a way that allows it to be used by a RIB manager for installation
+ in the forwarding plane as part of a particular route. Please see
+ Sections 7.6 and 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atlas, et al. Informational [Page 7]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+ ****************** ***************** *****************
+ * Application C * * Application D * * Application E *
+ ****************** ***************** *****************
+ ^ ^ ^
+ |--------------| | |--------------|
+ | | |
+ v v v
+ ***************
+ * Client P *
+ ***************
+ ^ ^
+ | |-------------------------|
+ *********************** | *********************** |
+ * Application A * | * Application B * |
+ * * | * * |
+ * +----------------+ * | * +----------------+ * |
+ * | Client A | * | * | Client B | * |
+ * +----------------+ * | * +----------------+ * |
+ ******* ^ ************* | ***** ^ ****** ^ ****** |
+ | | | | |
+ | |-------------| | | |-----|
+ | | -----------------------| | |
+ | | | | |
+ ************ v * v * v ********* ***************** v * v ********
+ * +---------------------+ * * +---------------------+ *
+ * | Agent 1 | * * | Agent 2 | *
+ * +---------------------+ * * +---------------------+ *
+ * ^ ^ ^ ^ * * ^ ^ ^ ^ *
+ * | | | | * * | | | | *
+ * v | | v * * v | | v *
+ * +---------+ | | +--------+ * * +---------+ | | +--------+ *
+ * | Routing | | | | Local | * * | Routing | | | | Local | *
+ * | and | | | | Config | * * | and | | | | Config | *
+ * |Signaling| | | +--------+ * * |Signaling| | | +--------+ *
+ * +---------+ | | ^ * * +---------+ | | ^ *
+ * ^ | | | * * ^ | | | *
+ * | |----| | | * * | |----| | | *
+ * v | v v * * v | v v *
+ * +----------+ +------------+ * * +----------+ +------------+ *
+ * | Dynamic | | Static | * * | Dynamic | | Static | *
+ * | System | | System | * * | System | | System | *
+ * | State | | State | * * | State | | State | *
+ * +----------+ +------------+ * * +----------+ +------------+ *
+ * * * *
+ * Routing Element 1 * * Routing Element 2 *
+ ******************************** ********************************
+
+ Figure 1: Architecture of I2RS Clients and Agents
+
+
+
+Atlas, et al. Informational [Page 8]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+ Routing Element: A Routing Element implements some subset of the
+ routing system. It does not need to have a forwarding plane
+ associated with it. Examples of Routing Elements can include:
+
+ * A router with a forwarding plane and RIB Manager that runs
+ IS-IS, OSPF, BGP, PIM, etc.,
+
+ * A BGP speaker acting as a Route Reflector,
+
+ * A Label Switching Router (LSR) that implements RSVP-TE,
+ OSPF-TE, and the Path Computation Element (PCE) Communication
+ Protocol (PCEP) and has a forwarding plane and associated RIB
+ Manager, and
+
+ * A server that runs IS-IS, OSPF, and BGP and uses Forwarding and
+ Control Element Separation (ForCES) to control a remote
+ forwarding plane.
+
+ A Routing Element may be locally managed, whether via command-line
+ interface (CLI), SNMP, or the Network Configuration Protocol
+ (NETCONF).
+
+ Routing and Signaling: This block represents that portion of the
+ Routing Element that implements part of the Internet routing
+ system. It includes not merely standardized protocols (i.e.,
+ IS-IS, OSPF, BGP, PIM, RSVP-TE, LDP, etc.), but also the RIB
+ Manager layer.
+
+ Local Configuration: The black box behavior for interactions between
+ the ephemeral state that I2RS installs into the routing element;
+ Local Configuration is defined by this document and the behaviors
+ specified by the I2RS protocol.
+
+ Dynamic System State: An I2RS agent needs access to state on a
+ routing element beyond what is contained in the routing subsystem.
+ Such state may include various counters, statistics, flow data,
+ and local events. This is the subset of operational state that is
+ needed by network applications based on I2RS that is not contained
+ in the routing and signaling information. How this information is
+ provided to the I2RS agent is out of scope, but the standardized
+ information and data models for what is exposed are part of I2RS.
+
+ Static System State: An I2RS agent needs access to static state on a
+ routing element beyond what is contained in the routing subsystem.
+ An example of such state is specifying queueing behavior for an
+ interface or traffic. How the I2RS agent modifies or obtains this
+ information is out of scope, but the standardized information and
+ data models for what is exposed are part of I2RS.
+
+
+
+Atlas, et al. Informational [Page 9]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+ I2RS agent: See the definition in Section 2.
+
+ Application: A network application that needs to observe the network
+ or manipulate the network to achieve its service requirements.
+
+ I2RS client: See the definition in Section 2.
+
+ As can be seen in Figure 1, an I2RS client can communicate with
+ multiple I2RS agents. Similarly, an I2RS agent may communicate with
+ multiple I2RS clients -- whether to respond to their requests, to
+ send notifications, etc. Timely notifications are critical so that
+ several simultaneously operating applications have up-to-date
+ information on the state of the network.
+
+ As can also be seen in Figure 1, an I2RS agent may communicate with
+ multiple clients. Each client may send the agent a variety of write
+ operations. In order to keep the protocol simple, two clients should
+ not attempt to write (modify) the same piece of information on an
+ I2RS agent. This is considered an error. However, such collisions
+ may happen and Section 7.8 ("Multi-headed Control") describes how the
+ I2RS agent resolves collision by first utilizing priority to resolve
+ collisions and second by servicing the requests in a first-in, first-
+ served basis. The I2RS architecture includes this definition of
+ behavior for this case simply for predictability, not because this is
+ an intended result. This predictability will simplify error handling
+ and suppress oscillations. If additional error cases beyond this
+ simple treatment are required, these error cases should be resolved
+ by the network applications and management systems.
+
+ In contrast, although multiple I2RS clients may need to supply data
+ into the same list (e.g., a prefix or filter list), this is not
+ considered an error and must be correctly handled. The nuances so
+ that writers do not normally collide should be handled in the
+ information models.
+
+ The architectural goal for I2RS is that such errors should produce
+ predictable behaviors and be reportable to interested clients. The
+ details of the associated policy is discussed in Section 7.8. The
+ same policy mechanism (simple priority per I2RS client) applies to
+ interactions between the I2RS agent and the CLI/SNMP/NETCONF as
+ described in Section 6.3.
+
+ In addition, it must be noted that there may be indirect interactions
+ between write operations. A basic example of this is when two
+ different but overlapping prefixes are written with different
+ forwarding behavior. Detection and avoidance of such interactions is
+ outside the scope of the I2RS work and is left to agent design and
+ implementation.
+
+
+
+Atlas, et al. Informational [Page 10]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+2. Terminology
+
+ The following terminology is used in this document.
+
+ agent or I2RS agent: An I2RS agent provides the supported I2RS
+ services from the local system's routing subsystems by interacting
+ with the routing element to provide specified behavior. The I2RS
+ agent understands the I2RS protocol and can be contacted by I2RS
+ clients.
+
+ client or I2RS client: A client implements the I2RS protocol, uses
+ it to communicate with I2RS agents, and uses the I2RS services to
+ accomplish a task. It interacts with other elements of the
+ policy, provisioning, and configuration system by means outside of
+ the scope of the I2RS effort. It interacts with the I2RS agents
+ to collect information from the routing and forwarding system.
+ Based on the information and the policy-oriented interactions, the
+ I2RS client may also interact with I2RS agents to modify the state
+ of their associated routing systems to achieve operational goals.
+ An I2RS client can be seen as the part of an application that uses
+ and supports I2RS and could be a software library.
+
+ service or I2RS service: For the purposes of I2RS, a service refers
+ to a set of related state access functions together with the
+ policies that control their usage. The expectation is that a
+ service will be represented by a data model. For instance, 'RIB
+ service' could be an example of a service that gives access to
+ state held in a device's RIB.
+
+ read scope: The read scope of an I2RS client within an I2RS agent
+ is the set of information that the I2RS client is authorized to
+ read within the I2RS agent. The read scope specifies the access
+ restrictions to both see the existence of data and read the value
+ of that data.
+
+ notification scope: The notification scope is the set of events and
+ associated information that the I2RS client can request be pushed
+ by the I2RS agent. I2RS clients have the ability to register for
+ specific events and information streams, but must be constrained
+ by the access restrictions associated with their notification
+ scope.
+
+ write scope: The write scope is the set of field values that 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.
+
+
+
+
+
+Atlas, et al. Informational [Page 11]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+ scope: When unspecified as either read scope, write scope, or
+ notification scope, the term "scope" applies to the read scope,
+ write scope, and notification scope.
+
+ resources: A resource is an I2RS-specific use of memory, storage,
+ or execution that a client may consume due to its I2RS operations.
+ The amount of each such resource that a client may consume in the
+ context of a particular agent may be constrained based upon the
+ client's security role. An example of such a resource could
+ include the number of notifications registered for. These are not
+ protocol-specific resources or network-specific resources.
+
+ role or security role: A security role specifies the scope,
+ resources, priorities, etc., that a client or agent has. If an
+ identity has multiple roles in the security system, the identity
+ is permitted to perform any operations any of those roles permit.
+ Multiple identities may use the same security role.
+
+ identity: A client is associated with exactly one specific
+ identity. State can be attributed to a particular identity. It
+ is possible for multiple communication channels to use the same
+ identity; in that case, the assumption is that the associated
+ client is coordinating such communication.
+
+ identity and scope: A single identity can be associated with
+ multiple roles. Each role has its own scope, and an identity
+ associated with multiple roles can use the combined scope of all
+ its roles. More formally, each identity has:
+
+ * a read scope that is the logical OR of the read scopes
+ associated with its roles,
+
+ * a write scope that is the logical OR of the write scopes
+ associated with its roles, and
+
+ * a notification scope that is the logical OR of the notification
+ scopes associated with its roles.
+
+ secondary identity: An I2RS client may supply a secondary opaque
+ identifier for a secondary identity that is not interpreted by the
+ I2RS agent. An example of the use of the secondary opaque
+ identifier 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.
+
+
+
+
+
+
+
+Atlas, et al. Informational [Page 12]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+ ephemeral data: Ephemeral data is data that does not persist across
+ a reboot (software or hardware) or a power on/off condition.
+ Ephemeral data can be configured data or data recorded from
+ operations of the router. Ephemeral configuration data also has
+ the property that a system cannot roll back to a previous
+ ephemeral configuration state.
+
+ group: The NETCONF Access Control Model [RFC6536] uses the term
+ "group" in terms of an administrative group that supports the
+ well-established distinction between a root account and other
+ types of less-privileged conceptual user accounts. "Group" still
+ refers to a single identity (e.g., root) that is shared by a group
+ of users.
+
+ routing system/subsystem: A routing system or subsystem is a set of
+ software and/or hardware that determines where packets are
+ forwarded. The I2RS agent is a component of a routing system.
+ The term "packets" may be qualified to be layer 1 frames, layer 2
+ frames, or layer 3 packets. The phrase "Internet routing system"
+ implies the packets that have IP as layer 3. A routing
+ "subsystem" indicates that the routing software/hardware is only
+ the subsystem of another larger system.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+3. Key Architectural Properties
+
+ Several key architectural properties for the I2RS protocol are
+ elucidated below (simplicity, extensibility, and model-driven
+ programmatic interfaces). However, some architectural properties
+ such as performance and scaling are not described below because they
+ are discussed in [RFC7920] and because they may vary based on the
+ particular use cases.
+
+3.1. Simplicity
+
+ There have been many efforts over the years to improve access to the
+ information available to the routing and forwarding system. Making
+ such information visible and usable to network management and
+ applications has many well-understood benefits. There are two
+ related challenges in doing so. First, the quantity and diversity of
+ information potentially available is very large. Second, the
+ variation both in the structure of the data and in the kinds of
+ operations required tends to introduce protocol complexity.
+
+
+
+
+
+Atlas, et al. Informational [Page 13]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+ While the types of operations contemplated here are complex in their
+ nature, it is critical that I2RS be easily deployable and robust.
+ Adding complexity beyond what is needed to satisfy well known and
+ understood requirements would hinder the ease of implementation, the
+ robustness of the protocol, and the deployability of the protocol.
+ Overly complex data models tend to ossify information sets by
+ attempting to describe and close off every possible option,
+ complicating extensibility.
+
+ Thus, one of the key aims for I2RS is to 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?" If we need the complexity, we should
+ ask ourselves, "Is this the simplest way to provide this complexity
+ in the I2RS external interface?"
+
+3.2. Extensibility
+
+ Extensibility of the protocol and data model is very important. In
+ particular, given the necessary scope limitations of the initial
+ work, it is critical that the initial design include strong support
+ for extensibility.
+
+ The scope of I2RS work is being designed in phases to provide
+ deliverable and deployable results at every phase. Each phase will
+ have a specific set of requirements, and the I2RS protocol and data
+ models will progress toward these requirements. Therefore, it is
+ clearly desirable for the I2RS data models to be easily and highly
+ extensible to represent additional aspects of the network elements or
+ network systems. It should be easy to integrate data models from
+ I2RS with other data. This reinforces the criticality of designing
+ the data models to be highly extensible, preferably in a regular and
+ simple fashion.
+
+ The I2RS Working Group is defining operations for the I2RS protocol.
+ It would be optimistic to assume that more and different ones may not
+ be needed when the scope of I2RS increases. Thus, it is important to
+ consider extensibility not only of the underlying services' data
+ models, but also of the primitives and protocol operations.
+
+3.3. Model-Driven Programmatic Interfaces
+
+ A critical component of I2RS is the standard information and data
+ models with their associated semantics. While many components of the
+ routing system are standardized, associated data models for them are
+ not yet available. Instead, each router uses different information,
+ different mechanisms, and different CLI, which makes a standard
+ interface for use by applications extremely cumbersome to develop and
+
+
+
+Atlas, et al. Informational [Page 14]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+ 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 data-model-
+ focused processing of management data that provides modular
+ implementation in I2RS clients and I2RS agents. The I2RS client only
+ needs to implement the models the I2RS client is able to access. The
+ I2RS agent only needs to implement the data models the I2RS agent
+ supports.
+
+ Second, tools can automate checking and manipulating data; this is
+ particularly valuable for both extensibility and for the ability to
+ easily manipulate and check proprietary data models.
+
+ The different services provided by I2RS can correspond to separate
+ data models. An I2RS agent may indicate which data models are
+ supported.
+
+ The purpose of the data model is to provide a definition of the
+ information regarding the routing system that can be used in
+ operational networks. If routing information is being modeled for
+ the first time, a logical information model may be standardized prior
+ to creating the data model.
+
+4. Security Considerations
+
+ This I2RS architecture describes interfaces that clearly require
+ serious consideration of security. As an architecture, I2RS has been
+ designed to reuse existing protocols that carry network management
+ information. Two of the existing protocols that are being reused for
+ the I2RS protocol version 1 are NETCONF [RFC6241] and RESTCONF
+ [RESTCONF]. Additional protocols may be reused in future versions of
+ the I2RS protocol.
+
+ The I2RS protocol design process will be to specify additional
+ requirements (including security) for the existing protocols in order
+ in order to support the I2RS architecture. After an existing
+ protocol (e.g., NETCONF or RESTCONF) has been altered to fit the I2RS
+ requirements, then it will be reviewed to determine if it meets these
+ requirements. During this review of changes to existing protocols to
+ serve the I2RS architecture, an in-depth security review of the
+ revised protocol should be done.
+
+ Due to the reuse strategy of the I2RS architecture, this security
+ section describes the assumed security environment for I2RS with
+ additional details on a) identity and authentication, b)
+ authorization, and c) client redundancy. Each protocol proposed for
+
+
+
+Atlas, et al. Informational [Page 15]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+ inclusion as an I2RS protocol will need to be evaluated for the
+ security constraints of the protocol. The detailed requirements for
+ the I2RS protocol and the I2RS security environment will be defined
+ within these global security environments.
+
+ The I2RS protocol security requirements for I2RS protocol version 1
+ are contained in [I2RS-PROT-SEC], and the global I2RS security
+ environment requirements are contained [I2RS-ENV-SEC].
+
+ First, here is a brief description of the assumed security
+ environment for I2RS. The I2RS agent associated with a Routing
+ Element is a trusted part of that Routing Element. For example, it
+ may be part of a vendor-distributed signed software image for the
+ entire Routing Element, or it may be a trusted signed application
+ that an operator has installed. The I2RS agent is assumed to have a
+ separate authentication and authorization channel by which it can
+ validate both the identity and permissions associated with an I2RS
+ client. To support numerous and speedy interactions between the I2RS
+ agent and I2RS client, it is assumed that the I2RS agent can also
+ cache that particular I2RS clients are trusted and their associated
+ authorized scope. This implies that the permission information may
+ be old either in a pull model until the I2RS agent re-requests it or
+ in a push model until the authentication and authorization channel
+ can notify the I2RS agent of changes.
+
+ Mutual authentication between the I2RS client and I2RS agent is
+ required. An I2RS client must be able to trust that the I2RS agent
+ is attached to the relevant Routing Element so that write/modify
+ operations are correctly applied and so that information received
+ from the I2RS agent can be trusted by the I2RS client.
+
+ An I2RS client is not automatically trustworthy. Each I2RS client is
+ associated with an identity with a set of scope limitations.
+ Applications using an I2RS client should be aware that the scope
+ limitations of an I2RS client are based on its identity (see
+ Section 4.1) and the assigned role that the identity has. A role
+ sets specific authorization limits on the actions that an I2RS client
+ can successfully request of an I2RS agent (see Section 4.2). For
+ example, one I2RS client may only be able to read a static route
+ table, but another client may be able add an ephemeral route to the
+ static route table.
+
+ If the I2RS client is acting as a broker for multiple applications,
+ then managing the security, authentication, and authorization for
+ that communication is out of scope; nothing prevents the broker from
+ using the I2RS protocol and a separate authentication and
+ authorization channel from being used. Regardless of the mechanism,
+ an I2RS client that is acting as a broker is responsible for
+
+
+
+Atlas, et al. Informational [Page 16]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+ determining that applications using it are trusted and permitted to
+ make the particular requests.
+
+ Different levels of integrity, confidentiality, and replay protection
+ are relevant for different aspects of I2RS. The primary
+ communication channel that is used for client authentication and then
+ used by the client to write data requires integrity, confidentiality
+ and replay protection. Appropriate selection of a default required
+ transport protocol is the preferred way of meeting these
+ requirements.
+
+ Other communications via I2RS may not require integrity,
+ confidentiality, and replay protection. For instance, if an I2RS
+ client subscribes to an information stream of prefix announcements
+ from OSPF, those may require integrity but probably not
+ confidentiality or replay protection. Similarly, an information
+ stream of interface statistics may not even require guaranteed
+ delivery. In Section 7.2, additional logins regarding multiple
+ communication channels and their use is provided. From the security
+ perspective, it is critical to realize that an I2RS agent may open a
+ new communication channel based upon information provided by an I2RS
+ client (as described in Section 7.2). For example, an I2RS client
+ may request notifications of certain events, and the agent will open
+ a communication channel to report such events. Therefore, to avoid
+ an indirect attack, such a request must be done in the context of an
+ authenticated and authorized client whose communications cannot have
+ been altered.
+
+4.1. Identity and Authentication
+
+ As discussed above, all control exchanges between the I2RS client and
+ agent should be authenticated and integrity-protected (such that the
+ contents cannot be changed without detection). Further, manipulation
+ of the system must be accurately attributable. In an ideal
+ architecture, even information collection and notification should be
+ protected; this may be subject to engineering trade-offs during the
+ design.
+
+ I2RS clients may be operating on behalf of other applications. While
+ those applications' identities are not needed for authentication or
+ authorization, each application should have a unique opaque
+ identifier that can be provided by the I2RS client to the I2RS agent
+ for purposes of tracking attribution of operations to an application
+ identifier (and from that to the application's identity). This
+ tracking of operations to an application supports I2RS functionality
+ for tracing actions (to aid troubleshooting in routers) and logging
+ of network changes.
+
+
+
+
+Atlas, et al. Informational [Page 17]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+4.2. Authorization
+
+ All operations using I2RS, both observation and manipulation, should
+ be subject to appropriate authorization controls. Such authorization
+ is based on the identity and assigned role of the I2RS client
+ performing the operations and the I2RS agent in the network element.
+ Multiple identities may use the same role(s). As noted in the
+ definitions of "identity" and "role" above, if multiple roles are
+ associated with an identity then the identity is authorized to
+ perform any operation authorized by any of its roles.
+
+ I2RS agents, in performing information collection and manipulation,
+ will be acting on behalf of the I2RS clients. As such, each
+ operation authorization will be based on the lower of the two
+ permissions of the agent itself and of the authenticated client. The
+ mechanism by which this authorization is applied within the device is
+ outside of the scope of I2RS.
+
+ The appropriate or necessary level of granularity for scope can
+ depend upon the particular I2RS service and the implementation's
+ granularity. An approach to a similar access control problem is
+ defined in the NETCONF Access Control Model (NACM) [RFC6536]; it
+ allows arbitrary access to be specified for a data node instance
+ identifier while defining meaningful manipulable defaults. The
+ identity within NACM [RFC6536] can be specified as either a user name
+ or a group user name (e.g., Root), and this name is linked a scope
+ policy that is contained in a set of access control rules.
+ Similarly, it is expected the I2RS identity links to one role that
+ has a scope policy specified by a set of access control rules. This
+ scope policy can be provided via Local Configuration, exposed as an
+ I2RS service for manipulation by authorized clients, or via some
+ other method (e.g., Authentication, Authorization, and Accounting
+ (AAA) service)
+
+ While the I2RS agent allows access based on the I2RS client's scope
+ policy, this does not mean the access is required to arrive on a
+ particular transport connection or from a particular I2RS client by
+ the I2RS architecture. The operator-applied scope policy may or may
+ not restrict the transport connection or the identities that can
+ access a local I2RS agent.
+
+ When an I2RS client is authenticated, its identity is provided to the
+ I2RS agent, and this identity links to a role that links to the scope
+ policy. Multiple identities may belong to the same role; for
+ example, such a role might be an Internal-Routes-Monitor that allows
+ reading of the portion of the I2RS RIB associated with IP prefixes
+ used for internal device addresses in the AS.
+
+
+
+
+Atlas, et al. Informational [Page 18]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+4.3. Client Redundancy
+
+ I2RS must support client redundancy. At the simplest, this can be
+ handled by having a primary and a backup network application that
+ both use the same client identity and can successfully authenticate
+ as such. Since I2RS does not require a continuous transport
+ connection and supports multiple transport sessions, this can provide
+ some basic redundancy. However, it does not address the need for
+ troubleshooting and logging of network changes to be informed about
+ which network application is actually active. At a minimum, basic
+ transport information about each connection and time can be logged
+ with the identity.
+
+4.4. I2RS in Personal Devices
+
+ If an I2RS agent or I2RS client is tightly correlated with a person
+ (such as if an I2RS agent is running on someone's phone to control
+ tethering), then this usage can raise privacy issues, over and above
+ the security issues that normally need to be handled in I2RS. One
+ example of an I2RS interaction that could raise privacy issues is if
+ the I2RS interaction enabled easier location tracking of a person's
+ phone. The I2RS protocol and data models should consider if privacy
+ issues can arise when clients or agents are used for such use cases.
+
+5. Network Applications and I2RS Client
+
+ I2RS is expected to be used by network-oriented applications in
+ different architectures. While the interface between a network-
+ oriented application and the I2RS client is outside the scope of
+ I2RS, considering the different architectures is important to
+ sufficiently specify I2RS.
+
+ In the simplest architecture of direct access, a network-oriented
+ application has an I2RS client as a library or driver for
+ communication with routing elements.
+
+ In the broker architecture, multiple network-oriented applications
+ communicate in an unspecified fashion to a broker application that
+ contains an I2RS client. That broker application requires additional
+ functionality for authentication and authorization of the network-
+ oriented applications; such functionality is out of scope for I2RS,
+ but similar considerations to those described in Section 4.2 do
+ apply. As discussed in Section 4.1, the broker I2RS client should
+ determine distinct opaque identifiers for each network-oriented
+ application that is using it. The broker I2RS client can pass along
+ the appropriate value as a secondary identifier, which can be used
+ for tracking attribution of operations.
+
+
+
+
+Atlas, et al. Informational [Page 19]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+ In a third architecture, a routing element or network-oriented
+ application that uses an I2RS client to access services on a
+ different routing element may also contain an I2RS agent to provide
+ services to other network-oriented applications. However, where the
+ needed information and data models for those services differs from
+ that of a conventional routing element, those models are, at least
+ initially, out of scope for I2RS. The following section describes an
+ example of such a network application.
+
+5.1. Example Network Application: Topology Manager
+
+ A Topology Manager includes an I2RS client that uses the I2RS data
+ models and protocol to collect information about the state of the
+ network by communicating directly with one or more I2RS agents. From
+ these I2RS agents, the Topology Manager collects routing
+ configuration and operational data, such as interface and Label
+ Switched Path (LSP) information. In addition, the Topology Manager
+ may collect link-state data in several ways -- via I2RS models, by
+ peering with BGP-LS [RFC7752], or by listening into the IGP.
+
+ The set of functionality and collected information that is the
+ Topology Manager may be embedded as a component of a larger
+ application, such as a path computation application. As a stand-
+ alone application, the Topology Manager could be useful to other
+ network applications by providing a coherent picture of the network
+ state accessible via another interface. That interface might use the
+ same I2RS protocol and could provide a topology service using
+ extensions to the I2RS data models.
+
+6. I2RS Agent Role and Functionality
+
+ The I2RS agent is part of a routing element. As such, it has
+ relationships with that routing element as a whole and with various
+ components of that routing element.
+
+6.1. Relationship to Its Routing Element
+
+ A Routing Element may be implemented with a wide variety of different
+ architectures: an integrated router, a split architecture,
+ distributed architecture, etc. The architecture does not need to
+ affect the general I2RS agent behavior.
+
+ For scalability and generality, the I2RS agent may be responsible for
+ collecting and delivering large amounts of data from various parts of
+ the routing element. Those parts may or may not actually be part of
+ a single physical device. Thus, for scalability and robustness, it
+ is important that the architecture allow for a distributed set of
+ reporting components providing collected data from the I2RS agent
+
+
+
+Atlas, et al. Informational [Page 20]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+Atlas, et al. Informational [Page 21]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+ 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.
+
+
+
+
+Atlas, et al. Informational [Page 22]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+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.
+
+
+
+
+
+Atlas, et al. Informational [Page 23]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+Atlas, et al. Informational [Page 24]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+ 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.
+
+
+
+Atlas, et al. Informational [Page 25]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atlas, et al. Informational [Page 26]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+ 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.
+
+
+
+
+
+
+
+Atlas, et al. Informational [Page 27]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+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.
+
+
+
+Atlas, et al. Informational [Page 28]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+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.
+
+
+
+
+
+Atlas, et al. Informational [Page 29]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+Atlas, et al. Informational [Page 30]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+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.
+
+
+
+
+Atlas, et al. Informational [Page 31]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+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
+
+
+
+
+
+Atlas, et al. Informational [Page 32]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+ 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
+
+
+
+Atlas, et al. Informational [Page 33]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+ 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
+
+
+
+
+Atlas, et al. Informational [Page 34]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+ 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.
+
+
+
+
+
+Atlas, et al. Informational [Page 35]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+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.
+
+
+
+
+Atlas, et al. Informational [Page 36]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+ 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.
+
+
+
+
+Atlas, et al. Informational [Page 37]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+ 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>.
+
+
+
+
+
+
+Atlas, et al. Informational [Page 38]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+ [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.
+
+
+
+
+
+
+
+Atlas, et al. Informational [Page 39]
+
+RFC 7921 I2RS Architecture June 2016
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+Atlas, et al. Informational [Page 40]
+