--- 1/draft-ietf-i2rs-problem-statement-09.txt 2016-02-12 10:15:28.991646432 -0800 +++ 2/draft-ietf-i2rs-problem-statement-10.txt 2016-02-12 10:15:29.019647128 -0800 @@ -1,21 +1,21 @@ Network Working Group A. Atlas, Ed. Internet-Draft Juniper Networks Intended status: Informational T. Nadeau, Ed. -Expires: July 18, 2016 Brocade +Expires: August 15, 2016 Brocade D. Ward Cisco Systems - January 15, 2016 + February 12, 2016 Interface to the Routing System Problem Statement - draft-ietf-i2rs-problem-statement-09 + draft-ietf-i2rs-problem-statement-10 Abstract Traditionally, routing systems have implemented routing and signaling (e.g. MPLS) to control traffic forwarding in a network. Route computation has been controlled by relatively static policies that define link cost, route cost, or import and export routing policies. With the advent of highly dynamic data center networking, on-demand WAN services, dynamic policy-driven traffic steering and service chaining, the need for real-time security threat responsiveness via @@ -37,21 +37,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 July 18, 2016. + This Internet-Draft will expire on August 15, 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 @@ -64,21 +64,23 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. I2RS Model and Problem Area for the IETF . . . . . . . . . . 3 3. Standard Data-Models of Routing State for Installation . . . 6 4. Learning Router Information . . . . . . . . . . . . . . . . . 6 5. Aspects to be Considered for an I2RS Protocol . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 - 9. Informative References . . . . . . . . . . . . . . . . . . . 9 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 + 9.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. Existing Management Interfaces . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Traditionally, routing systems have implemented routing and signaling (e.g. MPLS) to control traffic forwarding in a network. Route computation has been controlled by relatively static policies that define link cost, route cost, or import and export routing policies. With the advent of highly dynamic data center networking, on-demand @@ -155,21 +157,21 @@ routing element, which may or may not be co-located with a data- plane. The I2RS Client could be integrated in a network application or controlled and used by one or more separate network applications. For instance, an I2RS Client could be provided by a network controller or a network orchestration system that provides a non-I2RS interface to network applications and an I2RS interface to I2RS Agents on the systems being managed. The scope of the data-models used by I2RS extends across the entire routing system and the selected protocol(s) for I2RS. - As depicted in Figure 1, the I2RS Client and I2RS agent in a routing + As depicted in Figure 1, the I2RS Client and I2RS Agent in a routing system are objects with in the I2RS scope. The selected protocol(s) for I2RS extend between the I2RS client and I2RS Agent. All other objects and interfaces in Figure 1 are outside the I2RS scope for standardization. +***************+ +***************+ +***************+ * Application * * Application * * Application * +***************+ +***************+ +***************+ | I2RS Client | ^ ^ +---------------+ * * @@ -219,27 +221,28 @@ would be used .... boundary of a router supporting I2RS Figure 1: I2RS model and Problem Area The I2RS Working Group must select the suitable protocol(s) to carry messages between the I2RS Clients and I2RS Agent. The protocol should provide the key features specified in Section 5. - The I2RS Working Group must identify or define is a set of meaningful + The I2RS Working Group must identify or define a set of meaningful data-models for information in the routing system and in a topology database. The data-model should describe the meaning and relationships of the modeled items. The data-models should be separable across different features of the managed components, versioned, and extendable. As shown in Figure 1, I2RS needs to interact with several logical components of the routing element: + policy database, topology database, subscription and configuration for dynamic measurements/events, routing signaling protocols, and its RIB manager. This interaction is both for writing (e.g. to policy databases or RIB manager) as well as for reading (e.g. dynamic measurement or topology database). An application should be able to combine data from individual routing elements to provide network-wide data-model(s). The data models should translate into a concise transfer syntax, sent via the I2RS protocol, that is straightforward for applications to @@ -265,36 +268,36 @@ standardizing data models that describe the forwarding plane (e.g. ForCES [RFC3746]). I2RS recognizes that the routing system and a router's OS provide useful mechanisms that applications could usefully harness to accomplish application-level goals. Using routing indirection, recursion and common routing abstractions (e.g. tunnels, LSPs, etc.) provides significant flexibility and functionality over collapsing the state to individual routes in the FIB that need to be individually modified when a change occurs. In addition to interfaces to control the RIB layer, there is a need - to dynamically configure policies and values for parameters for the + to dynamically configure policies and parameter values for the various routing and signaling protocols based upon application-level policy decisions. 4. Learning Router Information A router has information that applications may require so that they can understand the network, verify that programmed state is installed, measure the behavior of various flows, and understand the existing configuration and state of the router. I2RS should provide a framework so that applications can register for asynchronous notifications and can make specific requests for information. Although there are efforts to extend the topological information available, even the best of these (e.g., BGP-LS - [I-D.ietf-idr-ls-distribution]) still provide only the current active + [I-D.ietf-idr-ls-distribution]) still only provide the current active state as seen at the IGP and BGP layers. Detailed topological state that provides more information than the current functional status (e.g. active paths and links) is needed by applications. Examples of missing information include paths or link that are potentially available (e.g. administratively down) or unknown (e.g. to peers or customers) to the routing topology. For applications to have a feedback loop that includes awareness of the relevant traffic, an application must be able to request the measurement and timely, scalable reporting of data. While a @@ -326,61 +329,65 @@ sending the next. Very Fine Granularity of Data Locking for Writing: When an I2RS operation is processed, it is required that the data locked for writing is very granular (e.g. a particular prefix and route) rather than extremely coarse, as is done for writing configuration. This should improve the number of concurrent I2RS operations that are feasible and reduce blocking delays. Multi-Headed Control: Multiple applications may communicate to the - same I2RS agent in a minimally coordinated fashion. It is - necessary that the I2RS agent can handle multiple requests in a + same I2RS Agent in a minimally coordinated fashion. It is + necessary that the I2RS Agent can handle multiple requests in a well-known policy-based fashion. Data written can be owned by - different I2RS clients at different times; data may even be - overwritten by a different I2RS client. The details of how this + different I2RS Clients at different times; data may even be + overwritten by a different I2RS Client. The details of how this should be handled are described in [I-D.ietf-i2rs-architecture]. - Duplex: Communications can be established by either the I2RS client + Duplex: Communications can be established by either the I2RS Client (i.e., that resides within the application or is used by it to - communicate with the I2RS agent), or the I2RS agent. Similarly, + communicate with the I2RS Agent), or the I2RS Agent. Similarly, events, acknowledgements, failures, operations, etc. can be sent at any time by both the router and the application. The I2RS is not a pure pull-model where only the application queries to pull responses. High-Throughput: At a minimum, within the I2RS scope, the I2RS Agent and associated router should be able to handle a considerable number of operations per second (for example 10,000 per second to handle many individual subscriber routes changing simultaneously). Low-Latency: Within a sub-second time-scale, it should be possible to complete simple operations (e.g. reading or writing a single prefix route). Multi-Channel: It should be possible for information to be communicated via the interface from different components in the router without requiring going through a single channel. For example, for scaling, some exported data or events may be better sent directly from the forwarding plane, while other interactions - may come from the control-plane. + may come from the control-plane. One channel, with authorization + and authentication, may be considered primary; only an authorized + client can then request that information be delivered on a + different channel. Writes from a client are only expected on + channels that provide authorization and authentication. Scalable, Filterable Information Access: To extract information in a scalable fashion that is more easily used by applications, the ability to specify filtering constructs in an operation requesting data or requesting an asynchronous notification is very valuable. Secure Control and Access: Any ability to manipulate routing state must be subject to authentication and authorization. Sensitive routing information may also need to be provided via secure access - back to the I2RS client. Such communications must be integrity + back to the I2RS Client. Such communications must be integrity protected. Some communications will also require confidentiality. Extensible and Interoperability: Both the I2RS protocol and models must be extensible and interoperate between different versions of protocols and models. 6. Acknowledgements The authors would like to thank Ken Gray, Ed Crabbe, Nic Leymann, Carlos Pignataro, Kwang-koog Lee, Linda Dunbar, Sue Hares, Russ @@ -397,28 +404,32 @@ installation and extracting of detailed router state. The need for secure control and access is mentioned in Section 5. More architectural security considerations are discussed in [I-D.ietf-i2rs-architecture]. Briefly, the I2RS Agent is assumed to have a separate authentication and authorization channel by which it can validate both the identity and the permissions associated with an I2RS Client. Mutual authentication between the I2RS Agent and I2RS Client is required. Different levels of integrity, confidentiality, and replay protection are relevant for different aspects of I2RS. -9. Informative References +9. References + +9.1. Normative References [I-D.ietf-i2rs-architecture] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing System", draft-ietf-i2rs-architecture-12 (work in progress), December 2015. +9.2. Informative References + [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. [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, DOI 10.17487/RFC3746, April 2004, .