--- 1/draft-ietf-i2rs-architecture-14.txt 2016-04-22 08:15:56.715969815 -0700 +++ 2/draft-ietf-i2rs-architecture-15.txt 2016-04-22 08:15:56.799971891 -0700 @@ -1,25 +1,25 @@ Network Working Group A. Atlas Internet-Draft Juniper Networks Intended status: Informational J. Halpern -Expires: October 23, 2016 Ericsson +Expires: October 24, 2016 Ericsson S. Hares Huawei D. Ward Cisco Systems T. Nadeau Brocade - April 21, 2016 + April 22, 2016 An Architecture for the Interface to the Routing System - draft-ietf-i2rs-architecture-14 + draft-ietf-i2rs-architecture-15 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 Routing System (I2RS). @@ -31,21 +31,21 @@ 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 October 23, 2016. + This Internet-Draft will expire on October 24, 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 @@ -56,71 +56,71 @@ 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 . . . . . . . . . . . . . . . . 12 3.1. Simplicity . . . . . . . . . . . . . . . . . . . . . . . 12 - 3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 13 + 3.2. Extensibility . . . . . . . . . . . . . . . . . . . . . . 12 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 + 4.4. I2RS in Personal Devices . . . . . . . . . . . . . . . . 17 5. Network Applications and I2RS Client . . . . . . . . . . . . 18 - 5.1. Example Network Application: Topology Manager . . . . . . 19 + 5.1. Example Network Application: Topology Manager . . . . . . 18 6. I2RS Agent Role and Functionality . . . . . . . . . . . . . . 19 6.1. Relationship to its Routing Element . . . . . . . . . . . 19 - 6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 20 + 6.2. I2RS State Storage . . . . . . . . . . . . . . . . . . . 19 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. Interactions with Local Configuration . . . . . . . . . . 21 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. Routing Components and Associated I2RS Services . . . . . 24 + 6.4.1. Routing and Label Information Bases . . . . . . . . . 25 + 6.4.2. IGPs, BGP and Multicast Protocols . . . . . . . . . . 26 + 6.4.3. MPLS . . . . . . . . . . . . . . . . . . . . . . . . 26 + 6.4.4. Policy and QoS Mechanisms . . . . . . . . . . . . . . 27 6.4.5. Information Modeling, Device Variation, and - Information Relationships . . . . . . . . . . . . . . 28 + Information Relationships . . . . . . . . . . . . . . 27 6.4.5.1. Managing Variation: Object Classes/Types and - 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 + Inheritance . . . . . . . . . . . . . . . . . . . 27 + 6.4.5.2. Managing Variation: Optionality . . . . . . . . . 28 + 6.4.5.3. Managing Variation: Templating . . . . . . . . . 28 + 6.4.5.4. Object Relationships . . . . . . . . . . . . . . 29 + 6.4.5.4.1. Initialization . . . . . . . . . . . . . . . 29 + 6.4.5.4.2. Correlation Identification . . . . . . . . . 29 + 6.4.5.4.3. Object References . . . . . . . . . . . . . . 30 + 6.4.5.4.4. Active Reference . . . . . . . . . . . . . . 30 + 7. I2RS Client Agent Interface . . . . . . . . . . . . . . . . . 30 + 7.1. One Control and Data Exchange Protocol . . . . . . . . . 30 + 7.2. Communication Channels . . . . . . . . . . . . . . . . . 31 + 7.3. Capability Negotiation . . . . . . . . . . . . . . . . . 31 + 7.4. Scope Policy Specifications . . . . . . . . . . . . . . . 32 + 7.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 32 + 7.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 33 + 7.7. Information collection . . . . . . . . . . . . . . . . . 33 + 7.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 34 + 7.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 34 + 8. Operational and Manageability Considerations . . . . . . . . 35 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 36 + 11.2. Informative References . . . . . . . . . . . . . . . . . 36 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 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. @@ -199,23 +199,22 @@ Such an interface also facilitates the injection of ephemeral state into the routing system. Ephemeral state on a router is the state which does not survive a 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 the I2RS and that state could then be distributed in a routing or signaling protocol and/or be used locally (e.g. to program the co-located forwarding plane). 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. + 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) which the @@ -507,26 +506,20 @@ applications and it is necessary to track which application has requested a particular operation. 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 @@ -1191,24 +1185,23 @@ 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 - source. + 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