idnits 2.17.1 draft-ietf-i2rs-problem-statement-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 18, 2015) is 3046 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4292' is defined on line 423, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-11 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Atlas, Ed. 3 Internet-Draft Juniper Networks 4 Intended status: Informational T. Nadeau, Ed. 5 Expires: June 20, 2016 Brocade 6 D. Ward 7 Cisco Systems 8 December 18, 2015 10 Interface to the Routing System Problem Statement 11 draft-ietf-i2rs-problem-statement-08 13 Abstract 15 Traditionally, routing systems have implemented routing and signaling 16 (e.g. MPLS) to control traffic forwarding in a network. Route 17 computation has been controlled by relatively static policies that 18 define link cost, route cost, or import and export routing policies. 19 With the advent of highly dynamic data center networking, on-demand 20 WAN services, dynamic policy-driven traffic steering and service 21 chaining, the need for real-time security threat responsiveness via 22 traffic control, and a paradigm of separating policy-based decision- 23 making from the router itself, the need has emerged to more 24 dynamically manage and program routing systems in order to control 25 routing information and traffic paths and to extract network topology 26 information, traffic statistics, and other network analytics from 27 routing systems. 29 This document proposes meeting this need via an Interface to the 30 Routing System (I2RS). 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on June 20, 2016. 49 Copyright Notice 51 Copyright (c) 2015 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. I2RS Model and Problem Area for the IETF . . . . . . . . . . 3 68 3. Standard Data-Models of Routing State for Installation . . . 6 69 4. Learning Router Information . . . . . . . . . . . . . . . . . 6 70 5. Aspects to be Considered for an I2RS Protocol . . . . . . . . 7 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 9. Informative References . . . . . . . . . . . . . . . . . . . 9 75 Appendix A. Existing Management Interfaces . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction 80 Traditionally, routing systems have implemented routing and signaling 81 (e.g. MPLS) to control traffic forwarding in a network. Route 82 computation has been controlled by relatively static policies that 83 define link cost, route cost, or import and export routing policies. 84 With the advent of highly dynamic data center networking, on-demand 85 WAN services, dynamic policy-driven traffic steering and service 86 chaining, the need for real-time security threat responsiveness via 87 traffic control, and a paradigm of separating policy-based decision- 88 making from the router itself, the need has emerged to more 89 dynamically manage and program routing systems in order to control 90 routing information and traffic paths and to extract network topology 91 information, traffic statistics, and other network analytics from 92 routing systems. 94 As modern networks continue to grow in scale and complexity and 95 desired policy has become more complex and dynamic, there is a need 96 to support rapid control and analytics. The scale of modern networks 97 and data-centers and the associated operational expense drives the 98 need to automate even the simplest operations. The ability to 99 quickly interact via more complex operations to support dynamic 100 policy is even more critical. 102 In order to enable network applications to have access to and control 103 over information in the different vendors' routing systems, a 104 publicly documented interface is required. The interface needs to 105 support real-time, asynchronous interactions using efficient data 106 models and encodings that are based on and extend those previously 107 defined. Furthermore, the interface must be tailored to provide a 108 solid base on which a variety of use cases can be supported. 110 To support the requirements of orchestration software and automated 111 network applications to dynamically modify the network, there is a 112 need to learn topology, network analytics, and existing state from 113 the network as well as to create or modify routing information and 114 network paths. A feedback loop is needed so that changes made can be 115 verifiable and so that these applications can learn and react to 116 network changes. 118 Proprietary solutions to partially support the requirements outlined 119 above have been developed to handle specific situations and needs. 120 Standardizing an interface to the routing system will make it easier 121 to integrate use of it into a network. Because there are proprietary 122 partial solutions already, the standardization of a common interface 123 should be feasible. 125 It should be noted that during the course of this document, the term 126 "applications" is used. This is meant to refer to an executable 127 program of some sort that has access to a network, such as an IP or 128 MPLS network, via a routing system. 130 2. I2RS Model and Problem Area for the IETF 132 Managing a network of systems running a variety of routing protocols 133 and/or providing one or more additional services (e.g., forwarding, 134 classification and policing, firewalling) involves interactions 135 between multiple components within these systems. Some of these 136 systems or system components may be virtualized, colocated within the 137 same physical system or distributed. In all cases, it is desirable 138 to enable network applications to manage and control the services 139 provided by many, if not all, of these components, subject to 140 authenticated and authorized access and policies. 142 A data-model driven interface to the routing system is needed. This 143 will allow expansion of what information can be read and controlled 144 and allow for future flexibility. At least one accompanying protocol 145 with clearly defined operations is needed; the suitable protocol(s) 146 can be identified and expanded to support the requirements of an 147 Interface to the Routing System (I2RS). These solutions must be 148 designed to facilitate rapid, isolated, secure, and dynamic changes 149 to a device's routing system. These would facilitate wide-scale 150 deployment of interoperable applications and routing systems. 152 The I2RS model and problem area for IETF work is illustrated in 153 Figure 1. This document uses terminology defined in 154 [I-D.ietf-i2rs-architecture]. The I2RS Agent is associated with a 155 routing element, which may or may not be co-located with a data- 156 plane. The I2RS Client could be integrated in a network application 157 or controlled and used by one or more separate network applications. 158 For instance, an I2RS Client could be provided by a network 159 controller or a network orchestration system that provides a non-I2RS 160 interface to network applications and an I2RS interface to I2RS 161 Agents on the systems being managed. The scope of the data-models 162 used by I2RS extends across the entire routing system and the 163 selected protocol(s) for I2RS. 165 As depicted in Figure 1, the I2RS Client and I2RS agent in a routing 166 system are objects with in the I2RS scope. The selected protocol(s) 167 for I2RS extend between the I2RS client and I2RS Agent. All other 168 objects and interfaces in Figure 1 are outside the I2RS scope for 169 standardization. 171 +***************+ +***************+ +***************+ 172 * Application * * Application * * Application * 173 +***************+ +***************+ +***************+ 174 | I2RS Client | ^ ^ 175 +---------------+ * * 176 ^ * **************** 177 | * * 178 | v v 179 | +---------------+ +-------------+ 180 | | I2RS Client |<------->| Other I2RS | 181 | +---------------+ | Agents | 182 | ^ +-------------+ 183 |________________ | 184 | | <== I2RS Protocol 185 | | 186 ...........................|..|.................................. 187 . v v . 188 . +*************+ +---------------+ +****************+ . 189 . * Policy * | | * Routing & * . 190 . * Database *<***>| I2RS Agent |<****>* Signaling * . 191 . +*************+ | | * Protocols * . 193 . +---------------+ +****************+ . 194 . ^ ^ ^ ^ . 195 . +*************+ * * * * . 196 . * Topology * * * * * . 197 . * Database *<*******+ * * v . 198 . +*************+ * * +****************+ . 199 . * +********>* RIB Manager * . 200 . * +****************+ . 201 . * ^ . 202 . v * . 203 . +*******************+ * . 204 . * Subscription & * * . 205 . * Configuration * v . 206 . * Templates for * +****************+ . 207 . * Measurements, * * FIB Manager * . 208 . * Events, QoS, etc. * * & Data Plane * . 209 . +*******************+ +****************+ . 210 ................................................................. 212 <--> interfaces inside the scope of I2RS Protocol 213 +--+ objects inside the scope of I2RS-defined behavior 215 <**> interfaces NOT within the scope of I2RS Protocol 216 +**+ objects NOT within the scope of I2RS-defined behavior 218 .... boundary of a router supporting I2RS 220 Figure 1: I2RS model and Problem Area 222 The I2RS Working Group must select the suitable protocol(s) to carry 223 messages between the I2RS Clients and I2RS Agent. The protocol 224 should provide the key features specified in Section 5. 226 The I2RS Working Group must identify or define is a set of meaningful 227 data-models for information in the routing system and in a topology 228 database. The data-model should describe the meaning and 229 relationships of the modeled items. The data-models should be 230 separable across different features of the managed components, 231 versioned, and extendable. As shown in Figure 1, I2RS needs to 232 interact with several logical components of the routing element: 233 policy database, topology database, subscription and configuration 234 for dynamic measurements/events, routing signaling protocols, and its 235 RIB manager. This interaction is both for writing (e.g. to policy 236 databases or RIB manager) as well as for reading (e.g. dynamic 237 measurement or topology database). An application should be able to 238 combine data from individual routing elements to provide network-wide 239 data-model(s). 241 The data models should translate into a concise transfer syntax, sent 242 via the I2RS protocol, that is straightforward for applications to 243 use (e.g., a Web Services design paradigm). The information transfer 244 should use existing transport protocols to provide the reliability, 245 security, and timeliness appropriate for the particular data. 247 3. Standard Data-Models of Routing State for Installation 249 As described in Section 1, there is a need to be able to precisely 250 control routing and signaling state based upon policy or external 251 measures. One set of data-models that I2RS should focus on is for 252 interacting with the RIB layer (e.g. RIB, LIB, multicast RIB, 253 policy-based routing) to provide flexibility and routing 254 abstractions. As an example, the desired routing and signaling state 255 might range from simple static routes to policy-based routing to 256 static multicast replication and routing state. This means that, to 257 usefully model next-hops, the data model employed needs to handle 258 next-hop indirection and recursion (e.g. a prefix X is routed like 259 prefix Y) as well as different types of tunneling and encapsulation. 261 Efforts to provide this level of control have focused on 262 standardizing data models that describe the forwarding plane (e.g. 263 ForCES [RFC3746]). I2RS recognizes that the routing system and a 264 router's OS provide useful mechanisms that applications could 265 usefully harness to accomplish application-level goals. Using 266 routing indirection, recursion and common routing abstractions (e.g. 267 tunnels, LSPs, etc.) provides significant flexibility and 268 functionality over collapsing the state to individual routes in the 269 FIB that need to be individually modified when a change occurs. 271 In addition to interfaces to control the RIB layer, there is a need 272 to dynamically configure policies and values for parameters for the 273 various routing and signaling protocols based upon application-level 274 policy decisions. 276 4. Learning Router Information 278 A router has information that applications may require so that they 279 can understand the network, verify that programmed state is 280 installed, measure the behavior of various flows, and understand the 281 existing configuration and state of the router. I2RS should provide 282 a framework so that applications can register for asynchronous 283 notifications and can make specific requests for information. 285 Although there are efforts to extend the topological information 286 available, even the best of these (e.g., BGP-LS 287 [I-D.ietf-idr-ls-distribution]) still provide only the current active 288 state as seen at the IGP and BGP layers. Detailed topological state 289 that provides more information than the current functional status 290 (e.g. active paths and links) is needed by applications. Examples of 291 missing information include paths or link that are potentially 292 available (e.g. administratively down) or unknown (e.g. to peers or 293 customers) to the routing topology. 295 For applications to have a feedback loop that includes awareness of 296 the relevant traffic, an application must be able to request the 297 measurement and timely, scalable reporting of data. While a 298 mechanism such as IPFIX [RFC5470] may be the facilitator for 299 delivering the data, providing the ability for an application to 300 dynamically request that measurements be taken and data delivered is 301 important. 303 There are a wide range of events that applications could use for 304 either verification of router state before other network state is 305 changed (e.g. that a route has been installed), to act upon changes 306 to relevant routes by others, or upon router events (e.g. link up/ 307 down). While a few of these (e.g. link up/down) may be available via 308 MIB notifications today, the full range is not (e.g. route-installed, 309 route-changed, primary LSP changed, etc.) 311 5. Aspects to be Considered for an I2RS Protocol 313 This section describes required aspects of a protocol that could 314 support I2RS. Whether such a protocol is built upon extending 315 existing mechanisms or requires a new mechanism requires further 316 investigation. 318 The key aspects needed in an interface to the routing system are: 320 Multiple Simultaneous Asynchronous Operations: A single application 321 should be able to send multiple independent atomic operations via 322 I2RS without being required to wait for each to complete before 323 sending the next. 325 Very Fine Granularity of Data Locking for Writing: When an I2RS 326 operation is processed, it is required that the data locked for 327 writing is very granular (e.g. a particular prefix and route) 328 rather than extremely coarse, as is done for writing 329 configuration. This should improve the number of concurrent I2RS 330 operations that are feasible and reduce blocking delays. 332 Multi-Headed Control: Multiple applications may communicate to the 333 same I2RS agent in a minimally coordinated fashion. It is 334 necessary that the I2RS agent can handle multiple requests in a 335 well-known policy-based fashion. Data written can be owned by 336 different I2RS clients at different times; data may even be 337 overwritten by a different I2RS client. The details of how this 338 should be handled are described in [I-D.ietf-i2rs-architecture]. 340 Duplex: Communications can be established by either the I2RS client 341 (i.e.: that resides within the application or is used by it to 342 communicate with the I2RS agent), or the I2RS agent. Similarly, 343 events, acknowledgements, failures, operations, etc. can be sent 344 at any time by both the router and the application. The I2RS is 345 not a pure pull-model where only the application queries to pull 346 responses. 348 High-Throughput: At a minimum, within the I2RS scope, the I2RS 349 Agent and associated router should be able to handle a 350 considerable number of operations per second (for example 10,000 351 per second to handle many individual subscriber routes changing 352 simultaneously). 354 Low-Latency: Within a sub-second time-scale, it should be possible 355 to complete simple operations (e.g. reading or writing a single 356 prefix route). 358 Multi-Channel: It should be possible for information to be 359 communicated via the interface from different components in the 360 router without requiring going through a single channel. For 361 example, for scaling, some exported data or events may be better 362 sent directly from the forwarding plane, while other interactions 363 may come from the control-plane. 365 Scalable, Filterable Information Access: To extract information in a 366 scalable fashion that is more easily used by applications, the 367 ability to specify filtering constructs in an operation requesting 368 data or requesting an asynchronous notification is very valuable. 370 Secure Control and Access: Any ability to manipulate routing state 371 must be subject to authentication and authorization. Sensitive 372 routing information may also need to be provided via secure access 373 back to the I2RS client. Such communications must be integrity 374 protected. Some communications will also require confidentiality. 376 Extensible and Interoperability: Both the I2RS protocol and models 377 must be extensible and interoperate between different versions of 378 protocols and models. 380 6. Acknowledgements 382 The authors would like to thank Ken Gray, Ed Crabbe, Nic Leymann, 383 Carlos Pignataro, Kwang-koog Lee, Linda Dunbar, Sue Hares, Russ 384 Housley, Eric Grey, Qin Wu, Stephen Kent, Nabil Bitar, Deborah 385 Brungard, and Sarah Banks for their suggestions and review. 387 7. IANA Considerations 389 This document includes no request to IANA. 391 8. Security Considerations 393 Security is a key aspect of any protocol that allows state 394 installation and extracting of detailed router state. The need for 395 secure control and access is mentioned in Section 5. More 396 architectural security considerations are discussed in 397 [I-D.ietf-i2rs-architecture]. Briefly, the I2RS Agent is assumed to 398 have a separate authentication and authorization channel by which it 399 can validate both the identity and the permissions associated with an 400 I2RS Client. Mutual authentication between the I2RS Agent and I2RS 401 Client is required. Different levels of integrity, confidentiality, 402 and replay protection are relevant for different aspects of I2RS. 404 9. Informative References 406 [I-D.ietf-i2rs-architecture] 407 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 408 Nadeau, "An Architecture for the Interface to the Routing 409 System", draft-ietf-i2rs-architecture-11 (work in 410 progress), December 2015. 412 [I-D.ietf-idr-ls-distribution] 413 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 414 Ray, "North-Bound Distribution of Link-State and TE 415 Information using BGP", draft-ietf-idr-ls-distribution-13 416 (work in progress), October 2015. 418 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 419 "Forwarding and Control Element Separation (ForCES) 420 Framework", RFC 3746, DOI 10.17487/RFC3746, April 2004, 421 . 423 [RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, 424 DOI 10.17487/RFC4292, April 2006, 425 . 427 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 428 "Architecture for IP Flow Information Export", RFC 5470, 429 DOI 10.17487/RFC5470, March 2009, 430 . 432 Appendix A. Existing Management Interfaces 434 This section discusses as a single entity the combination of the 435 abstract data models, their representation in a data language, and 436 the transfer protocol commonly used with them. While other 437 combinations of these existing standard technologies are possible, 438 the ways described are those that have significant deployment. 440 There are three basic ways that routers are managed. The most 441 popular is the command line interface (CLI), which allows both 442 configuration and learning of device state. This is a proprietary 443 interface resembling a UNIX shell that allows for very customized 444 control and observation of a device, and, specifically of interest in 445 this case, its routing system. Some form of this interface exists on 446 almost every device (virtual or otherwise). Processing of 447 information returned to the CLI (called "screen scraping") is a 448 burdensome activity because the data is normally formatted for use by 449 a human operator, and because the layout of the data can vary from 450 device to device, and between different software versions. Despite 451 its ubiquity, this interface has never been standardized and is 452 unlikely to ever be standardized. CLI standardization is not 453 considered as a candidate solution for the problems motivating I2RS. 455 The second most popular interface for interrogation of a device's 456 state, statistics, and configuration is the Simple Network Management 457 Protocol (SNMP) and a set of relevant standards-based and proprietary 458 Management Information Base (MIB) modules. SNMP has a strong history 459 of being used by network managers to gather statistical and state 460 information about devices, including their routing systems. However, 461 SNMP is very rarely used to configure a device or any of its systems 462 for reasons that vary depending upon the network operator. Some 463 example reasons include complexity, the lack of desired configuration 464 semantics (e.g., configuration "roll-back", "sandboxing" or 465 configuration versioning), and the difficulty of using the semantics 466 (or lack thereof) as defined in the MIB modules to configure device 467 features. Therefore, SNMP is not considered as a candidate solution 468 for the problems motivating I2RS. 470 Finally, the IETF's Network Configuration (or NETCONF) protocol has 471 made many strides at overcoming most of the limitations around 472 configuration that were just described. However, as a new technology 473 and with the initial lack of standard data models, the adoption of 474 NETCONF has been slow. I2RS will define needed information and data 475 models to support I2RS applications. Additional extensions to handle 476 multi-headed control may need to be added to NETCONF and/or 477 appropriate data models. 479 Authors' Addresses 481 Alia Atlas (editor) 482 Juniper Networks 484 Email: akatlas@juniper.net 486 Thomas D. Nadeau (editor) 487 Brocade 489 Email: tnadeau@lucidvision.com 491 Dave Ward 492 Cisco Systems 494 Email: wardd@cisco.com