idnits 2.17.1 draft-white-i2rs-use-case-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 27, 2013) is 3894 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 403, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-lapukhov-bgp-routing-large-dc-06 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 i2rs R. White 3 Internet-Draft IETF 4 Intended status: Informational S. Hares 5 Expires: February 28, 2014 ADARA 6 A. Retana 7 Cisco Systems, Inc. 8 August 27, 2013 10 Protocol Independent Use Cases for an Interface to the Routing System 11 draft-white-i2rs-use-case-01 13 Abstract 15 Programmatic interfaces to provide control over individual forwarding 16 devices in a network promise to reduce operational costs while 17 improving scaling, control, and visibility into the operation of 18 large scale networks. To this end, several programmatic interfaces 19 have been proposed. OpenFlow, for instance, provides a mechanism to 20 replace the dynamic control plane processes on individual forwarding 21 devices throughout a network with off box processes that interact 22 with the forwarding tables on each device. Another example is 23 NETCONF, which provides a fast and flexible mechanism to interact 24 with device configuration and policy. 26 There is, however, no proposal which provides an interface to all 27 aspects of the routing system as a system. Such a system would not 28 interact with the forwarding system on individual devices, but rather 29 with the control plane processes already used to discover the best 30 path to any given destination through the network, as well as 31 interact with the routing information base (RIB), which feeds the 32 forwarding table the information needed to actually switch traffic at 33 a local level. 35 This document describes a set of use cases such a system could 36 fulfill. It is designed to provide underlying support for the 37 framework, policy, and other drafts describing the Interface to the 38 Routing System (I2RS). 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on February 28, 2014. 57 Copyright Notice 59 Copyright (c) 2013 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 75 2. Distributed Reaction to Network Based Attacks . . . . . . . . 3 76 3. Remote Service Routing . . . . . . . . . . . . . . . . . . . 4 77 4. Within Data Center Routing . . . . . . . . . . . . . . . . . 6 78 5. Temporary Overlays between Data Centers . . . . . . . . . . . 7 79 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 81 6.2. Informative References . . . . . . . . . . . . . . . . . 9 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 84 1. Introduction 86 The Interface to the Routing System Framework 87 [I-D.ward-i2rs-framework] describes a mechanism where the distributed 88 control plane can be augmented by an outside control plane through an 89 open, accessible interface, including the Routing Information Base 90 (RIB), in individual devices. This represents a "halfway point" 91 between completely replacing the traditional distributed control 92 plane and directly configuring devices to distribute policy or 93 modifications to routing through off-board processes. This draft 94 proposes a set of use cases that explain where the work described in 95 [I2RS - should this be a reference to the framework as above, or to 96 the architecture, or the WG charter or ??] will be useful. The goal 97 is to inform not only the community's understanding of where I2RS 98 fits in the larger scheme of SDN proposals, but also to inform the 99 requirements, framework, and specification of I2RS to provide the 100 best fit for the purposes which make the most sense for this type of 101 programmatic interface. 103 Towards this end the authors have searched for a number of different 104 use cases representing not only complex modifications of the control 105 plane, including interaction with applications and network 106 conditions, but also simpler use cases. The array of use cases 107 presented here should provide the reader with a solid understanding 108 of the power of an SDN solution that will augment, rather than 109 replace, traditional distributed control planes. 111 Each use case is presented in its own section. 113 2. Distributed Reaction to Network Based Attacks 115 Quickly modifying the control plane to reroute traffic for one 116 destination while leaving a standard configuration in place (filters, 117 metrics, and other policy mechanisms) is a challenge --but this is 118 precisely the challenge of a network engineer attempting to deal with 119 a network incursion. The ability to redirect specific flows of 120 information or specific classes of traffic into, through, and back 121 out of traffic analyzers on the fly is crucial in these situations. 122 The following network diagram provides an illustration of the 123 problem. 125 Valid Source---\ /--R2--------------------\ 126 R1 R3---Valid Destination 127 Attack Source--/ \--Monitoring Device-----/ 129 Modifying the cost of the link between R1 and R2 to draw the attack 130 traffic through the monitoring device in the distributed control 131 plane will, of necessity, also draw the valid traffic through the 132 monitoring device. Drawing valid traffic through a monitoring device 133 introduces delay, jitter, and other quality of service issues, as 134 well as posing a problem for the monitoring device itself in terms of 135 traffic load and management. 137 An I2RS controller could stand between the detection of the attack 138 and the control plane to facilitate the rapid modification of control 139 and forwarding planes to either block the traffic or redirect it to 140 analysis devices connected to the network. 142 Summary of IRS Capabilities and Interactions: 144 o The ability to monitor the available routes installed in the RIB 145 of each forwarding device, including near real time notification 146 of route installation and removal. This information must include 147 the destination prefix (NLRI), a table identifier (if the 148 forwarding device has multiple forwarding instances), the metric 149 of the installed route, and an identifier indicating the 150 installing process. 152 o The ability to install source and destination based routes in the 153 local RIB of each forwarding device. This must include the 154 ability to supply the destination prefix (NLRI), the source prefix 155 (NLRI), a table identifier (if the forwarding device has multiple 156 forwarding instances), a route preference, a route metric, a next 157 hop, an outbound interface, and a route process identifier. 159 o The ability to install a route to a null destination, effectively 160 filtering traffic to this destination. 162 o The ability to interact with various policies configured on the 163 forwarding devices, in order to inform the policies implemented by 164 the dynamic routing processes. This interaction should be through 165 existing configuration mechanisms, such as NETCONF, and should be 166 recorded in the configuration of the local device so operators are 167 aware of the full policy implemented in the network from the 168 running configuration. 170 o The ability to interact with traffic flow and other network 171 traffic level measurement protocols and systems, in order to 172 determine path performance, top talkers, and other information 173 required to make an informed path decision based on locally 174 configured policy. 176 3. Remote Service Routing 178 In hub and spoke overlay networks, there is always an issue with 179 balancing between the information held in the spoke routing table, 180 optimal routing through the network underlying the overlay, and 181 mobility. Most solutions in this space use some form of centralized 182 route server that acts as a directory of all reachable destinations 183 and next hops, a protocol by which spoke devices and this route 184 server communicate, and caches at the remote sites. 186 An I2RS solution would use the same elements, but with a different 187 control plane. Remote sites would register (or advertise through 188 some standard routing protocol, such as BGP), the reachable 189 destinations at each site, along with the address of the router (or 190 other device) used to reach that destination. These would, as 191 always, be stored in a route server (or several redundant route 192 servers) at a central location. 194 When a remote site sends a set of packets to the central location 195 that are eventually destined to some other remote site, the central 196 location can forward this traffic, but at the same time simply 197 directly insert the correct routing information into the remote 198 site's routing table. If the location of the destination changes, 199 the route server can directly modify the routing information at the 200 remote site as needed. 202 An interesting aspect of this solution is that no new and specialized 203 protocols are needed between the remote sites and the centralized 204 route server(s). Normal routing protocols can be used to notify the 205 centralized route server(s) of modifications in reachability 206 information, and the route server(s) can respond as needed, based on 207 local algorithms optimized for a particular application or network. 208 For instance, short lived flows might be allowed to simply pass 209 through the hub site with no reaction, while longer lived flows might 210 warrant a specific route to be installed in the remote router. 211 Algorithms can also be developed that would optimize traffic flow 212 through the overlay, and also to remove routing entries from remote 213 devices when they are no longer needed based on far greater 214 intelligence than simple non-use for some period of time. 216 Summary of IRS Capabilities and Interactions: 218 o The ability to read the local RIB of each forwarding device, 219 including the destination prefix (NLRI), a table identifier (if 220 the forwarding device has multiple forwarding instances), the 221 metric of each installed route, a route preference, and an 222 identifier indicating the installing process. 224 o The ability to monitor the available routes installed in the RIB 225 of each forwarding device, including near real time notification 226 of route installation and removal. This information must include 227 the destination prefix (NLRI), a table identifier (if the 228 forwarding device has multiple forwarding instances), the metric 229 of the installed route, and an identifier indicating the 230 installing process. 232 o The ability to install destination based routes in the local RIB 233 of each forwarding device. This must include the ability to 234 supply the destination prefix (NLRI), a table identifier (if the 235 forwarding device has multiple forwarding instances), a route 236 preference, a route metric, a next hop, an outbound interface, and 237 a route process identifier. 239 4. Within Data Center Routing 241 Data Centers have evolved into massive topologies with thousands of 242 server racks and millions of hosts. Data Centers use BGP with ECMP, 243 ISIS (with multiple LAGs), or other protocols to tie the data center 244 together. Data centers are currently designed around a three or four 245 tier structure with: server, top-of-rack switches, aggregation 246 switches, and router interfacing the data center to the Internet. 247 [I-D.lapukhov-bgp-routing-large-dc] examines many of these elements 248 of data center design. 250 One element of these Data Center routing infrastructures is the 251 ability to quickly read topology information and execute 252 configuration from a centralized location. Key to this environment 253 is the tight feedback loop between learning about topology changes or 254 loading changes, and instantiating new routing policy. Without I2RS, 255 may Data Centers are using extra physical topologies or logical 256 topologies to work around the features. 258 An I2RS solution would use the same elements, but with a different 259 control plane. The I2RS enabled control plane could provide the Data 260 Center 4 tier infrastructure the quick access to topology and data 261 flow information needed for traffic flow optimization. Changes to 262 the Data Center infrastructure done via I2RS could have a tight 263 feedback loop. 265 Again, this solution would reduce the need for new and specialized 266 protocols while giving the Data Center the control it desire. The 267 I2RS routing interface could be extended to virtual routers. 269 Summary of IRS Capabilities and Interactions: 271 o The ability to read the local RIB of each forwarding device, 272 including the destination prefix (NLRI), a table identifier (if 273 the forwarding device has multiple forwarding instances), the 274 metric of each installed route, a route preference, and an 275 identifier indicating the installing process. 277 o The ability to monitor the available routes installed in the RIB 278 of each forwarding device, including near real time notification 279 of route installation and removal. This information must include 280 the destination prefix (NLRI), a table identifier (if the 281 forwarding device has multiple forwarding instances), the metric 282 of the installed route, and an identifier indicating the 283 installing process. 285 o The ability to install destination based routes in the local RIB 286 of each forwarding device. This must include the ability to 287 supply the destination prefix (NLRI), a table identifier (if the 288 forwarding device has multiple forwarding instances), a route 289 preference, a route metric, a next hop, an outbound interface, and 290 a route process identifier. 292 o The ability to read the tables of other local protocol processes 293 running on the device. This reading action should be supported 294 through an import/export interface which can present the 295 information in a consistent manner across all protocol 296 implementations, rather than using a protocol specific model for 297 each type of available process. 299 o The ability to inject information directly into the local tables 300 of other protocol processes running on the forwarding device. 301 This injection should be supported through an import/export 302 interface which can inject routing information in a consistent 303 manner across all protocol implementations, rather than using a 304 protocol specific model for each type of available process. 306 o The ability to interact with various policies configured on the 307 forwarding devices, in order to inform the policies implemented by 308 the dynamic routing processes. This interaction should be through 309 existing configuration mechanisms, such as NETCONF, and should be 310 recorded in the configuration of the local device so operators are 311 aware of the full policy implemented in the network from the 312 running configuration. 314 o The ability to interact with traffic flow and other network 315 traffic level measurement protocols and systems, in order to 316 determine path performance, top talkers, and other information 317 required to make an informed path decision based on locally 318 configured policy. 320 5. Temporary Overlays between Data Centers 322 Data Centers within one organization may operate as one single entity 323 even though they may be geographically distributed. Applications are 324 load balanced within Data Centers and between data centers to take 325 advantage of cost economics in power, storage, and server 326 availability for compute resources. Applications are also transfer 327 to alternate data centers in case of failures within a data center. 328 To reduce time during failure, Data Centers often replicate user 329 storage between two or more data centers. During the transfer of 330 stored information prior to a Data Center to Data Center move, the 331 Data Center controllers need to dynamically acquire a large amount of 332 inter-data center bandwidth through an overlay network, often during 333 off hours. 335 I2RS could provide the connection between the overlay network 336 configuration, local policies, and the control plane to dynamically 337 bring a large bandwidth inter-data center overlay or channel into 338 use, and then to remove it from use when the data transfer is 339 completed. 341 Similarly, during a fail-over, a control process within data centers 342 interacts with a group host process and the network to seamless move 343 the processing to another data center. During the fail-over case, 344 additional process state may need to be moved as well to restart the 345 system. The difference between these data-to-data center moves is 346 immediate and urgent need to move systems. If an application (such 347 as medical or banking services) pays to have this type of fail-over, 348 it is likely the service will pay for preemption on network 349 bandwidth. I2RS can allow the Data Center network and the Network 350 connecting the data center to preempt other best-effort traffic to 351 send this priority data flow. After the high priority data flow has 352 finished, networks can return to their previous condition. 354 Summary of IRS Capabilities and Interactions: 356 o The ability to read the local RIB of each forwarding device, 357 including the destination prefix (NLRI), a table identifier (if 358 the forwarding device has multiple forwarding instances), the 359 metric of each installed route, a route preference, and an 360 identifier indicating the installing process. 362 o The ability to monitor the available routes installed in the RIB 363 of each forwarding device, including near real time notification 364 of route installation and removal. This information must include 365 the destination prefix (NLRI), a table identifier (if the 366 forwarding device has multiple forwarding instances), the metric 367 of the installed route, and an identifier indicating the 368 installing process. 370 o The ability to install destination based routes in the local RIB 371 of each forwarding device. This must include the ability to 372 supply the destination prefix (NLRI), a table identifier (if the 373 forwarding device has multiple forwarding instances), a route 374 preference, a route metric, a next hop, an outbound interface, and 375 a route process identifier. 377 o The ability to interact with various policies configured on the 378 forwarding devices, in order to inform the policies implemented by 379 the dynamic routing processes. This interaction should be through 380 existing configuration mechanisms, such as NETCONF, and should be 381 recorded in the configuration of the local device so operators are 382 aware of the full policy implemented in the network from the 383 running configuration. 385 o The ability to interact with policies and configurations on the 386 forwarding devices using time based processing, either through 387 timed auto-rollback or some other mechanism. This interaction 388 should be through existing configuration mechanisms, such as 389 NETCONF, and should be recorded in the configuration of the local 390 device so operators are aware of the full policy implemented in 391 the network from the running configuration. 393 o The ability to interact with traffic flow and other network 394 traffic level measurement protocols and systems, in order to 395 determine path performance, top talkers, and other information 396 required to make an informed path decision based on locally 397 configured policy. 399 6. References 401 6.1. Normative References 403 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 404 Requirement Levels", BCP 14, RFC 2119, March 1997. 406 6.2. Informative References 408 [I-D.lapukhov-bgp-routing-large-dc] 409 Lapukhov, P., Premji, A., and J. Mitchell, "Use of BGP for 410 routing in large-scale data centers", draft-lapukhov-bgp- 411 routing-large-dc-06 (work in progress), August 2013. 413 [I-D.ward-i2rs-framework] 414 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 415 Routing System Framework", draft-ward-i2rs-framework-00 416 (work in progress), February 2013. 418 Authors' Addresses 420 Russ White 421 IETF 423 Email: russw@riw.us 424 Susan Hares 425 ADARA 427 Email: shares@ndzh.com 429 Alvaro Retana 430 Cisco Systems, Inc. 431 7025 Kit Creek Road 432 Research Triangle Park, NC 27617 433 USA 435 Email: aretana@cisco.com