idnits 2.17.1 draft-retana-network-complexity-framework-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 : ---------------------------------------------------------------------------- ** 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.) == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (March 14, 2013) is 4060 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'R1' is mentioned on line 157, but not defined == Missing Reference: 'R2' is mentioned on line 157, but not defined == Missing Reference: 'R4' is mentioned on line 157, but not defined == Missing Reference: 'R6' is mentioned on line 157, but not defined Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Retana 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track R. White 5 Expires: September 15, 2013 Verisign 6 March 14, 2013 8 A Framework for Measuring Network Complexity 9 draft-retana-network-complexity-framework-00.txt 11 Abstract 13 Network architecture revolves around the concept of fitting the 14 design of a network to its purpose; of asking the question, "what 15 network will best fit these needs?" A part of fitting network design 16 to requirements is the problem of complexity, an idea often measured 17 by "seat of pants" methods. When would adding a particular protocol, 18 policy, or configuration be "too complex?" This document suggests a 19 series of continuums along which network complexity might be 20 measured. No suggestions are made in measuring complexity for each 21 of these continuums are provided; this is left for future documents. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 15, 2013. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 59 3. Control Plane State verses Optimal Forwarding Paths (Stretch) 3 60 4. Configuration State verses Failure Domain Separation . . . . 4 61 5. Policy Centralization verses Optimal Policy Application . . . 6 62 6. Configuration State verses Per Hop Forwarding Optimization . 7 63 7. Reactivity verses Stability . . . . . . . . . . . . . . . . . 7 64 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 10. Normative References . . . . . . . . . . . . . . . . . . . . 9 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 69 1. Introduction 71 Network complexity is a systemic, rather than component level, 72 problem; complexity must be measured in terms of the multiple moving 73 parts of a system, and complexity may be more than the complexity of 74 the individual pieces, examined individually, might suggest. There 75 are two basic ways in which systemic level problems might be 76 addressed: interfaces and continuums. In addressing a systemic 77 problem through interfaces, we seek to treat each piece of the system 78 as a "black box," and develop a complete understanding of the 79 interfaces between these black boxes. In address a systemic problem 80 as a continuum, we seek to understand the impact of a single change 81 or element to the entire system as a set of tradeoffs. While network 82 complexity can profitably be approached from either of these 83 perspectives, the authors of this document have chosen to approach 84 the systemic impacts of network complexity from the perspective of 85 continuums of tradeoffs. In theory, modifying the network to resolve 86 one particular problem (or class of problems) will add complexity 87 which results in the increased liklihood (or appearance) of another 88 class of problems. Discovering these continuums of tradeoffs, and 89 then determining how to measure each one, become the key steps in 90 understanding and measuring systemic complexity in this view. 92 This document proposes five such continuums; more may be possible. 93 Others may be added into this document in future revisions, or 94 documented in other drafts, as circumstances dictate. 96 o Control Plane State verses Optimal Forwarding Paths (or it's 97 opposite measure, stretch) 99 o Configuration State verses Failure Domain Separation 101 o Policy Centralization verses Optimal Policy Application 103 o Configuration State verses Per Hop Forwarding Optimization 105 o Reactivity verses Stability 107 Each of these continuums is described in a separate section of this 108 draft. 110 2. Requirements notation 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" in this 114 document are to be interpreted as in [RFC2119]. 116 3. Control Plane State verses Optimal Forwarding Paths (Stretch) 118 Control plane state is the aggregate amount of information carried by 119 the control plane through the network in order to produce the 120 forwarding table at each device. Each additional piece of 121 information added to the control plane --such as more specific 122 reachability information, policy information, additional control 123 planes for virtualization and tunneling, or more precise topology 124 information-- adds to the complexity of the control plane. This 125 added complexity, in turn, adds to the burden of monitoring, 126 understanding, troubleshooting, and managing the network. Removing 127 control plane state, however, is not always a net positive gain for 128 the network as a system; removing control plane state almost always 129 results in decreased optimality in the forwarding and handing of 130 packets travelling through the network. This decreased optimality 131 can be termed stretch, which is defined as the difference between the 132 absolute shortest (or best) path traffic could take through the 133 network and the path the traffic actually takes through the network. 134 Stretch is expressed as the difference between the optimal and actual 135 path. The figure below provides and example of this tradeoff. 137 R1-------+ 138 | | 139 R2 R3 140 | | 141 R4-------R5 142 | 143 R6 145 Assume each link is of equal cost in this figure, and: 147 o R4 is advertising 192.0.2.1/32 as a reachable destination not 148 shown on the diagram 150 o R5 is advertising 192.0.2.2/32 as a reachable destination not 151 shown on the diagram 153 o R6 is advertising 192.0.2.3/32 as a reachable destination not 154 shown on the diagram 156 For R1, the shortest path to 192.0.2.3/32, advertised by R6, is along 157 the path [R1,R2,R4,R6]. Assume, however, the network administrator 158 decides to aggregate reachability information at R2 and R3, 159 advertising 192.0.2.0/24 towards R1 from both of these points. This 160 reduces the overall complexity of the control plane by reducing the 161 amount of information carried past these two routers (at R1 only in 162 this case). Aggregating reachability information at R2 and R3, 163 however, has the impact of making both routes towards 192.168.2.3/32 164 appear as equal cost paths to R1; there is no particular reason R1 165 should choose the shortest path through R2 over the longer path 166 through R3. This, in effect, increases the stretch of the network. 167 The shortest path from R1 to R6 is 3 hops, a path that will always be 168 chosen before aggregation is configured. Assuming half of the 169 traffic will be forwarded along the path through R2 (3 hops), and 170 half through R3 (4 hops), the network is stretched by ((3+4)/2) - 3), 171 or .5, a "half a hop." 173 Traffic engineering through various tunneling mechanisms is, at a 174 broad level, adding control plane state to provide more optimal 175 forwarding (or network utlization). Optimizing network utilization 176 may require detuning stretch (intentionally increasing stretch) to 177 increase overall network utilization and efficiency; this is simply 178 an alternate instance of control plane state (and hence complexity) 179 weighed against optimal forwarding through the network. 181 4. Configuration State verses Failure Domain Separation 182 A failure domain, within the context of a network control plane, can 183 be defined as the set of devices impacted by a change in the network 184 topology or configuration. A network with larger failure domains is 185 more prone to cascading failures, so smaller failure domains are 186 normally preferred over larger ones. The primary manes used to limit 187 the size of a failure domain within a network's control plane is 188 information hiding; the two primary types of information hidden in a 189 network control plane are reachability information and topology 190 information. An example of aggregating reachability information is 191 summarizing the routes 192.0.2.1/32, 192.0.2.2/32, and 192.0.2.3/32 192 into the single route 192.0.2.0/24, along with the aggregation of the 193 metric information associated with each of the component routes. 194 Note that aggregation is a "natural" part of IP networks, starting 195 with the aggregation of individual hosts into a subnet at the network 196 edge. An example of topology aggregation is the summarization of 197 routes at a link state flooding domain boundary, or the complete 198 failure to advertise topology information in a distance-vector 199 protocol. 201 While limiting the size of failure domains appears to be an absolute 202 good in terms of network complexity, there is a definite tradeoff in 203 configuration complexity. The more failure domain edges created in a 204 network, the more complex configuration will become. This is 205 particularly true is redistribution of routing information between 206 multiple control plane processes is used to create failure domain 207 boundaries; moving between different types of control planes causes a 208 loss of the consistent metrics most control planes rely on to build 209 loop free paths. Redistribution, in particular, opens the door to 210 very destructive positive feedback looks within the control plane. 211 Examples of control plane complexity caused by the creation of 212 failure domain boundaries include route filters, routing aggregation 213 configuration, and metric modifications to engineer traffic across 214 failure domain boundaries. 216 Returning to the network described in the previous section, 217 aggregating routing information at R2 and R3 will divide the network 218 into two failure domains: (R1,R2,R3), and (R2,R3,R4,R5). A failure 219 at R5 should have no impact on the forwarding information at R1. A 220 false failure domain separation occurs, however, when the metric of 221 the aggregate route advertised by R2 and R3 is dependent on one of 222 the routes within the aggregate. For instance, if the metric of the 223 192.0.2.0/24 aggregate is taken from the metric of the component 224 192.0.2.1/32, then a failure of this one component will cause changes 225 in the forwarding table at R1 --in this case, the control plane has 226 not truly been separated into two distinct failure domains. The 227 added complexity in the illustration network would be the management 228 of the configuration required to aggregate the contorl plane 229 information, and the management of the metrics to ensure the control 230 plane is truly separated into two distinct failure domains. 232 Replacing aggregation with redistribution adds the complexity of 233 managing the feedback of routing information redistributed between 234 the failure domains. For instance, if R1, R2, and R3 were configured 235 to run one routing protocol, while R2, R3, R4, R5, and R6 were 236 configured to run another protocol, R2 and R3 could be configured to 237 redistribute reachability information between these two control 238 planes. This can split the control plane into multiple failure 239 domains (depending on how, specifically, redistribution is 240 configured), but at the cost of creating and managing the 241 redistribution configuration. Futher, R3 must be configured to block 242 routing information redistributed at R2 towards R1 from being 243 redistributined (again) towards R4 and R5. 245 5. Policy Centralization verses Optimal Policy Application 247 Another broad area where control plane complexity interacts with 248 optimal network utilization is Quality of Service (QoS). Two 249 specific actions are required to optimize the flow of traffic through 250 a network: marking and Per Hop Behaviors (PHBs). Rather than 251 examining each packet at each forwarding device in a network, packets 252 are often marked, or classified, in some way (typically through Type 253 of Service bits) so they can be handled consistently at all 254 forwarding devices. Packet marking policies must be configured on 255 specific forwarding devices throughout the network. Distributing 256 marking closer to the edge of the network necessarily means 257 configuring and managing more devices, but produces optimal 258 forwarding at a larger number of network devices. Moving marking 259 towards the network core means packets are marked for proper handling 260 across a smaller number of devices. In the same way, each device 261 through which a packet passes with the correct PHBs configured 262 represents an increase in the consistency in packet handling through 263 the network as well as an increase in the number of devices which 264 must be configured and managed for the correct PHBs. The network 265 below is used for an illustration of this concept. 267 +----R1----+ 268 | | 269 +--R2--+ +--R3--+ 270 | | | | 271 R4 R5 R6 R7 273 In this network, marking and PHB configuration may be configured on 274 any device, R1 through R7. Assume marking is configured at the 275 network edge; in this case, four devices, (R4,R5,R6,R7), must be 276 configured, including ongoing configuration management, to mark 277 packets. Moving packet marking to R2 and R3 will halve the number of 278 devices on which packet marking configuration must be managed, but at 279 the cost of consistent packet handling at the inbound interfaces of 280 R2 and R3 themselves. Thus reducing the number of devices which must 281 have managed configurations for packet marking will reduce optimal 282 packet flow through the network. Assuming packet marking is actually 283 configured along the edge of this network, configuring PHBs on 284 different devices has this same tradeoff of managed configuration 285 verses optimal traffic flow. If the correct PHBs are configured on 286 R1, R2, and R3, then packets passing through the network will be 287 handled correctly at each hop. The cost involved will be the 288 management of PHB configuration on three devices. Configuring a 289 single device for the correct PHBs (R1, for instance), will decrease 290 the amount of configuration management required, at the cost of less 291 than optimal packet handling along the entire path. 293 6. Configuration State verses Per Hop Forwarding Optimization 295 The number of PHBs configured along a forwarding path exhibits the 296 same complexity verses optimality tradeoff described in the section 297 above. The more types of service (or queues) traffic is divided 298 into, the more optimally traffic will be managed as it passes through 299 the network. At the same time, each class of service must be 300 managed, both in terms of configuration and in its interaction with 301 other classes of service configured in the network. 303 7. Reactivity verses Stability 305 The speed at which the network's control plane can react to a change 306 in configuration or topology is an area of widespread study. Control 307 plane convergence can be broken down into four essential parts: 309 o Detecting the change 310 o Propagating information about the change 312 o Determining the best path(s) through the network after the change 314 o Changing the forwarding path at each network element along the 315 modified paths 317 Each of these areas can be addressed in an effort to improve network 318 convergence speeds; some of these improvements come at the cost of 319 increased complexity. 321 Changes in network topology can be detected much more quickly through 322 faster echo (or hello) mechanisms, lower layer physical detection, 323 and other methods. Each of these mechanisms, however, can only be 324 used at the cost of evaluating and managing false positives and high 325 rates of topology change. If the state of a link change can be 326 detected in 10ms, for instance, the link could theoretically change 327 state 50 times in a second --it would be impossible to tune a network 328 control plane to react to topology changes at this rate. Injecting 329 topology change information into the control plane at this rate can 330 destabalize the control plane, and hence the network itself. To 331 counter this, most fast down detection techniques include some form 332 of dampening mechanism; configuring and managing these dampening 333 mechanisms represents an added complexity that must be configured and 334 managed. 336 Changes in network topology must also be propagated throughout the 337 network, so each device along the path can compute new forwarding 338 tables. In high speed network environments, propagation of routing 339 information changes can take place in tens of milliseconds, opening 340 the possibility of multiple changes being propagated per second. 341 Injecting information at this rate into the contral plane creates the 342 risk of overloading the processes and devices participating in the 343 control plane, as well as creating destructive positive feedback 344 loops in the network. To avoid these consequences, most control 345 plane protocols regulate the speed at which information about network 346 changes can be transmitted by any individual device. A recent 347 innovation in this area is using exponential backoff techniques to 348 manage the rate at which information is injected into the control 349 plane; the first change is transmitted quickly, while subsequent 350 changes are transmitted more slowly. These techniques all control 351 the destabalilzing effects of rapid information flows through the 352 control plane through the added complexity of configuring and 353 managing the rate at which the control plane can propagate 354 information about network changes. 356 All control planes require some form of algorithmic calculation to 357 find the best path through the network to any given destination. 359 These algorithms are often lightweight, but they still require some 360 amount of memory and computational power to execute. Rapid changes 361 in the network can overwhelm the devices on which these algorithms 362 run, particularly if changes are presented more quickly than the 363 algorithm can run. Once the devices running these algorithms become 364 processor or memory bound, it could experience a computational 365 failure altogether, causing a more general network outage. To 366 prevent computational overloading, control plane protocols are 367 designed with timers limiting how often they can compute the best 368 path through a network; often these timers are exponential in nature, 369 allowing the first computation to run quickly, while delaying 370 subsequent computations. Configuring and managing these timers is 371 another source of complexity within the network. 373 Another option to improve the speed at which the control plane reacts 374 to changes in the network is to precompute alternate paths at each 375 device, and possibly preinstall forwarding information into local 376 forwarding tables. Additional state is often needed to precompute 377 alternate paths, and additional algorithms and techniques are often 378 configured and deployed. This additional state, and these additional 379 algorithms, add some amount of complexity to the configuration and 380 management of the network. In some situations (for some topologies), 381 a tunnel is required to pass traffic around a network failure or 382 topology change. These tunnels, while not manually configured, 383 represent additional complexity at the forwarding and control planes. 385 8. Conclusion 387 This document describes various areas of network and design where 388 complexity is traded off against some optimization in the operation 389 of the network. This is (by it's nature) not an exhaustive list, but 390 it can serve to guide the measurement of network complexity and the 391 search for other areas where these tradeoffs exist. 393 9. Security Considerations 395 None. 397 10. Normative References 399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels", BCP 14, RFC 2119, March 1997. 402 Authors' Addresses 404 Alvaro Retana 405 Cisco Systems 406 2610 Wycliff Road 407 Raleigh, NC 27607 408 USA 410 Email: aretana@cisco.com 412 Russ White 413 Verisign 414 12061 Bluemont Way 415 Reston, VA 20190 416 USA 418 Email: russw@riw.us