idnits 2.17.1 draft-ietf-i2rs-problem-statement-02.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 (June 6, 2014) is 3609 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: December 8, 2014 Brocade 6 D. Ward 7 Cisco Systems 8 June 6, 2014 10 Interface to the Routing System Problem Statement 11 draft-ietf-i2rs-problem-statement-02 13 Abstract 15 As modern networks grow in scale and complexity, the need for rapid 16 and dynamic control increases. With scale, the need to automate even 17 the simplest operations is important, but even more critical is the 18 ability to quickly interact with more complex operations such as 19 policy-based controls. 21 In order to enable network applications to have access to and control 22 over information in the Internet's routing system, we need a publicly 23 documented interface specification. The interface needs to support 24 real-time, asynchronous interactions using data models and encodings 25 that are efficient and potentially different from those available 26 today. Furthermore, the interface must be tailored to support a 27 variety of use cases. 29 This document expands upon these statements of requirements to 30 provide a detailed problem statement for an Interface to the Routing 31 System (I2RS). 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 8, 2014. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. I2RS Model and Problem Area for The IETF . . . . . . . . . . 3 69 3. Standard Data-Models of Routing State for Installation . . . 5 70 4. Learning Router Information . . . . . . . . . . . . . . . . . 6 71 5. Desired Aspects of a Protocol for I2RS . . . . . . . . . . . 6 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 9. Informative References . . . . . . . . . . . . . . . . . . . 8 76 Appendix A. Existing Management Interfaces . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 As modern networks grow in scale and complexity, the need for rapid, 82 flexible and dynamic control increases. With scale, the need to 83 automate even the simplest operation is important, but even more 84 critical is the ability for network operators to quickly interact 85 with these operations using mechanisms such as policy-based controls. 87 With complexity comes the need for more sophisticated automated 88 network applications and orchestration software that can process 89 large quantities of data, run complex algorithms, and adjust the 90 routing state as required in order to support the network 91 applications, their computations and their policies. Changes made to 92 the routing state of a network by external applications must be 93 verifiable by those applications to ensure that the correct state has 94 been installed in the correct places. 96 In the past, mechanisms to support the requirements outlined above 97 have been developed piecemeal as proprietary solutions to specific 98 situations and needs. Many routing elements have an external 99 interface to interact with routing - but since these vary between 100 vendors, it is difficult to integrate use of those interfaces into a 101 network. The existence of such proprietary interfaces demonstrates 102 both that the need for such an interface is understood and that 103 technology solutions are understood. What is needed are 104 technological solutions with clearly defined operations that an 105 application can initiate, and data-models to support such actions. 106 These would facilitate wide-scale deployment of interoperable 107 applications and routing systems. These solutions must be designed 108 to facilitate rapid, isolated, secure, and dynamic changes to a 109 device's routing system. In order to address these needs, the 110 creation of an Interface to the Routing System (I2RS) is needed. 112 It should be noted that during the course of this document, the term 113 "applications" is used. This is meant to refer to an executable 114 program of some sort that has access to a network, such as an IP or 115 MPLS network. 117 2. I2RS Model and Problem Area for The IETF 119 Managing a network of production devices running a variety of routing 120 protocols involves interactions between multiple components within a 121 device. Some of these components are virtual while some are 122 physical; it may be desirable for many, or even all of these 123 components to be made available to be managed and manipulated by 124 applications, given that appropriate access, authentication, and 125 policy hurdles have been crossed. The management of only some of 126 these components require standardization, as others have already been 127 standardized. The I2RS model is intended to incorporate existing 128 mechanisms where appropriate, and to build extensions and new 129 protocols where needed. The I2RS model and problem area for IETF 130 work is illustrated in Figure 1. The I2RS Agent is associated with a 131 routing element, which may or may not be co-located with a data- 132 plane. The I2RS Client is used and controlled by one or more network 133 applications; they may be co-located or the I2RS Client might be part 134 of a separate application, such as an orchestrator or controller. 136 +***************+ +***************+ +***************+ 137 * Application * * Application * * Application * 138 +***************+ +***************+ +***************+ 139 | I2RS Client | ^ ^ 140 +---------------+ * * 141 ^ * **************** 142 | * * 143 | v v 144 | +---------------+ +-------------+ 145 | | I2RS Client |<------->| Other I2RS | 146 | +---------------+ | Agents | 147 | ^ +-------------+ 148 |________________ | 149 | | <== I2RS Protocol 150 | | 151 ...........................|..|.................................. 152 . v v . 153 . +*************+ +---------------+ +****************+ . 154 . * Policy * | | * Routing & * . 155 . * Database *<***>| I2RS Agent |<****>* Signaling * . 156 . +*************+ | | * Protocols * . 157 . +---------------+ +****************+ . 158 . ^ ^ ^ ^ . 159 . +*************+ * * * * . 160 . * Topology * * * * * . 161 . * Database *<*******+ * * v . 162 . +*************+ * * +****************+ . 163 . * +********>* RIB Manager * . 164 . * +****************+ . 165 . * ^ . 166 . v * . 167 . +*******************+ * . 168 . * Subscription & * * . 169 . * Configuration * v . 170 . * Templates for * +****************+ . 171 . * Measurements, * * FIB Manager * . 172 . * Events, QoS, etc. * * & Data Plane * . 173 . +*******************+ +****************+ . 174 ................................................................. 176 <--> interfaces inside the scope of I2RS 177 +--+ objects inside the scope of I2RS 179 <**> interfaces NOT within the scope of I2RS 180 +**+ objects NOT within the scope of I2RS 182 .... boundary of a router participating in the I2RS 184 Figure 1: I2RS model and Problem Area 186 A critical aspect of I2RS is defining a suitable protocol or 187 protocols to carry messages between the I2RS Clients and the I2RS 188 Agent, and defining the data-models for use with those I2RS 189 protocol(s). The protocol should provide the key features specified 190 in Section 5. The data models should translate into a clear transfer 191 syntax that is straightforward for applications to use (e.g., a Web 192 Services design paradigm). The information transfer should use 193 existing transport protocols to provide the reliability, security, 194 and timeliness appropriate for the particular data. 196 The second critical aspect are semantic-aware data-models for 197 information in the routing system and in a topology database. The 198 data-model should describe the meaning and relationships of the 199 modeled items. The data-models should be separable across different 200 features of the managed components, versioned, and extendable. As 201 shown in Figure 1, I2RS needs to interact with several logical 202 components of the routing element: policy database, topology 203 database, subscription and configuration for dynamic measuresments/ 204 events, routing signaling protocols, and its RIB manager. This 205 interaction is both for writing (e.g. to policy databases or RIB 206 manager) as well as for reading (e.g. dynamic measurement or topology 207 database). An application should be able to combine data from 208 individual routing elements to provide network-wide data-model(s). 210 3. Standard Data-Models of Routing State for Installation 212 There is a need to be able to precisely control routing and signaling 213 state based upon policy or external measures. This can range from 214 simple static routes to policy-based routing to static multicast 215 replication and routing state. This means that, to usefully model 216 next-hops, the data model employed needs to handle next-hop 217 indirection and recursion (e.g. a prefix X is routed like prefix Y) 218 as well as different types of tunneling and encapsulation. The 219 relevant MIB modules (for example [RFC4292]) lack the necessary 220 generality and flexibility. In addition, by having I2RS focus 221 initially on interfaces to the RIB layer (e.g. RIB, LIB, multicast 222 RIB, policy-based routing), the ability to use routing indirection 223 allows flexibility and functionality that can't be as easily obtained 224 at the forwarding layer. 226 Efforts to provide this level of control have focused on 227 standardizing data models that describe the forwarding plane (e.g. 228 ForCES [RFC3746]). I2RS posits that the routing system and a 229 router's OS provide useful mechanisms that applications could 230 usefully harness to accomplish application-level goals. 232 In addition to interfaces to the RIB layer, there is a need to 233 configure the various routing and signaling protocols with differing 234 dynamic state based upon application-level policy decisions. The 235 range desired is not available via MIBs at the present time. 237 4. Learning Router Information 239 A router has information that applications may require so that they 240 can understand the network, verify that programmed state is installed 241 in the forwarding plane, measure the behavior of various flows, and 242 understand the existing configuration and state of the router. I2RS 243 provides a framework so that applications can register for 244 asynchronous notifications and can make specific requests for 245 information. 247 Although there are efforts to extend the topological information 248 available, even the best of these (e.g., BGP-LS 249 [I-D.gredler-idr-ls-distribution]) still provide only the current 250 active state as seen at the IGP layer and above. Detailed 251 topological state that provides more information than the current 252 functional status is needed by applications; only the active paths or 253 links are known versus those potentially available (e.g. 254 administratively down) or unknown (e.g. to peers or customers) to the 255 routing topology. 257 For applications to have a feedback loop that includes awareness of 258 the relevant traffic, an application must be able to request the 259 measurement and timely, scalable reporting of data. While a 260 mechanism such as IPFIX [RFC5470] may be the facilitator for 261 delivering the data, the need for an application to be able to 262 dynamically request that measurements be taken and data delivered is 263 critical. 265 There are a wide range of events that applications could use for 266 either verification of router state before other network state is 267 changed (e.g. that a route has been installed), to act upon changes 268 to relevant routes by others, or upon router events (e.g. link up/ 269 down). While a few of these (e.g. link up/down) may be available via 270 MIB Notifications today, the full range is not - nor is there the 271 standardized ability to set up the router to trigger different 272 actions upon an event's occurrence so that a rapid reaction can be 273 accomplished. 275 5. Desired Aspects of a Protocol for I2RS 277 This section describes required aspects of a protocol that could 278 support I2RS. Whether such a protocol is built upon extending 279 existing mechanisms or requires a new mechanism requires further 280 investigation. 282 The key aspects needed in an interface to the routing system are: 284 Multiple Simultaneous Asynchronous Operations: A single application 285 should be able to send multiple independent operations via I2RS 286 without being required to wait for each to complete before sending 287 the next. 289 Very Fine Granularity of Data Locking for Writing: When an I2RS 290 operation is processed, it is required that the data locked for 291 writing is very granular (e.g. a particular prefix and route) 292 rather than extremely coarse, as is done for writing 293 configuration. This should improve the number of concurrent I2RS 294 operations that are feasible and reduce blocking delays. 296 Multi-Headed Control: Multiple applications may communicate to the 297 same I2RS agent in a minimally coordinated fashion. It is 298 necessary that the I2RS agent can handle multiple requests in a 299 well-known policy-based fashion. Data written can be owned by 300 different I2RS clients. 302 Duplex: Communications can be established by either the I2RS client 303 (i.e.: that resides within the application or is used by it to 304 communicate with the I2RS agent), or the I2RS agent. Similarly, 305 events, acknowledgements, failures, operations, etc. can be sent 306 at any time by both the router and the application. The I2RS is 307 not a pure pull-model where only the application queries to pull 308 responses. 310 High-Throughput: At a minimum, the I2RS Agent and associated router 311 should be able to handle a considerable number of operations per 312 second (for example 10,000 per second to handle many individual 313 subscriber routes changing simultaneously). 315 Responsive: Within a sub-second time-scale, it should be possible 316 to complete simple operations (e.g. reading or writing a single 317 prefix route). 319 Multi-Channel: It should be possible for information to be 320 communicated via the interface from different components in the 321 router without requiring going through a single channel. For 322 example, for scaling, some exported data or events may be better 323 sent directly from the forwarding plane, while other interactions 324 may come from the control-plane. Thus a single TCP session would 325 not be a good match. 327 Scalable, Filterable Information Access: To extract information in a 328 scalable fashion that is more easily used by applications, the 329 ability to specify filtering constructs in an operation requesting 330 data or requesting an asynchronous notification is very valuable. 332 Secure Control: Any ability to manipulate routing state must be 333 subject to authentication and authorization. Such communications 334 must also have its integrity protected. 336 Extensible and Interoperability: Both the I2RS protocol and models 337 must be extensible and interoperate between different versions of 338 protocols and models. 340 6. Acknowledgements 342 The authors would like to thank Ken Gray, Ed Crabbe, Nic Leymann, 343 Carlos Pignataro, Kwang-koog Lee, Linda Dunbar, and Sue Hares for 344 their suggestions and review. 346 7. IANA Considerations 348 This document includes no request to IANA. 350 8. Security Considerations 352 Security is a key aspect of any protocol that allows state 353 installation and extracting of detailed router state. More 354 investigation remains to fully define the security requirements, such 355 as authorization and authentication levels. 357 9. Informative References 359 [I-D.gredler-idr-ls-distribution] 360 Gredler, H., Medved, J., Previdi, S., and A. Farrel, 361 "North-Bound Distribution of Link-State and TE Information 362 using BGP", draft-gredler-idr-ls-distribution-02 (work in 363 progress), July 2012. 365 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 366 "Forwarding and Control Element Separation (ForCES) 367 Framework", RFC 3746, April 2004. 369 [RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, April 370 2006. 372 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 373 "Architecture for IP Flow Information Export", RFC 5470, 374 March 2009. 376 Appendix A. Existing Management Interfaces 378 This section discusses as a single entity the combination of the 379 abstract data models, their representation in a data language, and 380 the transfer protocol commonly used with them. While other 381 combinations of these existing standard technologies are possible, 382 the ways described are those that have significant deployment. 384 There are three basic ways that routers are managed. The most 385 popular is the command line interface (CLI), which allows both 386 configuration and learning of device state. This is a proprietary 387 interface resembling a UNIX shell that allows for very customized 388 control and observation of a device, and, specifically of interest in 389 this case, its routing system. Some form of this interface exists on 390 almost every device (virtual or otherwise). Processing of 391 information returned to the CLI (called "screen scraping") is a 392 burdensome activity because the data is normally formatted for use by 393 a human operator, and because the layout of the data can vary from 394 device to device, and between different software versions. Despite 395 its ubiquity, this interface has never been standardized and is 396 unlikely to ever be standardized. I2RS does not involve CLI 397 standardization. 399 The second most popular interface for interrogation of a device's 400 state, statistics, and configuration is The Simple Network Management 401 Protocol (SNMP) and a set of relevant standards-based and proprietary 402 Management Information Base (MIB) modules. SNMP has a strong history 403 of being used by network managers to gather statistical and state 404 information about devices, including their routing systems. However, 405 SNMP is very rarely used to configure a device or any of its systems 406 for reasons that vary depending upon the network operator. Some 407 example reasons include complexity, the lack of desired configuration 408 semantics (e.g., configuration "roll-back", "sandboxing" or 409 configuration versioning), and the difficulty of using the semantics 410 (or lack thereof) as defined in the MIB modules to configure device 411 features. Therefore, SNMP is not considered as a candidate solution 412 for the problems motivating I2RS. 414 Finally, the IETF's Network Configuration (or NetConf) protocol has 415 made many strides at overcoming most of the limitations around 416 configuration that were just described. However, the lack of 417 standard data models have hampered the adoption of NetConf. 418 Naturally, I2RS may help define needed information and data models. 419 Additional extensions to handle multi-headed control may need to be 420 added to NetConf and/or appropriate data models. 422 Authors' Addresses 424 Alia Atlas (editor) 425 Juniper Networks 426 10 Technology Park Drive 427 Westford, MA 01886 428 USA 430 Email: akatlas@juniper.net 432 Thomas D. Nadeau (editor) 433 Brocade 435 Email: tnadeau@lucidvision.com 437 Dave Ward 438 Cisco Systems 439 Tasman Drive 440 San Jose, CA 95134 441 USA 443 Email: wardd@cisco.com