From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7921.txt | 2243 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2243 insertions(+) create mode 100644 doc/rfc/rfc7921.txt (limited to 'doc/rfc/rfc7921.txt') 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, + . + + [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, + . + +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, + . + + [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration + Protocol (NETCONF) Access Control Model", RFC 6536, + DOI 10.17487/RFC6536, March 2012, + . + + + + + + +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, + . + + [RFC7223] Bjorklund, M., "A YANG Data Model for Interface + Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, + . + + [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", + RFC 7224, DOI 10.17487/RFC7224, May 2014, + . + + [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", + RFC 7277, DOI 10.17487/RFC7277, June 2014, + . + + [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for + System Management", RFC 7317, DOI 10.17487/RFC7317, August + 2014, . + + [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, + . + + [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] + -- cgit v1.2.3