--- 1/draft-ietf-i2rs-architecture-13.txt 2016-04-21 23:15:57.413818506 -0700 +++ 2/draft-ietf-i2rs-architecture-14.txt 2016-04-21 23:15:57.497820588 -0700 @@ -1,50 +1,51 @@ Network Working Group A. Atlas Internet-Draft Juniper Networks Intended status: Informational J. Halpern -Expires: August 23, 2016 Ericsson +Expires: October 23, 2016 Ericsson S. Hares Huawei D. Ward Cisco Systems T. Nadeau Brocade - February 20, 2016 + April 21, 2016 An Architecture for the Interface to the Routing System - draft-ietf-i2rs-architecture-13 + draft-ietf-i2rs-architecture-14 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 basic architecture, the components, - and their interfaces with particular focus on those to be - standardized as part of the Interface to Routing System (I2RS). + 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 Routing System (I2RS). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 23, 2016. + This Internet-Draft will expire on October 23, 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 @@ -53,68 +54,73 @@ include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Drivers for the I2RS Architecture . . . . . . . . . . . . 4 1.2. Architectural Overview . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 3. Key Architectural Properties . . . . . . . . . . . . . . . . 11 - 3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 11 - 3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12 - 3.3. Model-Driven Programmatic Interfaces . . . . . . . . . . 12 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 4.1. Identity and Authentication . . . . . . . . . . . . . . . 15 - 4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 15 - 4.3. Client Redundancy . . . . . . . . . . . . . . . . . . . . 16 - 5. Network Applications and I2RS Client . . . . . . . . . . . . 16 - 5.1. Example Network Application: Topology Manager . . . . . . 17 - 6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 17 - 6.1. Relationship to its Routing Element . . . . . . . . . . . 17 - 6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 18 - 6.2.1. I2RS Agent Failure . . . . . . . . . . . . . . . . . 18 - 6.2.2. Starting and Ending . . . . . . . . . . . . . . . . . 19 - 6.2.3. Reversion . . . . . . . . . . . . . . . . . . . . . . 19 - 6.3. Interactions with Local Configuration . . . . . . . . . . 20 - 6.4. Routing Components and Associated I2RS Services . . . . . 21 - 6.4.1. Routing and Label Information Bases . . . . . . . . . 22 - 6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 22 - 6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 23 - 6.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 23 + 3. Key Architectural Properties . . . . . . . . . . . . . . . . 12 + 3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 12 + 3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 13 + 3.3. Model-Driven Programmatic Interfaces . . . . . . . . . . 13 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 4.1. Identity and Authentication . . . . . . . . . . . . . . . 16 + 4.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 16 + 4.3. Client Redundancy . . . . . . . . . . . . . . . . . . . . 17 + 4.4. I2RS in Personal Devices . . . . . . . . . . . . . . . . 18 + 5. Network Applications and I2RS Client . . . . . . . . . . . . 18 + 5.1. Example Network Application: Topology Manager . . . . . . 19 + 6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 19 + 6.1. Relationship to its Routing Element . . . . . . . . . . . 19 + 6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 20 + 6.2.1. I2RS Agent Failure . . . . . . . . . . . . . . . . . 20 + 6.2.2. Starting and Ending . . . . . . . . . . . . . . . . . 21 + 6.2.3. Reversion . . . . . . . . . . . . . . . . . . . . . . 21 + 6.3. Interactions with Local Configuration . . . . . . . . . . 22 + 6.3.1. Examples of Local Configuration vs. I2RS Ephemeral + Configuration . . . . . . . . . . . . . . . . . . . . 23 + 6.4. Routing Components and Associated I2RS Services . . . . . 25 + 6.4.1. Routing and Label Information Bases . . . . . . . . . 26 + 6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 27 + 6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 28 + 6.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 28 6.4.5. Information Modeling, Device Variation, and - Information Relationships . . . . . . . . . . . . . . 23 + Information Relationships . . . . . . . . . . . . . . 28 6.4.5.1. Managing Variation: Object Classes/Types and - Inheritance . . . . . . . . . . . . . . . . . . . 24 - 6.4.5.2. Managing Variation: Optionality . . . . . . . . . 24 - 6.4.5.3. Managing Variation: Templating . . . . . . . . . 25 - 6.4.5.4. Object Relationships . . . . . . . . . . . . . . 25 - 6.4.5.4.1. Initialization . . . . . . . . . . . . . . . 25 - 6.4.5.4.2. Correlation Identification . . . . . . . . . 26 - 6.4.5.4.3. Object References . . . . . . . . . . . . . . 26 - 6.4.5.4.4. Active Reference . . . . . . . . . . . . . . 26 - 7. I2RS Client Agent Interface . . . . . . . . . . . . . . . . . 26 - 7.1. One Control and Data Exchange Protocol . . . . . . . . . 26 - 7.2. Communication Channels . . . . . . . . . . . . . . . . . 27 - 7.3. Capability Negotiation . . . . . . . . . . . . . . . . . 27 - 7.4. Scope Policy Specifications . . . . . . . . . . . . . . . 28 - 7.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 28 - 7.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 29 - 7.7. Information collection . . . . . . . . . . . . . . . . . 29 - 7.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 30 - 7.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 30 - 8. Operational and Manageability Considerations . . . . . . . . 31 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 - 11. Informative References . . . . . . . . . . . . . . . . . . . 32 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 + Inheritance . . . . . . . . . . . . . . . . . . . 28 + 6.4.5.2. Managing Variation: Optionality . . . . . . . . . 29 + 6.4.5.3. Managing Variation: Templating . . . . . . . . . 29 + 6.4.5.4. Object Relationships . . . . . . . . . . . . . . 30 + 6.4.5.4.1. Initialization . . . . . . . . . . . . . . . 30 + 6.4.5.4.2. Correlation Identification . . . . . . . . . 30 + 6.4.5.4.3. Object References . . . . . . . . . . . . . . 31 + 6.4.5.4.4. Active Reference . . . . . . . . . . . . . . 31 + 7. I2RS Client Agent Interface . . . . . . . . . . . . . . . . . 31 + 7.1. One Control and Data Exchange Protocol . . . . . . . . . 31 + 7.2. Communication Channels . . . . . . . . . . . . . . . . . 32 + 7.3. Capability Negotiation . . . . . . . . . . . . . . . . . 32 + 7.4. Scope Policy Specifications . . . . . . . . . . . . . . . 33 + 7.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 33 + 7.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 34 + 7.7. Information collection . . . . . . . . . . . . . . . . . 34 + 7.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 35 + 7.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 35 + 8. Operational and Manageability Considerations . . . . . . . . 36 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 37 + 11.2. Informative References . . . . . . . . . . . . . . . . . 37 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 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. @@ -155,20 +160,28 @@ 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 interface to the routing system. + Section 4 provides an overview of the security considerations for the + I2RS architecture. The detailed requirements for I2RS protocol + security are contained in + [I-D.ietf-i2rs-protocol-security-requirements], and the detailed + security requirements for environment in which the I2RS protocol + exists in are contained in [I-D.ietf-i2rs-security-environment-reqs]. + 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, asynchronous, and 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 @@ -193,65 +206,65 @@ state could then be distributed in a routing or signaling protocol and/or be used locally (e.g. to program the co-located forwarding plane). I2RS will only permit modification of state that would be safe, conceptually, 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. + using I2RS, their associated I2RS clients, and I2RS agents. Applications access I2RS services through I2RS clients. A single - 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 + 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) which the - I2RS Agent data models may access or augment. + I2RS agent data models may access or augment. Figure 1 is similar to the figure 1 found in the [I-D.ietf-i2rs-problem-statement], but this figure shows additional detail on how the applications utilize I2RS clients to interact with - I2RS Agents. Figure 1 also shows a logical view of the data models + I2RS agents. Figure 1 also shows a logical view of the data models associated with the routing system rather than a functional view (RIB, FIB, topology, policy, routing/signaling protocols, etc.) In figure 1, Clients A and B each provide access to a single application (application 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 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 the figure 1, - Clients B and P access I2RS Agents 1 and 2. Likewise, an I2RS Agent + An I2RS client can access one or more I2RS agents. In the 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 + agent 1 provides services to Clients A, B and P while Agent 2 provides services to only Clients B and P. I2RS agents and clients communicate with one another using an asynchronous protocol. Therefore, a single client can post multiple simultaneous requests, either to a single agent or to multiple agents. Furthermore, an agent can process multiple requests, either from a single client or from multiple clients, simultaneously. The I2RS agent provides read and write access to selected data on the routing element that are organized into I2RS Services. Section 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 LSP-ID or number of active BGP peers). In addition, the + (e.g. MPLS 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 Section 7.6 and Section 7.7 for details. @@ -300,31 +313,30 @@ * 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 + Figure 1: Architecture of I2RS Clients and Agents Routing Element: A Routing Element implements some subset of the routing system. It does not need to have a forwarding plane associated with it. Examples of Routing Elements can include: * A router with a forwarding plane and RIB Manager that runs IS- IS, OSPF, BGP, PIM, etc., * A BGP speaker acting as a Route Reflector, - * An LSR that implements RSVP-TE, OSPF-TE, and PCEP and has a forwarding plane and associated RIB Manager, * A server that runs IS-IS, OSPF, BGP and uses ForCES to control a remote forwarding plane, A Routing Element may be locally managed, whether via CLI, SNMP, or NETCONF. Routing and Signaling: This block represents that portion of the @@ -347,45 +359,44 @@ provided to the I2RS agent is out of scope, but the standardized information and data models for what is exposed are part of I2RS. Static System State: An I2RS agent needs access to static state on a routing element beyond what is contained in the routing subsystem. An example of such state is specifying queueing behavior for an interface or traffic. How the I2RS agent modifies or obtains this information is out of scope, but the standardized information and data models for what is exposed are part of I2RS. - I2RS Agent: See the definition in Section 2. + 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. + I2RS client: See the definition in Section 2. As can be seen in Figure 1, an I2RS client can communicate with - multiple I2RS agents. An I2RS client may connect to one or more I2RS - agents based upon its needs. Similarly, an I2RS agent may - communicate with multiple I2RS clients - whether to respond to their - requests, to send notifications, etc. Timely notifications are - critical so that several simultaneously operating applications have - up-to-date information on the state of the network. + 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 + 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 + 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 + served basis. The I2RS architecture includes this definition of behavior for this case simply for predictability not because this is an intended result. This predictability will simplify the error handling and suppress oscillations. If additional error cases beyond this simple treatment are required, these error cases should be resolved by the network applications and management systems. In contrast, although multiple I2RS clients may need to supply data into the same list (e.g. a prefix or filter list), this is not considered an error and must be correctly handled. The nuances so that writers do not normally collide should be handled in the @@ -402,28 +413,28 @@ between write operations. A basic example of this is when two different but overlapping prefixes are written with different forwarding behavior. Detection and avoidance of such interactions is outside the scope of the I2RS work and is left to agent design and implementation. 2. Terminology The following terminology is used in this document. - agent or I2RS Agent: An I2RS agent provides the supported I2RS + agent or I2RS agent: An I2RS agent provides the supported I2RS services from the local system's routing sub-systems by interacting with the routing element to provide specified behavior. The I2RS agent understands the I2RS protocol and can be contacted by I2RS clients. - client or I2RS Client: A client implements the I2RS protocol, uses - it to communicate with I2RS Agents, and uses the I2RS services to + 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. @@ -434,22 +445,22 @@ service' could be an example of a service that gives access to state held in a device's RIB. read scope: The read scope of an I2RS client within an I2RS agent is the set of information which the I2RS client is authorized to read within the I2RS agent. The read scope specifies the access restrictions to both see the existence of data and read the value of that data. notification scope: The set of events and associated information - that the I2RS Client can request be pushed by the I2RS Agent. - I2RS Clients have the ability to register for specific events and + that the I2RS client can request be pushed by the I2RS agent. + I2RS clients have the ability to register for specific events and information streams, but must be constrained by the access restrictions associated with their notification scope. write scope: The set of field values which the I2RS client is authorized to write (i.e. add, modify or delete). This access can restrict what data can be modified or created, and what specific value sets and ranges can be installed. scope: When unspecified as either read scope, write scope, or notification scope, the term scope applies to the read scope, @@ -482,40 +493,62 @@ a read-scope that is the logical OR of the read-scopes associated with its roles, a write-scope that is the logical OR of the write-scopes associated with its roles, and a notification-scope that is the logical OR of the notification-scopes associated with its roles. - secondary identity: An I2RS Client may supply a secondary opaque - identity that is not interpreted by the I2RS Agent. An example - use is when the I2RS Client is a go-between for multiple + 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. - Groups: NETCONF Network Access [RFC6536] uses the term group in + ephemeral data: is data which 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. + + safe modification of routing state via I2RS: are I2RS ephemeral + configuration changes which which modify local configuration + rather than the direct modification of protocol-internal state. + Direct modifications to protocol-internal state may have unsafe + consequences. + + groups: NETCONF Network Access [RFC6536] uses the term group in terms of an Administrative group which supports the well- established distinction between a root account and other types of less-privileged conceptual user accounts. Group still refers to a single identity (e.g. root) which is shared by a group of users. + routing system/subsystem: is a set of software and hardware that + handles determining where packets are forwarded to which the I2RS + system connects. 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 which have IP as layer 3. A + routing "subsystem" indicates that the routing software/hardware + is only the subsystem of another larger system. + 3. Key Architectural Properties Several key architectural properties for the I2RS protocol are elucidated below (simplicity, extensibility, and model-driven programmatic interfaces). However, some architecture properties such as performance and scaling are not described below because they are - discussed in [I-D.ietf-i2rs-problem-statement], may may vary based on - the particular use-cases. + discussed in [I-D.ietf-i2rs-problem-statement], may vary based on the + particular use-cases. 3.1. Simplicity There have been many efforts over the years to improve the access to the information available to the routing and forwarding system. Making such information visible and usable to network management and applications has many well-understood benefits. There are two related challenges in doing so. First, the quantity and diversity of information potentially available is very large. Second, the variation both in the structure of the data and in the kinds of @@ -526,185 +559,211 @@ Adding complexity beyond what is needed to satisfy well known and understood requirements would hinder the ease of implementation, the robustness of the protocol, and the deployability of the protocol. Overly complex data models tend to ossify information sets by attempting to describe and close off every possible option, complicating extensibility. Thus, one of the key aims for I2RS is the keep the protocol and modeling architecture simple. So for each architectural component or aspect, we ask ourselves "do we need this complexity, or is the - behavior merely nice to have?" + behavior merely nice to have?" If we need the complexity, we should + ask ourselves "Is this the simpliest way to provide 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 the I2RS work is being restricted in the interests of - achieving a deliverable and deployable result. The I2RS Working - Group is modeling only a subset of the data of interest. It is - clearly desirable for the data models defined in the I2RS to be - useful in more general settings. It should be easy to integrate data - models from the I2RS with other data. Other work should be able to - easily extend it to represent additional aspects of the network - elements or network systems. This reinforces the criticality of - designing the data models to be highly extensible, preferably in a - regular and simple fashion. + The 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 the + 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 maintain. Well-known data modeling languages exist and may be used for defining the data models for I2RS. There are several key benefits for I2RS in using model-driven - architecture and protocol(s). First, it allows for transferring - data-models whose content is not explicitly implemented or - understood. Second, tools can automate checking and manipulating - data; this is particularly valuable for both extensibility and for - the ability to easily manipulate and check proprietary data-models. + 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 an definition of the + 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 re-utilize existing protocols that carry network - management information. Two of the existing protocols which the - which may be re-used are NETCONF [RFC6241] and RESTCONF - [I-D.ietf-netconf-restconf]. The I2RS protocol design process will - be to specify additional requirements including security for these - existing protocol in order to support the I2RS architecture. After - an existing protocol, (e.g. NETCONF or RESTCONF) has been altered to - fit the I2RS requirements, then it will be reviewed to determine if - it meets the I2RS security requirements. + designed to reuse existing protocols that carry network management + information. Two of the existing protocols which are being reused + for I2RS protocol version 1 are NETCONF [RFC6241] and RESTCONF + [I-D.ietf-netconf-restconf]. Additional protocol 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 re-use strategy of the I2RS architecture, this security section describes the assumed security environment for I2RS with additional details on: a) identity and authentication, b) authorization, and c) client redundancy. Each protocol proposed for inclusion as an I2RS protocol will need to be evaluated for the security constraints of the protocol. The detailed requirements for the I2RS protocol and the I2RS security environment will be defined within these global security environments. + The I2RS protocol security requirements for I2RS protocol version 1 + are contained in [I-D.ietf-i2rs-protocol-security-requirements], and + the global I2RS security environment requirements for protocol + version 1 are contained [I-D.ietf-i2rs-security-environment-reqs]. + First, here is a brief description of the assumed security - environment for I2RS. The I2RS Agent associated with a Routing + environment for I2RS. The I2RS agent associated with a Routing Element is a trusted part of that Routing Element. For example, it may be part of a vendor-distributed signed software image for the entire Routing Element or it may be trusted signed application that - an operator has installed. The I2RS Agent is assumed to have a + 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 + 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 + 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. + 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 + 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. + from the I2RS agent can be trusted by the I2RS client. - An I2RS Client is not automatically trustworthy. Each I2RS Client is + An I2RS client is not automatically trustworthy. Each I2RS client is associated with identity with a set of scope limitations. - Applications using the I2RSS should be aware of the scope limitations - of that I2RS Client. If the I2RS Client is acting as a broker for - multiple applications, then managing the security, authentication and - authorization for that communication is out of scope; nothing - prevents the broker from using I2RS protocol and a separate - authentication and authorization channel from being used. Regardless - of mechanism, an I2RS Client that is acting as a broker is - responsible for determining that applications using it are trusted - and permitted to make the particular requests. + Applications using an I2RS 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 that identity has sets specific authorization + limits on performation actions on 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 + I2RS protocol and a separate authentication and authorization channel + from being used. Regardless of mechanism, an I2RS client that is + acting as a broker is responsible for determining that applications + using it are trusted and permitted to make the particular requests. Different levels of integrity, confidentiality, and replay protection are relevant for different aspects of I2RS. The primary communication channel that is used for client authentication and then used by the client to write data requires integrity, confidentiality and replay protection. Appropriate selection of a default required transport protocol is the preferred way of meeting these requirements. Other communications via I2RS may not require integrity, confidentiality, and replay protection. For instance, if an I2RS - Client subscribes to an information stream of prefix announcements + client subscribes to an information stream of prefix announcements from OSPF, those may require integrity but probably not confidentiality or replay protection. Similarly, an information stream of interface statistics may not even require guaranteed delivery. In Section 7.2, additional login regarding multiple communication channels and their use is provided. From the security - perspective, it is critical to realize that an I2RS Agent may open a + 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 + client (as described in Section 7.2). For example, an I2RS client may request notifications of certain events and the agent will open a communication channel to report such events. Therefore, to avoid an indirect attack, such a request must be done in the context of an authenticated and authorized client whose communications cannot have been altered. 4.1. Identity and Authentication As discussed above, all control exchanges between the I2RS client and agent should be authenticated and integrity protected (such that the contents cannot be changed without detection). Further, manipulation of the system must be accurately attributable. In an ideal architecture, even information collection and notification should be protected; this may be subject to engineering tradeoffs during the design. I2RS clients may be operating on behalf of other applications. While those applications' identities are not needed for authentication or authorization, each application should have a unique opaque identifier that can be provided by the I2RS client to the I2RS agent - for purposes of tracking attribution of operations to support - functionality such as troubleshooting and logging of network changes. + 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. 4.2. Authorization All operations using I2RS, both observation and manipulation, should be subject to appropriate authorization controls. Such authorization is based on the identity and assigned role of the I2RS client performing the operations and the I2RS agent in the network element. Multiple Identities may use the same role(s). As noted in the definition of the identity and role above, if multiple roles are associated with an identity then the identity is authorized to perform any operation authorized by any of its roles. - I2RS Agents, in performing information collection and manipulation, + 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 @@ -712,119 +771,136 @@ identifier while defining meaningful manipulable defaults. The identity within NACM [RFC6536] can be specify as either a user name or a group user name (e.g. Root), and this name is linked a scope policy that is contained in a set of access control rules. Similarly, it is expected the I2RS identity links to one role which has a scope policy specified by a set of access control rules. This scope policy can be provided via Local Configuration, exposed as an I2RS Service for manipulation by authorized clients, or via some other method (e.g. AAA service) + 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/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 which links to the + I2RS agent, and this identity links to a role which links to the scope policy. Multiple identities may belong to the same role; for example, such a role might be an Internal-Routes-Monitor that allows reading of the portion of the I2RS RIB associated with IP prefixes used for internal device addresses in the AS." 4.3. Client Redundancy I2RS must support client redundancy. At the simplest, this can be handled by having a primary and a backup network application that both use the same client identity and can successfully authenticate as such. Since I2RS does not require a continuous transport connection and supports multiple transport sessions, this can provide some basic redundancy. However, it does not address the need for troubleshooting and logging of network changes to be informed about which network application is actually active. At a minimum, basic transport information about each connection and time can be logged with the identity. +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 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 + 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 + 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 + application that is using it. The broker I2RS client can pass along the appropriate value as a secondary identifier which can be used for tracking attribution of operations. In a third architecture, a routing element or network-oriented - application that uses an I2RS Client to access services on a + application that uses an I2RS client to access services on a different routing element may also contain an I2RS agent to provide services to other network-oriented applications. However, where the needed information and data models for those services differs from that of a conventional routing element, those models are, at least initially, out of scope for I2RS. Below is an example of such a network application 5.1. Example Network Application: Topology Manager A Topology Manager includes an I2RS client that uses the I2RS data models and protocol to collect information about the state of the network by communicating directly with one or more I2RS agents. From these I2RS agents, the Topology Manager collects routing configuration and operational data, such as interface and label- switched path (LSP) information. In addition, the Topology Manager may collect link-state data in several ways - either via I2RS models, - by peering with BGP-LS[I-D.ietf-idr-ls-distribution] or listening - into the IGP. + by peering with BGP-LS[RFC7752] or listening into the IGP. The set of functionality and collected information that is the Topology Manager may be embedded as a component of a larger application, such as a path computation application. As a stand- alone application, the Topology Manager could be useful to other network applications by providing a coherent picture of the network state accessible via another interface. That interface might use the same I2RS protocol and could provide a topology service using extensions to the I2RS data models. 6. I2RS Agent Role and Functionality - The I2RS Agent is part of a routing element. As such, it has + The I2RS agent is part of a routing element. As such, it has relationships with that routing element as a whole, and with various components of that routing element. 6.1. Relationship to its Routing Element A Routing Element may be implemented with a wide variety of different architectures: an integrated router, a split architecture, distributed architecture, etc. The architecture does not need to affect the general I2RS agent behavior. For scalability and generality, the I2RS agent may be responsible for collecting and delivering large amounts of data from various parts of the routing element. Those parts may or may not actually be part of a single physical device. Thus, for scalability and robustness, it is important that the architecture allow for a distributed set of reporting components providing collected data from the I2RS agent - back to the relevant I2RS clients. There may be multiple I2RS Agents + back to the relevant I2RS clients. There may be multiple I2RS agents within the same router. In such a case, they must have non- overlapping sets of information which they manipulate. To facilitate operations, deployment and troubleshooting, it is - important that traceability of the requests received by I2RS Agent's + 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 @@ -832,133 +908,236 @@ the state is removed by the client, overridden by some other operation such as CLI, or the device reboots. Meaningful logging of the application and removal of changes is recommended. I2RS applied changes to the routing element state will not be retained across routing element reboot. The I2RS data store is not preserved across routing element reboots; thus the I2RS agent will not attempt to reapply such changes after a reboot. 6.2.1. I2RS Agent Failure - It is expected that an I2RS Agent may fail independently of the + It is expected that an I2RS agent may fail independently of the associated routing element. This could happen because I2RS is - disabled on the routing element or because the I2RS Agent, a separate + disabled on the routing element or because the I2RS agent, a separate process or even running on a separate processor, experiences an unexpected failure. Just as routing state learned from a failed source is removed, the ephemeral I2RS state will usually be removed shortly after the failure is detected or as part of a graceful - shutdown process. To handle I2RS Agent failure, the I2RS Agent must - use two different notifications. - - NOTIFICATION_I2RS_AGENT_STARTING: This notification 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 only transmitted to I2RS clients which are - know in some way after a reboot.) + 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 the a description of + their use in unexpected failures and graceful shutdowns. NOTIFICATION_I2RS_AGENT_TERMINATING: This notification reports that - the associated I2RS Agent is shutting down gracefully, and 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 shutdown. Use of + timestamp indicating when the I2RS agent will shutdown. Use of this timestamp assumes that time synchronization has been done and the timestamp should not have granularity finer than one second because better accuracy of shutdown time is not guaranteed. + 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 on be sent by the I2RS agent to I2RS clients + which 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 + 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 + 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. + cached I2RS client. - Graceful failure: In this case, the I2RS Agent can do specific + 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. + 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. 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. + 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 + whatever was specified via the CLI, NETCONF, SNMP, etc. I2RS agents will not store multiple alternative states, nor try to determine which one among such a plurality it should fall back to. Thus, the model followed is not like the RIB, where multiple routes are stored at different preferences. (For I2RS state in the presence of two I2RS clients, please see section 1.2 and section 7.8) - An I2RS Client may register for notifications, subject to its + An I2RS client may register for notifications, subject to its notification scope, regarding state modification or removal by a - particular I2RS Client. + 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 model is the result of general I2RS rules, system - rules, knobs adjust by operator-applied policy, and the rules - associated with the yang data model (often in MUST and WHEN clauses + 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). - This operator-applied policy can determine whether Local + The operator-applied policy knobs can determine whether the Local Configuration overrides a particular I2RS client's request or vice - versa. To achieve this end, the I2RS data modules have a general - rule that by default the Local Configuration always wins. - Optionally, a routing element may permit a priority to be to be - configured on the device for the Local Configuration mechanism - interaction with the I2RS model. The policy mechanism would compare - the I2RS client's priority with that priority assigned to the Local - Configuration in order to determine whether Local Configuration or - I2RS wins. + versa. Normally, most devices will have an operator-applied policy + that will prioritize the I2RS client's ephemeral configuration + changes so that ephemeral data overides 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 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 clients 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. + + 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. For 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. The local configuration + model, if there is an I2RS ephemeral state value is installed instead + of the local configuration state. The local configuration information is stored so that if/when 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 sub-system, the I2RS Agent must also + that subsystem and the I2RS agent is still necessary. As an I2RS + agent connects to the routing sub-system, 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 + 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 are 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. + + Policy Knob 1: Ephemeral configuration overwrites local + configuration. + + Policy Knob 2: Update of local configuration value supercedes and + overwrites the ephemeral configuration. + + For Policy Knob 1, the routers with 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 "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 config has local config has + priority priority + + Router C ephemeral has local config + 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 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. + + 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. + + Router C's operator sets the Policy Knob 1 for the I2RS clients to + overwrite existing Local Configuration and the 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 the Local Configuration of all systems at + 11pm each night. Any ephemeral change to the network is only + supposed to last until 11pm 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 11pm, the back-end configuration system + updates the Local Configuration via NETCONF and the I2RS agent is + notified 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, @@ -1009,29 +1188,30 @@ or for QoS behaviors that traffic is direct into). Section 6.4.5 discusses information modeling constructs and the range of relationship types that are applicable. 6.4.1. Routing and Label Information Bases Routing elements may maintain one or more Information Bases. Examples include Routing Information Bases such as IPv4/IPv6 Unicast or IPv4/IPv6 Multicast. Another such example includes the MPLS Label Information Bases, per-platform or per-interface 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, so as to safely change the system state. Conceptually, this can be handled by having - the I2RS Agent communicate with a RIB Manager as a separate routing + 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 + 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 @@ -1041,24 +1221,25 @@ 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 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 + 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. 6.4.3. MPLS I2RS Services will be needed to expose the protocols that create @@ -1068,21 +1249,21 @@ originating in, transiting, or terminating in this Routing Element. 6.4.4. Policy and QoS Mechanisms Many network elements have separate policy and QoS mechanisms, including knobs which affect local path computation and queue control capabilities. These capabilities vary widely across implementations, and I2RS cannot model the full range of information collection or manipulation of these attributes. A core set does need to be included in the I2RS information models and supported in the expected - interfaces between the I2RS Agent and the network element, in order + interfaces between the I2RS agent and the network element, in order to provide basic capabilities and the hooks for future extensibility. By taking advantage of extensibility and sub-classing, information models can specify use of a basic model that can be replaced by a more detailed model. 6.4.5. Information Modeling, Device Variation, and Information Relationships I2RS depends heavily on information models of the relevant aspects of @@ -1103,22 +1284,22 @@ will be used as the example terminology. This I2RS architecture does require the ability to address variation in Routing Elements by allowing information models to define parent or base classes and subclasses. The base or parent class defines the common aspects that all Routing Elements are expected to support. Individual subclasses can represent variations and additional capabilities. When applicable, there may be several levels of refinement. The I2RS protocol can then provide mechanisms to allow an I2RS client to determine which - classes a given I2RS Agent has available. Clients which only want - basic capabilities can operate purely in terms of base or parent + classes a given I2RS agent has available. I2RS clients which only + want basic capabilities can operate purely in terms of base or parent classes, while a client needing more details or features can work with the supported sub-class(es). As part of I2RS information modeling, clear rules should be specified for how the parent class and subclass can relate; for example, what changes 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 @@ -1221,35 +1402,40 @@ 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 ([RFC6020]), Yang 1.1 - ([I-D.ietf-netmod-rfc6020bis]), and associated Yang based model - drafts ([RFC6991], [RFC7223], [RFC7224], [RFC7277], [RFC7317]). Two - the protocols to be expanded to support the I2RS protocol are NETCONF - [RFC6241] and RESTCONF [I-D.ietf-netconf-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 - 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. + data-models are defined in YANG 1.1 ([I-D.ietf-netmod-rfc6020bis]), + and associated YANG based model drafts ([RFC6991], [RFC7223], + [RFC7224], [RFC7277], [RFC7317]). Two the protocols to be expanded + to support the I2RS protocol are NETCONF [RFC6241] and RESTCONF + [I-D.ietf-netconf-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 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 the I2RS protocol may 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 sub-components 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). @@ -1260,276 +1446,283 @@ 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 + 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 which can take place within the base protocol mechanisms. In particular, the more complex protocol and mechanism negotiation can be addressed by defining information models - for both the I2RS Agent and the I2RS Client. These information + 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 section 4.1 and 4.2 describe, each I2RS Client will have a unique + As section 4.1 and 4.2 describe, each I2RS client will have a unique identity and it 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 limitations on the resources that can be consumed. - Specifications for scope policy need to specify the data and value - ranges for portion of scope policy. + and limitations on 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 - A client may or may not maintain an active communication channel with - an agent. Therefore, an agent may need to open a communication - channel to the client to communicate previously requested - information. The lack of an active communication channel does not - imply that the associated client is non-functional. When - communication is required, the agent or client can open a new - communication channel. + 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 agent that is owned by a client should not be - removed or cleaned up when a client is no longer communicating - even - if the agent cannot successfully open a new communication channel to - the client. + 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 mechanism instantiated in the I2RS - agent would add complications to the I2RS protocol and are thus left - for future work. + 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 clean-up if a particular transport session is terminated. The second is to allow state expiration, expressed as a policy associated with the I2RS client's role. The state expiration could occur after there has been no successful communication channel to or from the I2RS client for the policy-specified duration. 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 + client needs to be able to receive notifications of changes in network state. Notifications here refers to changes which are unanticipated, represent events outside the control of the systems (such as interface failures on controlled devices), or are sufficiently sparse as to be anomalous in some fashion. A notification may also be due to a regular event. - Such events may be of interest to multiple I2RS Clients controlling - data handled by an I2RS Agent, and to multiple other I2RS clients + Such events may be of interest to multiple I2RS clients controlling + data handled by an I2RS agent, and to multiple other I2RS clients which are collecting information without exerting control. The - architecture therefore requires that it be practical for I2RS Clients - to register for a range of notifications, and for the I2RS Agents to - send notifications to a number of Clients. The I2RS Client should be + 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. + 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 + 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 the I2RS is that it is intended to simplify collecting information about the state of network elements. This includes both getting a snapshot of a large amount of data about the current state of the network element, and subscribing to a feed of the ongoing changes to the set of data or a subset thereof. This is considered architecturally separate from notifications due to the differences in information rate and total volume. 7.8. Multi-Headed Control - As was described earlier, an I2RS Agent interacts with multiple I2RS - Clients who are actively controlling the network element. From an + As was described earlier, an I2RS agent interacts with multiple I2RS + clients who are actively controlling the network element. From an architecture and design perspective, the assumption is that by means outside of this system the data to be manipulated within the network element is appropriately partitioned so that any given piece of - information is only being manipulated by a single I2RS Client. + 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 + decidable means by which I2RS agents handle the collisions. The mechanism for ensuring predictability is to have a simple priority associated with each I2RS clients, and the highest priority change - remains in effect. In the case of priority ties, the first client - whose attribution is associated with the data will keep control. + 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 important that it is possible for an I2RS Client + I2RS clients, it is important that it is possible for an I2RS client to register for changes to any changes made by I2RS to data that it may care about. This is included in the I2RS event mechanisms. This also needs to apply to changes made by CLI/NETCONF/SNMP within the - write-scope of the I2RS Agent, as the same priority mechanism (even + 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 + single message. An I2RS client may indicate one of the following three error handling for a given message with multiple operations - which it sends to an I2RS Agent: + which it sends to an I2RS agent: Perform all or none: This traditional SNMP semantic indicates that other I2RS agent will keep enough state when handling a single message to roll back the operations within that message. Either all the operations will succeed, or none of them will be applied and an error message will report the single failure which caused them not to be applied. This is useful when there are, for example, mutual dependencies across operations in the message. Perform until error: In this case, the operations in the message are applied in the specified order. When an error occurs, no further operations are applied, and an error is returned indicating the failure. This is useful if there are dependencies among the operations and they can be topologically sorted. - Perform all storing errors: In this case, the I2RS Agent will + Perform all storing errors: In this case, the I2RS agent will attempt to perform all the operations in the message, and will return error indications for each one that fails. This is useful when there is no dependency across the operation, or where the - client would prefer to sort out the effect of errors on its own. + 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 + 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 + 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 the 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 + 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 + agents during deployment, and troubleshoot software or network problems. - Notification Subscription Service: The ability for an I2RS Client to - subscribe to a notification stream pushed from the I2RS Agent + 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 + more scalable notification handling for the I2RS agent-client interactions. 9. IANA Considerations This document includes no request to IANA. 10. Acknowledgements Significant portions of this draft came from draft-ward-i2rs- framework-00 and draft-atlas-i2rs-policy-framework-00. The authors would like to thank Nitin Bahadur, Shane Amante, Ed Crabbe, Ken Gray, Carlos Pignataro, Wes George, Ron Bonica, Joe Clarke, Juergen Schoenwalder, 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, and Deborah Brungard for - their suggestions and review. + 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. -11. Informative References +11. References + +11.1. Normative References [I-D.ietf-i2rs-problem-statement] Atlas, A., Nadeau, T., and D. Ward, "Interface to the Routing System Problem Statement", draft-ietf-i2rs- problem-statement-10 (work in progress), February 2016. - [I-D.ietf-idr-ls-distribution] - Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. - Ray, "North-Bound Distribution of Link-State and TE - Information using BGP", draft-ietf-idr-ls-distribution-13 - (work in progress), October 2015. +11.2. Informative References + + [I-D.ietf-i2rs-protocol-security-requirements] + Hares, S., Migault, D., and J. Halpern, "I2RS Security + Related Requirements", draft-ietf-i2rs-protocol-security- + requirements-03 (work in progress), March 2016. + + [I-D.ietf-i2rs-security-environment-reqs] + Migault, D., Halpern, J., and S. Hares, "I2RS Environment + Security Requirements", draft-ietf-i2rs-security- + environment-reqs-01 (work in progress), April 2016. [I-D.ietf-netconf-restconf] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF - Protocol", draft-ietf-netconf-restconf-09 (work in - progress), December 2015. + Protocol", draft-ietf-netconf-restconf-12 (work in + progress), April 2016. [I-D.ietf-netmod-rfc6020bis] Bjorklund, M., "The YANG 1.1 Data Modeling Language", draft-ietf-netmod-rfc6020bis-11 (work in progress), February 2016. - [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for - the Network Configuration Protocol (NETCONF)", RFC 6020, - DOI 10.17487/RFC6020, October 2010, - . - [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, . @@ -1546,29 +1739,36 @@ . [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, + . + Authors' Addresses Alia Atlas Juniper Networks 10 Technology Park Drive Westford, MA 01886 USA Email: akatlas@juniper.net + Joel Halpern Ericsson Email: Joel.Halpern@ericsson.com Susan Hares Huawei Email: shares@ndzh.com