idnits 2.17.1 draft-atlas-i2rs-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: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-atlas-i2rs-problem-statement-01', but the file name used is 'draft-atlas-i2rs-problem-statement-00' 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 (February 21, 2013) is 4054 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 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 T. Nadeau 4 Intended status: Informational Juniper Networks 5 Expires: August 25, 2013 D. Ward 6 Cisco Systems 7 February 21, 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, transaction-based interactions using data models and 24 encodings that are efficient and potentially different from those 25 available today. Furthermore, the interface must be tailored to 26 support a 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 August 25, 2013. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 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. Existing Management Interfaces . . . . . . . . . . . . . . . . 7 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 75 10. Informative References . . . . . . . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 78 1. Introduction 80 As modern networks grow in scale and complexity, the need for rapid 81 and dynamic control increases. With scale, the need to automate even 82 the simplest operations is important, but even more critical is the 83 ability to quickly interact with more complex operations such as 84 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 applications, their 90 calculations 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 right places. 95 Mechanisms to support the requirements outlined above have been 96 developed piecemeal as proprietary solutions to specific situations 97 and needs. A standard protocol, clearly defined operations that an 98 application can initiate with that protocol, and data-models to 99 support such actions would facilitate wide-scale deployment of 100 interoperable applications and routing systems. That a protocol 101 designed to facilitate rapid, isolated, secure, and dynamic routing 102 changes is needed motivates the creation of an Interface to The 103 Routing System (I2RS). 105 2. I2RS Model and Problem Area for The IETF 107 Managing a network of deployed devices running a variety of routing 108 protocols involves interactions among multiple different components 109 that exist within the network. Some of these components are virtual 110 while some are physical; all should be made available to be managed 111 and manipulated by applications, given that appropriate access, 112 authentication, and policy hurdles have been crossed. The management 113 of only some of these components requires standardization, as others 114 have already been standardized. The I2RS model is intended to 115 incorporate existing mechanisms where appropriate, and to build 116 extensions and new protocols where needed. The I2RS model and 117 problem area proposed for IETF work is illustrated in Figure 1. The 118 I2RS Agent is associated with a routing element, which may or may not 119 be co-located with a data-plane. The I2RS Client is used and 120 controlled by a network application; they may be co-located or the 121 I2RS Client might be part of a separate application, such as an 122 orchestrator or controller. 124 +***************+ +***************+ +***************+ 125 * Application * * Application * * Application * 126 +***************+ +***************+ +***************+ 127 | I2RS Client | ^ ^ 128 +---------------+ * * 129 ^ * **************** 130 | * * 131 | v v 132 | +---------------+ 133 | | I2RS Client | 134 | +---------------+ 135 | ^ 136 |________________ | 137 | | <== I2RS Protocol 138 | | 139 ...........................|..|.................................. 140 . v v . 141 . +*************+ +---------------+ +****************+ . 142 . * Policy * | | * Routing & * . 143 . * Database *<***>| I2RS Agent |<****>* Signaling * . 144 . +*************+ | | * Protocols * . 145 . +---------------+ +****************+ . 146 . ^ ^ ^ ^ . 147 . +*************+ * * * * . 148 . * Topology * * * * * . 149 . * Database *<*******+ * * v . 150 . +*************+ * * +****************+ . 151 . * +********>* RIB Manager * . 152 . * +****************+ . 153 . * ^ . 154 . v * . 155 . +*******************+ * . 156 . * Subscription & * * . 157 . * Configuration * v . 158 . * Templates for * +****************+ . 159 . * Measurements, * * FIB Manager * . 160 . * Events, QoS, etc. * * & Data Plane * . 161 . +*******************+ +****************+ . 162 ................................................................. 164 <--> interfaces inside the scope of I2RS 165 +--+ objects inside the scope of I2RS 167 <**> interfaces NOT within the scope of I2RS 168 +**+ objects NOT within the scope of I2RS 170 .... boundary of a router participating in the I2RS 171 Figure 1: I2RS model and Problem Area 173 A critical aspect of I2RS is defining a suitable protocol or 174 protocols to carry messages between the I2RS Clients and the I2RS 175 Agent, and defining the encapsulation of data within those messages. 176 This should provide a clear transfer syntax that is straightforward 177 for applications to use (e.g., a Web Services design paradigm), and 178 should provide the key features specified in Section 5. 180 The second critical aspect is semantic-aware data-models for 181 information in the routing system and in a topology database. The 182 data-models should be separable across different features of the 183 managed components, versioned, and combine to provide a network data- 184 model. 186 3. Standard Data-Models of Routing State for Installation 188 There is a need to be able to precisely control routing and signaling 189 state based upon policy or external measures. This can range from 190 simple static routes to policy-based routing to static multicast 191 replication and routing state. This means that, to usefully model 192 next-hops, the data model employed needs to handle indirection as 193 well as different types of tunneling and encapsulation. The relevant 194 MIB modules (for example [RFC4292]) lack the necessary generality and 195 flexibility. In addition, by having I2RS focus initially on 196 interfaces to the RIB layer (e.g. RIB, LFIB, multicast RIB, policy- 197 based routing), the ability to use routing indirection allows 198 flexibility and functionality that can't be as easily obtained at the 199 forwarding layer. 201 Efforts to provide this level of control have focused on 202 standardizing data models that describe the forwarding plane (e.g. 203 ForCES [RFC3746]). I2RS posits that the routing system and a 204 router's OS provide useful mechanisms that applications could 205 usefully harness to accomplish application-level goals. 207 In addition to interfaces to the RIB layer, there is a need to 208 configure the various routing and signaling protocols with differing 209 dynamic state based upon application-level policy decisions. The 210 range desired is not available via MIBs at the present time. 212 4. Learning Router Information 214 A router has information that applications may require so that they 215 can understand the network, verify that programmed state is installed 216 in the forwarding plane, measure the behavior of various flows, and 217 understand the existing configuration and state of the router. I2RS 218 provides a framework for applications to register for asynchronous 219 notifications and for them to make specific requests for information. 221 Although there are efforts to extend the topological information 222 available, even the best of these (e.g., BGP-LS 223 [I-D.gredler-idr-ls-distribution]) still provides only the current 224 active state as seen at the IGP layer and above. Detailed 225 topological state that provides more information than the current 226 functional status is needed by applications; only the active paths or 227 links are known versus those potentially available or unknown to the 228 routing topology. 230 For applications to have a feedback loop that includes awareness of 231 the relevant traffic, an application must be able to request the 232 measurement and timely, scalable reporting of data. While a 233 mechanism such as IPFIX [RFC5470] may be the facilitator for 234 delivering the data, the need for an application to be able to 235 dynamically request that measurements be taken and data delivered is 236 critical. 238 There are a wide range of events that applications could use for 239 either verification of router state before other network state is 240 changed (e.g. that a route has been installed), to act upon changes 241 to relevant routes by others, or upon router events (e.g. link up/ 242 down). While a few of these (e.g. link up/down) may be available via 243 MIB Notifications today, the full range is not - nor is there the 244 standardized ability to set up the router to trigger different 245 actions upon an event's occurrence. 247 5. Desired Aspects of a Protocol for I2RS 249 This section describes required aspects of a protocol that could 250 support I2RS. Whether such a protocol is built upon extending 251 existing mechanisms or requires a new mechanism requires further 252 investigation. 254 The key aspects needed in an interface to the routing system are: 256 Multiple Simultaneous Asynchronous Operations: A single application 257 should be able to send multiple operations to I2RS without needing 258 to wait for each to complete before sending the next. 260 Very Fine Granularity of Data Locking for Writing: When an I2RS 261 operation is processed, it is required that the data locked for 262 writing is very granular (e.g. a particular prefix and route) 263 rather than extremely coarse, as is done for writing 264 configuration. This should improve the number of concurrent I2RS 265 operations that are feasible and reduce blocking delays. 267 Multi-Headed Control: Multiple applications may communicate to the 268 same I2RS agent in a minimally coordinated fashion. It is 269 necessary that the I2RS agent can handle multiple conflicting 270 requests in a well-known policy-based fashion. Data written can 271 be owned by different I2RS clients. 273 Duplex: Communications can be established by either the router or 274 the application. Similarly, events, acknowledgements, failures, 275 operations, etc. can be sent at any time by both the router and 276 the application. The I2RS is not a pure pull-model where only the 277 application queries to pull responses. 279 High-Throughput: At a minimum, the I2RS Agent and associated router 280 should be able to handle hundreds of simple operations per second. 282 Responsive: It should be possible to complete simple operations 283 within a sub-second time-scale. 285 Multi-Channel: It should be possible for information to be 286 communicated via the interface from different components in the 287 router without requiring going through a single channel. For 288 example, for scaling, some exported data or events may be better 289 sent directly from the forwarding plane, while other interactions 290 may come from the control-plane. Thus a single TCP session would 291 not be a good match. 293 Temporal State for Installation and Expiration: The ability to have 294 state installed with different lifetimes and different start-times 295 is very valuable. In particular, the ability of an I2RS client to 296 request that a pre-sent operation be started based upon a dynamic 297 event would provide a powerful functionality. 299 Scalable, Filterable Information Access: To extract information in a 300 scalable fashion that is more easily used by applications, the 301 ability to specify filtering constructs in an operation requesting 302 data or requesting an asynchronous notification is very valuable. 304 6. Existing Management Interfaces 306 This section discusses as a single entity the combination of the 307 abstract data models, their representation in a data language, and 308 the transfer protocol commonly used with them. While other 309 combinations are possible, the ways described are those that have 310 significant deployment. 312 There are three basic ways that routers are managed. The most 313 popular is the command line interface (CLI), which allows both 314 configuration and learning of device state. This is a proprietary 315 interface resembling a UNIX shell that allows for very customized 316 control and observation of a device, and, specifically of interest in 317 this case, its routing system. Some form of this interface exists on 318 almost every device (virtual or otherwise). Processing of 319 information returned to the CLI (called "screen scraping") is a 320 burdensome activity because the data is normally formatted for use by 321 a human operator, and because the layout of the data can vary from 322 device to device, and between different software versions. Despite 323 its ubiquity, this interface has never been standardized and is 324 unlikely to ever be standardized. I2RS does not involve CLI 325 standardization. 327 The second most popular interface for interrogation of a device's 328 state, statistics, and configuration is The Simple Network Management 329 Protocol (SNMP) and a set of relevant standards-based and proprietary 330 Management Information Base (MIB) modules. SNMP has a strong history 331 of being used by network managers to gather statistical and state 332 information about devices, including their routing systems. However, 333 SNMP is very rarely used to configure a device or any of its systems 334 for reasons that vary depending upon the network operator. Some 335 example reasons include complexity, the lack of desired configuration 336 semantics (e.g., configuration "roll-back", "sandboxing" or 337 configuration versioning), and the difficulty of using the semantics 338 (or lack thereof) as defined in the MIB modules to configure device 339 features. Therefore, SNMP is not considered as a candidate solution 340 for the problems motivating I2RS. 342 Finally, the IETF's Network Configuration (or NetConf) protocol has 343 made many strides at overcoming most of the limitations around 344 configuration that were just described. However, the lack of 345 standard data models have hampered the adoption of NetConf. 346 Naturally, I2RS may help define needed information and data models. 347 Additional extensions to handle multi-headed control and time-based 348 state installation and expiration may need to be added to NetConf 349 and/or appropriate data models. 351 7. Acknowledgements 353 The authors would like to thank Ken Gray for his suggestions and 354 review. 356 8. IANA Considerations 358 This document includes no request to IANA. 360 9. Security Considerations 362 Security is a key aspect of any protocol that allows state 363 installation and extracting of detailed router state. More 364 investigation remains to fully define the security requirements, such 365 as authorization and authentication levels. 367 10. Informative References 369 [I-D.gredler-idr-ls-distribution] 370 Gredler, H., Medved, J., Previdi, S., and A. Farrel, 371 "North-Bound Distribution of Link-State and TE Information 372 using BGP", draft-gredler-idr-ls-distribution-02 (work in 373 progress), July 2012. 375 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 376 "Forwarding and Control Element Separation (ForCES) 377 Framework", RFC 3746, April 2004. 379 [RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, 380 April 2006. 382 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 383 "Architecture for IP Flow Information Export", RFC 5470, 384 March 2009. 386 Authors' Addresses 388 Alia Atlas (editor) 389 Juniper Networks 390 10 Technology Park Drive 391 Westford, MA 01886 392 USA 394 Email: akatlas@juniper.net 395 Thomas D. Nadeau 396 Juniper Networks 397 1194 N. Mathilda Ave. 398 Sunnyvale, CA 94089 399 USA 401 Email: tnadeau@juniper.net 403 Dave Ward 404 Cisco Systems 405 Tasman Drive 406 San Jose, CA 95134 407 USA 409 Email: wardd@cisco.com