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