idnits 2.17.1 draft-atlas-i2rs-problem-statement-01.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 (July 15, 2013) is 3938 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: January 16, 2014 D. Ward 6 Cisco Systems 7 July 15, 2013 9 Interface to the Routing System Problem Statement 10 draft-atlas-i2rs-problem-statement-01 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 applications to have access to and control over 21 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 Internet 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 January 16, 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 . . . . . . . . . . . . . . . . . . . . . . 7 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 applications and orchestration software that can process large 88 quantities of data, run complex algorithms, and adjust the routing 89 state as required in order to support the network applications, their 90 computations and their policies. Changes made to the routing state 91 of a network by external applications must be verifiable by those 92 applications to ensure that the correct state has been installed in 93 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 | 145 | +---------------+ 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 (e.g. a prefix X is routed like prefix Y) as well as 211 different types of tunneling and encapsulation. The relevant MIB 212 modules (for example [RFC4292]) lack the necessary generality and 213 flexibility. In addition, by having I2RS focus initially on 214 interfaces to the RIB layer (e.g. RIB, LIB, multicast RIB, policy- 215 based routing), the ability to use routing indirection allows 216 flexibility and functionality that can't be as easily obtained at the 217 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 to 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 server), or the I2RS server. 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 Any ability to manipulate routing state must be subject to 322 authentication and authorization. 324 6. Acknowledgements 326 The authors would like to thank Ken Gray, Ed Crabbe and Nic Leymann 327 for their suggestions and review. 329 7. IANA Considerations 331 This document includes no request to IANA. 333 8. Security Considerations 335 Security is a key aspect of any protocol that allows state 336 installation and extracting of detailed router state. More 337 investigation remains to fully define the security requirements, such 338 as authorization and authentication levels. 340 9. Informative References 342 [I-D.gredler-idr-ls-distribution] 343 Gredler, H., Medved, J., Previdi, S., and A. Farrel, 344 "North-Bound Distribution of Link-State and TE Information 345 using BGP", draft-gredler-idr-ls-distribution-02 (work in 346 progress), July 2012. 348 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 349 "Forwarding and Control Element Separation (ForCES) 350 Framework", RFC 3746, April 2004. 352 [RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, April 353 2006. 355 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 356 "Architecture for IP Flow Information Export", RFC 5470, 357 March 2009. 359 Appendix A. Existing Management Interfaces 361 This section discusses as a single entity the combination of the 362 abstract data models, their representation in a data language, and 363 the transfer protocol commonly used with them. While other 364 combinations of these existing standard technologies are possible, 365 the ways described are those that have significant deployment. 367 There are three basic ways that routers are managed. The most 368 popular is the command line interface (CLI), which allows both 369 configuration and learning of device state. This is a proprietary 370 interface resembling a UNIX shell that allows for very customized 371 control and observation of a device, and, specifically of interest in 372 this case, its routing system. Some form of this interface exists on 373 almost every device (virtual or otherwise). Processing of 374 information returned to the CLI (called "screen scraping") is a 375 burdensome activity because the data is normally formatted for use by 376 a human operator, and because the layout of the data can vary from 377 device to device, and between different software versions. Despite 378 its ubiquity, this interface has never been standardized and is 379 unlikely to ever be standardized. I2RS does not involve CLI 380 standardization. 382 The second most popular interface for interrogation of a device's 383 state, statistics, and configuration is The Simple Network Management 384 Protocol (SNMP) and a set of relevant standards-based and proprietary 385 Management Information Base (MIB) modules. SNMP has a strong history 386 of being used by network managers to gather statistical and state 387 information about devices, including their routing systems. However, 388 SNMP is very rarely used to configure a device or any of its systems 389 for reasons that vary depending upon the network operator. Some 390 example reasons include complexity, the lack of desired configuration 391 semantics (e.g., configuration "roll-back", "sandboxing" or 392 configuration versioning), and the difficulty of using the semantics 393 (or lack thereof) as defined in the MIB modules to configure device 394 features. Therefore, SNMP is not considered as a candidate solution 395 for the problems motivating I2RS. 397 Finally, the IETF's Network Configuration (or NetConf) protocol has 398 made many strides at overcoming most of the limitations around 399 configuration that were just described. However, the lack of 400 standard data models have hampered the adoption of NetConf. 401 Naturally, I2RS may help define needed information and data models. 402 Additional extensions to handle multi-headed control may need to be 403 added to NetConf and/or appropriate data models. 405 Authors' Addresses 407 Alia Atlas (editor) 408 Juniper Networks 409 10 Technology Park Drive 410 Westford, MA 01886 411 USA 413 Email: akatlas@juniper.net 415 Thomas D. Nadeau 416 Juniper Networks 417 1194 N. Mathilda Ave. 418 Sunnyvale, CA 94089 419 USA 421 Email: tnadeau@juniper.net 422 Dave Ward 423 Cisco Systems 424 Tasman Drive 425 San Jose, CA 95134 426 USA 428 Email: wardd@cisco.com