--- 1/draft-ietf-i2rs-architecture-12.txt 2016-02-20 12:21:23.792879880 -0800 +++ 2/draft-ietf-i2rs-architecture-13.txt 2016-02-20 12:21:24.080887061 -0800 @@ -1,25 +1,25 @@ Network Working Group A. Atlas Internet-Draft Juniper Networks Intended status: Informational J. Halpern -Expires: June 25, 2016 Ericsson +Expires: August 23, 2016 Ericsson S. Hares Huawei D. Ward Cisco Systems T. Nadeau Brocade - December 23, 2015 + February 20, 2016 An Architecture for the Interface to the Routing System - draft-ietf-i2rs-architecture-12 + draft-ietf-i2rs-architecture-13 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). Status of This Memo @@ -30,25 +30,25 @@ 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 June 25, 2016. + This Internet-Draft will expire on August 23, 2016. Copyright Notice - Copyright (c) 2015 IETF Trust and the persons identified as the + Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -70,49 +70,49 @@ 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 . . . . . 20 - 6.4.1. Routing and Label Information Bases . . . . . . . . . 21 + 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 6.4.5. Information Modeling, Device Variation, and Information Relationships . . . . . . . . . . . . . . 23 6.4.5.1. Managing Variation: Object Classes/Types and - Inheritance . . . . . . . . . . . . . . . . . . . 23 + Inheritance . . . . . . . . . . . . . . . . . . . 24 6.4.5.2. Managing Variation: Optionality . . . . . . . . . 24 - 6.4.5.3. Managing Variation: Templating . . . . . . . . . 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 . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 26 + 7.2. Communication Channels . . . . . . . . . . . . . . . . . 27 7.3. Capability Negotiation . . . . . . . . . . . . . . . . . 27 - 7.4. Scope Policy Specifications . . . . . . . . . . . . . . . 27 + 7.4. Scope Policy Specifications . . . . . . . . . . . . . . . 28 7.5. Connectivity . . . . . . . . . . . . . . . . . . . . . . 28 - 7.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 28 + 7.6. Notifications . . . . . . . . . . . . . . . . . . . . . . 29 7.7. Information collection . . . . . . . . . . . . . . . . . 29 - 7.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 29 + 7.8. Multi-Headed Control . . . . . . . . . . . . . . . . . . 30 7.9. Transactions . . . . . . . . . . . . . . . . . . . . . . 30 - 8. Operational and Manageability Considerations . . . . . . . . 30 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 - 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 + 8. Operational and Manageability Considerations . . . . . . . . 31 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 11. Informative References . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 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 @@ -121,21 +121,23 @@ Routers convert all of this information into forwarding entries which are then used to forward packets and flows between network elements. The forwarding plane and the specified forwarding entries then contain active state information that describes the expected and observed operational behavior of the router and which is also needed by the network applications. Network-oriented applications require easy access to this information to learn the network topology, to verify that programmed state is installed in the forwarding plane, to measure the behavior of various flows, routes or forwarding entries, as well as to understand the configured and active states of the - router. + router. Network-oriented applications also require easy access to an + interface which will allow them to program and control state related + to forwarding. This document sets out an architecture for a common, standards-based interface to this information. This Interface to the Routing System (I2RS) facilitates control and observation of the routing-related state (for example, a Routing Element RIB manager's state), as well as enabling network-oriented applications to be built on top of today's routed networks. The I2RS is a programmatic asynchronous interface for transferring state into and out of the internet routing system. This I2RS architecture recognizes that the routing system and a router's Operating System (OS) provide useful mechanisms that @@ -133,31 +135,33 @@ This document sets out an architecture for a common, standards-based interface to this information. This Interface to the Routing System (I2RS) facilitates control and observation of the routing-related state (for example, a Routing Element RIB manager's state), as well as enabling network-oriented applications to be built on top of today's routed networks. The I2RS is a programmatic asynchronous interface for transferring state into and out of the internet routing system. This I2RS architecture recognizes that the routing system and a router's Operating System (OS) provide useful mechanisms that applications could harness to accomplish application-level goals. + These network-oriented applications can leverage the I2RS programmatic interface to create new ways of combining retrieval of internet routing data, analyzing this data, setting state within routers. Fundamental to the I2RS are clear data models that define the semantics of the information that can be written and read. The I2RS - provides a framework for registering and for requesting the - appropriate information for each particular application. The I2RS provides a way for applications to customize network behavior while - leveraging the existing routing system as desired. + leveraging the existing routing system as desired. The I2RS provides + a framework for applications (including controller applications) to + register and to request the appropriate information for each + particular application. Although the I2RS architecture is general enough to support information and data models for a variety of data, and aspects of the I2RS solution may be useful in domains other than routing, I2RS and this document are specifically focused on an interface for routing data. 1.1. Drivers for the I2RS Architecture There are four key drivers that shape the I2RS architecture. First @@ -240,23 +244,23 @@ 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 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 - enough 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. + 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. The scope of I2RS is to define the interactions between the I2RS agent and the I2RS client and the associated proper behavior of the I2RS agent and I2RS client. ****************** ***************** ***************** * Application C * * Application D * * Application E * ****************** ***************** ***************** ^ ^ ^ | | | @@ -522,21 +526,21 @@ 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?" Protocol parsimony is clearly a goal. + behavior merely nice to have?" 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 @@ -838,33 +842,35 @@ 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 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 identifies 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. + 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.) NOTIFICATION_I2RS_AGENT_TERMINATING: This notification reports that - the associated I2RS Agent is shutting down gracefully. Ephemeral - state will be removed. It can optionally include a 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 + 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 + 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. There are two different failure types that are possible and each has different behavior. Unexpected failure: In this case, the I2RS Agent has unexpectedly crashed and thus cannot notify its clients of anything. Since I2RS does not require a persistent connection between the I2RS Client and I2RS Agent, it is necessary to have a mechanism for the I2RS Agent to notify I2RS Clients that had subscriptions or @@ -892,46 +898,61 @@ An I2RS Agent may decide that some state should no longer be applied. An I2RS Client may instruct an Agent to remove state it has applied. In all such cases, the state will revert to what it would have been without the I2RS client-agent interaction; that state is generally whatever was specified via the CLI, NETCONF, SNMP, etc. I2RS Agents will not store multiple alternative states, nor try to determine which one among such a plurality it should fall back to. Thus, the model followed is not like the RIB, where multiple routes are stored at different preferences. (For I2RS state in the presence of two I2RS clients, please see section 1.2 and section 7.8) - An I2RS Client may register for notifications, subject to its notification scope, regarding state modification or removal by a particular I2RS Client. 6.3. Interactions with Local Configuration Changes may originate from either Local Configuration or from I2RS. The modifications and data stored by I2RS are separate from the local device configuration, but conflicts between the two must be resolved - in a deterministic manner that respects operator-applied policy. - That policy can determine whether Local Configuration overrides a - particular I2RS client's request or vice versa. To achieve this end, - either by default Local Configuration always wins or, optionally, a - routing element may permit a priority to be configured on the device - for the Local Configuration mechanism. The policy mechanism in the - later case is comparing the I2RS client's priority with that priority - assigned to the Local Configuration. + 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 + for dependencies). + + This operator-applied policy can determine whether 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. + + 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 + 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. That - communication contains the details of each specific device - configuration change that the I2RS Agent is permitted to modify. In - addition, when the system determines, that a client's I2RS state is - preempted, the I2RS agent must notify the affected I2RS clients; how - the system determines this is implementation-dependent. + 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 + 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.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 @@ -1225,22 +1244,22 @@ support suitable congestion control mechanisms. The transports chosen should be operator and implementor friendly to ease adoption. 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 level I2RS protocol. - + communication channels will use the same higher-layer I2RS protocol + (which combines secure transport and I2RS contextual information). The use of additional channels for communication will be coordinated between the I2RS client and the I2RS agent using this protocol. I2RS protocol communication may be delivered in-band via the routing system's data plane. I2RS protocol communication might be delivered out-of-band via a management interface. Depending on what operations are requested, it is possible for the I2RS protocol communication to cause the in-band communication channels to stop working; this could cause the I2RS agent to become unreachable across that communication channel. @@ -1474,37 +1493,37 @@ 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. 11. Informative 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-08 (work in progress), December 2015. + 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. [I-D.ietf-netconf-restconf] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", draft-ietf-netconf-restconf-09 (work in progress), December 2015. [I-D.ietf-netmod-rfc6020bis] Bjorklund, M., "The YANG 1.1 Data Modeling Language", - draft-ietf-netmod-rfc6020bis-09 (work in progress), - December 2015. + 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, .