idnits 2.17.1 draft-atlas-irs-problem-statement-00.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 30, 2012) is 4287 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 4 Intended status: Informational Juniper Networks 5 Expires: January 31, 2013 D. Ward 6 Cisco Systems 7 July 30, 2012 9 Interface to the Routing System Problem Statement 10 draft-atlas-irs-problem-statement-00 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 publically 22 documented interface specification. The interface needs to support 23 real-time, transaction-based interactions using efficient data models 24 and encodings. Furthermore, the interface must support a variety of 25 use cases including those where verified control feed-back loops are 26 needed. 28 This document expands upon these statements of requirements to 29 provide a problem statement for an interface to the Internet routing 30 system. 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 31, 2013. 49 Copyright Notice 51 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. IRS 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 IRS . . . . . . . . . . . . 6 71 6. Existing Management Interfaces . . . . . . . . . . . . . . . . 7 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 10. Informative References . . . . . . . . . . . . . . . . . . . . 9 76 Appendix A. Gaps and Concerns for SNMP . . . . . . . . . . . . . 9 77 Appendix B. Gaps and Concerns with NetConf . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 As modern networks grow in scale and complexity, the need for rapid 83 and dynamic control increases. With scale, the need to automate even 84 the simplest operations is important, but even more critical is the 85 ability to quickly interact with more complex operations such as 86 policy-based controls. 88 With complexity comes the need for more sophisticated automated 89 applications and orchestration software that can process large 90 quantities of data, run complex algorithms, and adjust the routing 91 state as required in order to support the applications, their 92 calculations and their policies. Changes made to the routing state 93 of a network by external applications must be verifiable by those 94 applications to ensure that the correct state has been installed in 95 the right places. 97 Mechanisms to support the requirements outlined above have been 98 developed piecemeal as proprietary solutions to specific situations 99 and needs. A standard protocol, clear operations that an application 100 can initiate with that protocol, and data-models to support such 101 actions would facilitate wide-scale deployment of interoperable 102 applications and routing systems. That a protocol designed to 103 facilitate rapid, isolated, secure, and dynamic routing changes is 104 needed motivates the creation of an Interface to The Routing System 105 (IRS). 107 2. IRS Model and Problem Area for The IETF 109 Managing a network of deployed devices running a variety of routing 110 protocols involves interactions among multiple different functions 111 and components that exist within the network. Some of these 112 components are virtual while some are physical; all should be made 113 available to be managed and manipulated by applications, given that 114 appropriate access, authentication, and policy hurdles have been 115 crossed. The management of only some of these components requires 116 standardization, as others have already been standardized. The IRS 117 model is intended to incorporate existing mechanisms where 118 appropriate, and to build extensions and new protocols where needed. 119 The IRS model and problem area proposed for IETF work is illustrated 120 in Figure 1. 122 +***************+ +***************+ +***************+ 123 * Application * * Application * * Application * 124 +***************+ +***************+ +***************+ 125 ^ ^ ^ 126 * * * 127 * * **************** 128 * * * 129 v v v 130 +---------------+ +---------------+ 131 | IRS Client | | IRS Client | 132 +---------------+ +---------------+ 133 ^ ^ 134 |________________ | 135 | | <== IRS Protocol 136 | | 137 ...........................|..|.................................. 138 . v v . 139 . +*************+ +---------------+ +****************+ . 140 . * Policy * | | * Routing & * . 141 . * Database *<***>| IRS Agent |<****>* Signaling * . 142 . +*************+ | | * Protocols * . 143 . +---------------+ +****************+ . 144 . ^ ^ ^ ^ . 145 . +*************+ * * * * . 146 . * Topology * * * * * . 147 . * Database *<*******+ * * v . 148 . +*************+ * * +****************+ . 149 . * +********>* RIB Manager * . 150 . * +****************+ . 151 . * ^ . 152 . v * . 153 . +*******************+ * . 154 . * Subscription & * * . 155 . * Configuration * v . 156 . * Templates for * +****************+ . 157 . * Measurements, * * FIB Manager * . 158 . * Events, QoS, etc. * * & Data Plane * . 159 . +*******************+ +****************+ . 160 ................................................................. 162 <--> interfaces inside the scope of IRS 163 +--+ objects inside the scope of IRS 165 <**> interfaces NOT within the scope of IRS 166 +**+ objects NOT within the scope of IRS 168 .... boundary of a router participating in the IRS 169 Figure 1: IRS model and Problem Area 171 A critical aspect of IRS is defining a suitable protocol or protocols 172 to carry messages between the IRS Clients and the IRS Agent, and 173 defining the encapsulation of data within those messages. This 174 should provide a clear transfer syntax that is straightforward for 175 applications to use (e.g., a Web Services design paradigm), and 176 should provide the key features specified in Section 5. 178 The second critical aspect is semantic-aware data-models for 179 information in the routing system and in a topology database. The 180 data-models should be separable across different features of the 181 managed components, versioned, and combine to provide a network data- 182 model. 184 3. Standard Data-Models of Routing State for Installation 186 There is a need to be able to precisely control routing and signaling 187 state based upon policy or external measures. This can range from 188 simple static routes to policy-based routing to static multicast 189 replication and routing state. This means that the data model 190 employed needs to handle indirection as well as different types of 191 tunneling and encapsulation. The relevant MIB modules (for example 192 [RFC4292]) lack the necessary generality and flexibility. In 193 addition, by having IRS focus initially on interfaces to the RIB 194 layer (e.g. RIB, LFIB, multicast RIB, policy-based routing), the 195 ability to use routing indirection allows flexibility and 196 functionality that can't be as easily obtained at the forwarding 197 layer. 199 Efforts to provide this level of control have focused on 200 standardizing data models that describe the forwarding plane (e.g. 201 ForCES [RFC3746]). IRS recognizes that the routing system and a 202 router's OS provide useful mechanisms that applications could 203 usefully harness to accomplish application-level goals. 205 In addition to interfaces to the RIB layer, there is a need to 206 configure the various routing and signaling protocols with differing 207 dynamic state based upon application-level policy decisions. The 208 range desired is not available via MIBs at the present time. 210 4. Learning Router Information 212 A router has information that applications may require so that they 213 can understand the network, verify that programmed state is installed 214 in the forwarding plane, measure the behavior of various flows, and 215 understand the existing configuration and state of the router. IRS 216 provides a framework for applications to register for asynchronous 217 notifications and for them to make specific requests for information. 219 Although there are efforts to extend the topological information 220 available, even the best of these (e.g., BGP-LS 221 [I-D.gredler-idr-ls-distribution]) still provides only the current 222 active state as seen at the IGP layer and above. Detailed 223 topological state that provides more information than the current 224 functional status is needed by applications; only the active paths or 225 links are known versus those desired or unknown to the routing 226 topology. 228 For applications to have a feedback loop that includes awareness of 229 the relevant traffic, an application must be able to request the 230 measurement and timely, scalable reporting of data. While a 231 mechanism such as IPFIX [RFC5470] may be the facilitator for 232 delivering the data, the need for an application to be able to 233 dynamically request that measurements be taken and data delivered is 234 critical. 236 There are a wide range of events that applications could use for 237 either verification of router state before other network state is 238 changed (e.g. that a route has been installed), to act upon changes 239 to relevant routes by others, or upon router events (e.g. link up/ 240 down). While a few of these (e.g. link up/down) may be available via 241 MIB Notifications today, the full range is not - nor is there the 242 ability to set up the router to trigger different actions upon an 243 event's occurrence. 245 5. Desired Aspects of a Protocol for IRS 247 This section describes required aspects of a protocol that could 248 support IRS. Whether such a protocol is built upon extending 249 existing mechanisms or requires a new mechanism requires further 250 investigation. 252 The key aspects needed in an interface to the routing system are: 254 Multiple Simultaneous Asynchronous Operations: A single application 255 should be able to send multiple operations to IRS without needing 256 to wait for each to complete before sending the next. 258 Configuration Not Re-Processed: When an IRS operation is processed, 259 it does not require that any of the configuration be processed. 260 I.e., the desired behavior is orthogonal to the static 261 configuration. 263 Duplex: Communications can be established by either the router or 264 the application. Similarly, events, acknowledgements, failures, 265 operations, etc. can be sent at any time by both the router and 266 the application. The IRS is not a pure pull-model where only the 267 application queries to pull responses. 269 High-Throughput: At a minimum, the IRS Agent and associated router 270 should be able to handle hundreds of simple operations per second. 272 Responsive: It should be possible to complete simple operations 273 within a sub-second time-scale. 275 Multi-Channel: It should be possible for information to be 276 communicated via the interface from different components in the 277 router without requiring going through a single channel. For 278 example, for scaling, some exported data or events may be better 279 sent directly from the forwarding plane, while other interactions 280 may come from the control-plane. Thus a single TCP session would 281 not be a good match. 283 Timing of State Installation and Expiration: The ability to have 284 state installed with different lifetimes and different start-times 285 is very valuable. In particular, the ability of an IRS client to 286 request that a pre-sent operation be started based upon a dynamic 287 event would provide a powerful functionality. 289 To extract information in a scalable fashion that is more easily used 290 by applications, the ability to specify filtering constructs in an 291 operation requesting data or requesting an asynchronous notification 292 is very valuable. 294 6. Existing Management Interfaces 296 This section discusses the combination of the abstract data models, 297 their representation in a data language, and the transfer protocol 298 commonly used with them as a single entity. While other combinations 299 are possible, the combinations described are those that have 300 significant deployment. 302 There are three basic ways that routers are managed. The most 303 popular is the command line interface (CLI), which allows both 304 configuration and learning of device state. This is a proprietary 305 interface resembling a UNIX shell that allows for very customized 306 control and observation of a device, and, specifically of interest in 307 this case, its routing system. Some form of this interface exists on 308 almost every device (virtual or otherwise). Processing of 309 information returned to the CLI (called "screen scraping") is a 310 burdensome activity because the data is normally formatted for use by 311 a human operator, and because the layout of the data can vary from 312 device to device, and between different software versions. Despite 313 its ubiquity, this interface has never been standardized and is 314 unlikely to ever be standardized. IRS does not involve CLI 315 standardization. 317 The second most popular interface for interrogation of a device's 318 state, statistics, and configuration is The Simple Network Management 319 Protocol (SNMP) and a set of relevant standards-based and proprietary 320 Management Information Base (MIB) modules. SNMP has a strong history 321 of being used by network managers to gather statistical and state 322 information about devices, including their routing systems. However, 323 SNMP is very rarely used to configure a device or any of its systems 324 for reasons that vary depending upon the network operator. Some 325 example reasons include complexity, the lack of desired configuration 326 semantics (e.g., configuration "roll-back", "sandboxing" or 327 configuration versioning), and the difficulty of using the semantics 328 (or lack thereof) as defined in the MIB modules to configure device 329 features. Therefore, SNMP is not considered as a candidate solution 330 for the problems motivating IRS. 332 Finally, the IETF's Network Configuration (or NetConf) protocol has 333 made many strides at overcoming most of the limitations around 334 configuration that were just described. However, the lack of 335 standard data models have hampered the adoption of NetConf. 337 7. Acknowledgements 339 The authors would like to thank Ken Gray for their suggestions and 340 review. 342 8. IANA Considerations 344 This document includes no request to IANA. 346 9. Security Considerations 348 Security is a key aspect of any protocol that allows state 349 installation and extracting of detailed router state. More 350 investigation remains to fully define the security requirements, such 351 as authorization and authentication levels. 353 10. Informative References 355 [I-D.gredler-idr-ls-distribution] 356 Gredler, H., Medved, J., Previdi, S., and A. Farrel, 357 "North-Bound Distribution of Link-State and TE Information 358 using BGP", draft-gredler-idr-ls-distribution-02 (work in 359 progress), July 2012. 361 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 362 "Forwarding and Control Element Separation (ForCES) 363 Framework", RFC 3746, April 2004. 365 [RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, 366 April 2006. 368 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 369 "Architecture for IP Flow Information Export", RFC 5470, 370 March 2009. 372 Appendix A. Gaps and Concerns for SNMP 374 Though SNMP can allow state to be written, the overhead of the 375 required infrastructure is quite high. Clients and servers that wish 376 to use SNMP must build in and understand a large number of MIB 377 modules, including many proprietary modules. Even when ignoring the 378 overhead in building the SNMP processing and handling functions into 379 an application, these properties lend themselves well to read-only 380 operations. A critical lack in MIB modules for read-write (i.e., for 381 configuration) operations is that there is no semantic understanding 382 of the objects defined in the modules encoded in those modules. Any 383 required semantic knowledge must be specifically hand-coded into 384 applications or ignored. Further, many MIB modules do not allow the 385 writing of state, and this limits coverage; owing to the cumbersome 386 nature, there has not been interest in increasing coverage. 388 An additional deficiency in using SNMP MIB modules either for reading 389 or writing comes in the inherent co-mingling of semantics and syntax 390 in the form of indexing requirements. SNMP MIB modules contain 391 tables that also define an index format. This format is then 392 translated - often mapped onto - a device's actual implementation. 393 Such a mapping means an implementation either matches the module's 394 indexing during searches or not; if not, then an implementation is 395 slowed down when it searches for objects. Even in not-so-extreme 396 cases, such slow performance can result in the SNMP manager's request 397 timing-out owing to the delay of the SNMP agent's response. 399 For example, if a search of N*M objects is stipulated as (N, M) in 400 the standard MIB module, but the implementation happens to choose to 401 index its tables internally as (M, N), this will result in search 402 times of O(N^2). When N or M become large, as they do in routing 403 tables, this results in wasted processing cycles for the device, and 404 either extremely long wait times for queries, or simply a lack of 405 answers to queries. It is a clear requirement for the IRS to not 406 suffer from this issue. 408 In addition to these difficulties, SNMP matches up to the key needed 409 aspects as follows: 411 Multiple Simultaneous Asynchronous Operations: Supported, but 412 difficult for configuration. 414 Configuration Not Re-Processed: Supported 416 Duplex: The manager must initiate communications with the SNMP 417 agent on the router. With the limited exception of Notifications 418 and InformRequests defined in a MIB module, this is a pull model. 420 High-Throughput: Possible 422 Responsive: Possible 424 Multi-Channel: Possible 426 The key gaps identified for SNMP are: 428 a. Infrastructure Overhead 430 b. Lack of Semantic Information in the Data-Model 432 c. Required Indexing, from mingling of semantics and syntax, badly 433 impacting performance or driving implementation decisions. 435 d. Limited interest and use for configuration 437 e. Communication model isn't naturally duplex. 439 Appendix B. Gaps and Concerns with NetConf 441 While NetConf has solved many of the deficiencies present in SNMP in 442 terms of configuration, it still does not satisfy a number of 443 requirements needed to manage today's routing information. First, 444 the lack of standard data models have hampered the adoption of 445 NetConf; a significant amount of per-vendor customization is still 446 needed. The transport mechanisms that are currently defined (e.g., 447 SOAP/BEEP) for NetConf are not those commonly used by modern 448 applications (e.g., ReST or JSON). 450 NetConf primarily facilitates configuration rather than reading of 451 state or handling asynchronous events. 453 NetConf matches up to the key needed aspects as follows: 455 Multiple Simultaneous Asynchronous Operations: Not Possible 457 Configuration Not Re-Processed: Not Possible 459 Duplex: Not Possible - strict pull model. 461 High-Throughput: Unlikely - Can depend on configuration size 463 Responsive: Unlikely - Can depend on configuration size 465 Multi-Channel: Not Possible 467 Authors' Addresses 469 Alia Atlas (editor) 470 Juniper Networks 471 10 Technology Park Drive 472 Westford, MA 01886 473 USA 475 Email: akatlas@juniper.net 477 Thomas Nadeau 478 Juniper Networks 479 1194 N. Mathilda Ave. 480 Sunnyvale, CA 94089 481 USA 483 Email: tnadeau@juniper.net 484 Dave Ward 485 Cisco Systems 486 Tasman Drive 487 San Jose, CA 95134 488 USA 490 Email: wardd@cisco.com