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