idnits 2.17.1 draft-ietf-i2rs-problem-statement-06.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 (January 7, 2015) is 3397 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-07 == Outdated reference: A later version (-13) exists of draft-ietf-idr-ls-distribution-07 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: July 11, 2015 Brocade 6 D. Ward 7 Cisco Systems 8 January 7, 2015 10 Interface to the Routing System Problem Statement 11 draft-ietf-i2rs-problem-statement-06 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 July 11, 2015. 50 Copyright Notice 52 Copyright (c) 2015 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. Aspects to be Considered for an I2RS Protocol . . . . . . . . 7 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 9. Informative References . . . . . . . . . . . . . . . . . . . 9 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. 84 With scale, the need to automate even the simplest operation is 85 important, but even more critical is the ability for network 86 operators to quickly interact with these operations using mechanisms 87 such as policy-based controls. 89 With complexity comes the need for more sophisticated automated 90 network applications and orchestration software that can process 91 large quantities of data, run complex algorithms, and adjust the 92 routing state as required in order to support the network 93 applications, their computations and their policies. Changes made to 94 the routing state of a network by external applications must be 95 verifiable by those applications to ensure that the correct state has 96 been installed in the correct places. 98 In the past, mechanisms to support the requirements outlined above 99 have been developed piecemeal as proprietary solutions to specific 100 situations and needs. Many routing elements have an external 101 interface to interact with routing - but since these vary between 102 vendors, it is difficult to integrate use of those interfaces into a 103 network. The existence of such proprietary interfaces demonstrates 104 both that the need for such an interface is understood and that 105 technology solutions are understood. What is needed are 106 technological solutions with clearly defined operations that an 107 application can initiate, and data-models to support such actions. 108 These would facilitate wide-scale deployment of interoperable 109 applications and routing systems. These solutions must be designed 110 to facilitate rapid, isolated, secure, and dynamic changes to a 111 device's routing system. In order to address these needs, the 112 creation of an Interface to the Routing System (I2RS) is needed. 114 It should be noted that during the course of this document, the term 115 "applications" is used. This is meant to refer to an executable 116 program of some sort that has access to a network, such as an IP or 117 MPLS network. 119 2. I2RS Model and Problem Area for The IETF 121 Managing a network of production devices running a variety of routing 122 protocols involves interactions between multiple components within a 123 device. Some of these components are virtual while some are 124 physical; it may be desirable for many, or even all of these 125 components to be made available to be managed and manipulated by 126 applications, given that appropriate access, authentication, and 127 policy hurdles have been crossed. The management of only some of 128 these components require standardization, as others have already been 129 standardized. The I2RS model is intended to incorporate existing 130 mechanisms where appropriate, and to build extensions and new 131 protocols where needed. The I2RS model and problem area for IETF 132 work is illustrated in Figure 1. The I2RS Agent is associated with a 133 routing element, which may or may not be co-located with a data- 134 plane. The I2RS Client is used and controlled by one or more network 135 applications; they may be co-located or the I2RS Client might be part 136 of a separate application, such as an orchestrator or controller. 137 The scope of the data-models used by I2RS extends across the entire 138 routing system and I2RS protocol. 140 +***************+ +***************+ +***************+ 141 * Application * * Application * * Application * 142 +***************+ +***************+ +***************+ 143 | I2RS Client | ^ ^ 144 +---------------+ * * 145 ^ * **************** 146 | * * 147 | v v 148 | +---------------+ +-------------+ 149 | | I2RS Client |<------->| Other I2RS | 150 | +---------------+ | Agents | 151 | ^ +-------------+ 152 |________________ | 153 | | <== I2RS Protocol 154 | | 155 ...........................|..|.................................. 156 . v v . 157 . +*************+ +---------------+ +****************+ . 158 . * Policy * | | * Routing & * . 159 . * Database *<***>| I2RS Agent |<****>* Signaling * . 160 . +*************+ | | * Protocols * . 161 . +---------------+ +****************+ . 162 . ^ ^ ^ ^ . 163 . +*************+ * * * * . 164 . * Topology * * * * * . 165 . * Database *<*******+ * * v . 166 . +*************+ * * +****************+ . 167 . * +********>* RIB Manager * . 168 . * +****************+ . 169 . * ^ . 170 . v * . 171 . +*******************+ * . 172 . * Subscription & * * . 173 . * Configuration * v . 174 . * Templates for * +****************+ . 175 . * Measurements, * * FIB Manager * . 176 . * Events, QoS, etc. * * & Data Plane * . 177 . +*******************+ +****************+ . 178 ................................................................. 180 <--> interfaces inside the scope of I2RS Protocol 181 +--+ objects inside the scope of I2RS-defined behavior 183 <**> interfaces NOT within the scope of I2RS Protocol 184 +**+ objects NOT within the scope of I2RS-defined behavior 186 .... boundary of a router supporting I2RS 188 Figure 1: I2RS model and Problem Area 190 A critical aspect of I2RS is defining a suitable protocol or 191 protocols to carry messages between the I2RS Clients and the I2RS 192 Agent, and defining the data-models for use with those I2RS 193 protocol(s). The protocol should provide the key features specified 194 in Section 5. The data models should translate into a concise 195 transfer syntax, sent via the I2RS protocol, that is straightforward 196 for applications to use (e.g., a Web Services design paradigm). The 197 information transfer should use existing transport protocols to 198 provide the reliability, security, and timeliness appropriate for the 199 particular data. 201 The second critical aspect of I2RS is a set of meaningful data-models 202 for information in the routing system and in a topology database. 203 The data-model should describe the meaning and relationships of the 204 modeled items. The data-models should be separable across different 205 features of the managed components, versioned, and extendable. As 206 shown in Figure 1, I2RS needs to interact with several logical 207 components of the routing element: policy database, topology 208 database, subscription and configuration for dynamic measurements/ 209 events, routing signaling protocols, and its RIB manager. This 210 interaction is both for writing (e.g. to policy databases or RIB 211 manager) as well as for reading (e.g. dynamic measurement or topology 212 database). An application should be able to combine data from 213 individual routing elements to provide network-wide data-model(s). 215 3. Standard Data-Models of Routing State for Installation 217 There is a need to be able to precisely control routing and signaling 218 state based upon policy or external measures. This can range from 219 simple static routes to policy-based routing to static multicast 220 replication and routing state. This means that, to usefully model 221 next-hops, the data model employed needs to handle next-hop 222 indirection and recursion (e.g. a prefix X is routed like prefix Y) 223 as well as different types of tunneling and encapsulation. The 224 relevant MIB modules (for example [RFC4292]) lack the necessary 225 generality and flexibility. In addition, by having I2RS focus 226 initially on interfaces to the RIB layer (e.g. RIB, LIB, multicast 227 RIB, policy-based routing), the ability to use routing indirection 228 allows flexibility and functionality that can't be as easily obtained 229 at the forwarding layer. 231 Efforts to provide this level of control have focused on 232 standardizing data models that describe the forwarding plane (e.g. 233 ForCES [RFC3746]). I2RS posits that the routing system and a 234 router's OS provide useful mechanisms that applications could 235 usefully harness to accomplish application-level goals. 237 In addition to interfaces to the RIB layer, there is a need to 238 configure the various routing and signaling protocols with differing 239 dynamic state based upon application-level policy decisions. The 240 range desired is not available via MIB modules at the present time. 241 Additionally, on March 2, 2014, the IESG issued a statement about 242 Writeable MIB Modules [IESG-Statement] which is expected to limit 243 creation of future writeable MIB modules. 245 4. Learning Router Information 247 A router has information that applications may require so that they 248 can understand the network, verify that programmed state is installed 249 in the forwarding plane, measure the behavior of various flows, and 250 understand the existing configuration and state of the router. I2RS 251 provides a framework so that applications can register for 252 asynchronous notifications and can make specific requests for 253 information. 255 Although there are efforts to extend the topological information 256 available, even the best of these (e.g., BGP-LS 257 [I-D.ietf-idr-ls-distribution]) still provide only the current active 258 state as seen at the IGP layer and above. Detailed topological state 259 that provides more information than the current functional status 260 (e.g. active paths and links) is needed by applications. Examples of 261 missing information include paths or link that are potentially 262 available (e.g. administratively down) or unknown (e.g. to peers or 263 customers) to the routing topology. 265 For applications to have a feedback loop that includes awareness of 266 the relevant traffic, an application must be able to request the 267 measurement and timely, scalable reporting of data. While a 268 mechanism such as IPFIX [RFC5470] may be the facilitator for 269 delivering the data, the need for an application to be able to 270 dynamically request that measurements be taken and data delivered is 271 critical. 273 There are a wide range of events that applications could use for 274 either verification of router state before other network state is 275 changed (e.g. that a route has been installed), to act upon changes 276 to relevant routes by others, or upon router events (e.g. link up/ 277 down). While a few of these (e.g. link up/down) may be available via 278 MIB notifications today, the full range is not - nor has there been 279 successfully deployed the standardized ability to set up the router 280 to trigger different actions upon an event's occurrence so that a 281 rapid reaction can be accomplished. 283 5. Aspects to be Considered for an I2RS Protocol 285 This section describes required aspects of a protocol that could 286 support I2RS. Whether such a protocol is built upon extending 287 existing mechanisms or requires a new mechanism requires further 288 investigation. 290 The key aspects needed in an interface to the routing system are: 292 Multiple Simultaneous Asynchronous Operations: A single application 293 should be able to send multiple independent atomic operations via 294 I2RS without being required to wait for each to complete before 295 sending the next. 297 Very Fine Granularity of Data Locking for Writing: When an I2RS 298 operation is processed, it is required that the data locked for 299 writing is very granular (e.g. a particular prefix and route) 300 rather than extremely coarse, as is done for writing 301 configuration. This should improve the number of concurrent I2RS 302 operations that are feasible and reduce blocking delays. 304 Multi-Headed Control: Multiple applications may communicate to the 305 same I2RS agent in a minimally coordinated fashion. It is 306 necessary that the I2RS agent can handle multiple requests in a 307 well-known policy-based fashion. Data written can be owned by 308 different I2RS clients at different times; data may even be 309 overwritten by a different I2RS client. The details of how this 310 should be handled are described in [I-D.ietf-i2rs-architecture]. 312 Duplex: Communications can be established by either the I2RS client 313 (i.e.: that resides within the application or is used by it to 314 communicate with the I2RS agent), or the I2RS agent. Similarly, 315 events, acknowledgements, failures, operations, etc. can be sent 316 at any time by both the router and the application. The I2RS is 317 not a pure pull-model where only the application queries to pull 318 responses. 320 High-Throughput: At a minimum, the I2RS Agent and associated router 321 should be able to handle a considerable number of operations per 322 second (for example 10,000 per second to handle many individual 323 subscriber routes changing simultaneously). 325 Low-Latency: Within a sub-second time-scale, it should be possible 326 to complete simple operations (e.g. reading or writing a single 327 prefix route). 329 Multi-Channel: It should be possible for information to be 330 communicated via the interface from different components in the 331 router without requiring going through a single channel. For 332 example, for scaling, some exported data or events may be better 333 sent directly from the forwarding plane, while other interactions 334 may come from the control-plane. Thus a single TCP session would 335 not be a good match. 337 Scalable, Filterable Information Access: To extract information in a 338 scalable fashion that is more easily used by applications, the 339 ability to specify filtering constructs in an operation requesting 340 data or requesting an asynchronous notification is very valuable. 342 Secure Control and Access: Any ability to manipulate routing state 343 must be subject to authentication and authorization. Sensitive 344 routing information may also need to be provided via secure access 345 back to the I2RS client. Such communications must be integrity 346 protected. Some communications will also require confidentiality. 348 Extensible and Interoperability: Both the I2RS protocol and models 349 must be extensible and interoperate between different versions of 350 protocols and models. 352 6. Acknowledgements 354 The authors would like to thank Ken Gray, Ed Crabbe, Nic Leymann, 355 Carlos Pignataro, Kwang-koog Lee, Linda Dunbar, Sue Hares, Russ 356 Housley, Eric Grey, Qin Wu, and Stephen Kent for their suggestions 357 and review. 359 7. IANA Considerations 361 This document includes no request to IANA. 363 8. Security Considerations 365 Security is a key aspect of any protocol that allows state 366 installation and extracting of detailed router state. The need for 367 secure control and access is mentioned in Section 5 More 368 architectural security considerations are discussed in 369 [I-D.ietf-i2rs-architecture]. Briefly, the I2RS Agent is assumed to 370 have a separate authentication and authorization channel by which it 371 can validate both the identity and the permissions associated with an 372 I2RS Client. Mutual authentication between the I2RS Agent and I2RS 373 Client is required. Different levels of integrity, confidentiality, 374 and replay protection are relevant for different aspects of I2RS. 376 9. Informative References 378 [I-D.ietf-i2rs-architecture] 379 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 380 Nadeau, "An Architecture for the Interface to the Routing 381 System", draft-ietf-i2rs-architecture-07 (work in 382 progress), December 2014. 384 [I-D.ietf-idr-ls-distribution] 385 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 386 Ray, "North-Bound Distribution of Link-State and TE 387 Information using BGP", draft-ietf-idr-ls-distribution-07 388 (work in progress), November 2014. 390 [IESG-Statement] 391 IESG, "Writable MIB Module IESG Statement", March 2014, 392 . 395 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 396 "Forwarding and Control Element Separation (ForCES) 397 Framework", RFC 3746, April 2004. 399 [RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, April 400 2006. 402 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 403 "Architecture for IP Flow Information Export", RFC 5470, 404 March 2009. 406 Appendix A. Existing Management Interfaces 408 This section discusses as a single entity the combination of the 409 abstract data models, their representation in a data language, and 410 the transfer protocol commonly used with them. While other 411 combinations of these existing standard technologies are possible, 412 the ways described are those that have significant deployment. 414 There are three basic ways that routers are managed. The most 415 popular is the command line interface (CLI), which allows both 416 configuration and learning of device state. This is a proprietary 417 interface resembling a UNIX shell that allows for very customized 418 control and observation of a device, and, specifically of interest in 419 this case, its routing system. Some form of this interface exists on 420 almost every device (virtual or otherwise). Processing of 421 information returned to the CLI (called "screen scraping") is a 422 burdensome activity because the data is normally formatted for use by 423 a human operator, and because the layout of the data can vary from 424 device to device, and between different software versions. Despite 425 its ubiquity, this interface has never been standardized and is 426 unlikely to ever be standardized. CLI standardization is not 427 considered as a candidate solution for the problems motivating I2RS. 429 The second most popular interface for interrogation of a device's 430 state, statistics, and configuration is The Simple Network Management 431 Protocol (SNMP) and a set of relevant standards-based and proprietary 432 Management Information Base (MIB) modules. SNMP has a strong history 433 of being used by network managers to gather statistical and state 434 information about devices, including their routing systems. However, 435 SNMP is very rarely used to configure a device or any of its systems 436 for reasons that vary depending upon the network operator. Some 437 example reasons include complexity, the lack of desired configuration 438 semantics (e.g., configuration "roll-back", "sandboxing" or 439 configuration versioning), and the difficulty of using the semantics 440 (or lack thereof) as defined in the MIB modules to configure device 441 features. Therefore, SNMP is not considered as a candidate solution 442 for the problems motivating I2RS. 444 Finally, the IETF's Network Configuration (or NETCONF) protocol has 445 made many strides at overcoming most of the limitations around 446 configuration that were just described. However, the initial lack of 447 standard data models have hampered the adoption of NETCONF. 448 Naturally, I2RS may help define needed information and data models. 449 Additional extensions to handle multi-headed control may need to be 450 added to NETCONF and/or appropriate data models. 452 Authors' Addresses 454 Alia Atlas (editor) 455 Juniper Networks 456 10 Technology Park Drive 457 Westford, MA 01886 458 USA 460 Email: akatlas@juniper.net 462 Thomas D. Nadeau (editor) 463 Brocade 465 Email: tnadeau@lucidvision.com 466 Dave Ward 467 Cisco Systems 468 Tasman Drive 469 San Jose, CA 95134 470 USA 472 Email: wardd@cisco.com