Network Working Group A. Retana Internet-Draft Cisco Systems, Inc. Intended status: Informational R. White Expires: March 03, 2014 IETF August 30, 2013 Network Design Complexity Measurement and Tradeoffs draft-irtf-ncrg-network-design-complexity-00 Abstract Network architecture revolves around the concept of fitting the design of a network to its purpose; of asking the question, "what network will best fit these needs?" A part of fitting network design to requirements is the problem of complexity, an idea often informally measured using intuition and subjective experience. When would adding a particular protocol, policy, or configuration be "too complex?" This document suggests a series of continuums along which network complexity might be measured. No suggestions are made on how to measure complexity for each of these continuums; this is left for future documents. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 03, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Retana & White Expires March 03, 2014 [Page 1] Internet-Draft Network Design Complexity August 2013 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Control Plane State versus Optimal Forwarding Paths (Stretch) 3 3. Configuration State versus Failure Domain Separation . . . . 4 4. Policy Centralization versus Optimal Policy Application . . . 6 5. Configuration State versus Per Hop Forwarding Optimization . 7 6. Reactivity versus Stability . . . . . . . . . . . . . . . . . 7 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Network complexity is a systemic, rather than component level, problem; complexity must be measured in terms of the multiple moving parts of a system, and complexity may be more than what the complexity of the individual pieces, examined individually, might suggest. There are two basic ways in which systemic level problems might be addressed: interfaces and continuums. In addressing a systemic problem through interfaces, we seek to treat each piece of the system as a "black box," and develop a complete understanding of the interfaces between these black boxes. In addressing a systemic problem as a continuum, we seek to understand the impact of a single change or element to the entire system as a set of tradeoffs. While network complexity can profitably be approached from either of these perspectives, in this document we have chosen to approach the systemic impacts of network complexity from the perspective of continuums of tradeoffs. In theory, modifying the network to resolve one particular problem (or class of problems) will add complexity which results in the increased likelihood (or appearance) of another class of problems. Discovering these continuums of tradeoffs, and then determining how to measure each one, become the key steps in understanding and measuring systemic complexity in this view. This document proposes five such continuums; more may be possible. Retana & White Expires March 03, 2014 [Page 2] Internet-Draft Network Design Complexity August 2013 o Control Plane State versus Optimal Forwarding Paths (or its opposite measure, stretch) o Configuration State versus Failure Domain Separation o Policy Centralization versus Optimal Policy Application o Configuration State versus Per Hop Forwarding Optimization o Reactivity versus Stability Each of these continuums is described in a separate section of this document. 2. Control Plane State versus Optimal Forwarding Paths (Stretch) Control plane state is the aggregate amount of information carried by the control plane through the network in order to produce the forwarding table at each device. Each additional piece of information added to the control plane --such as more specific reachability information, policy information, additional control planes for virtualization and tunneling, or more precise topology information-- adds to the complexity of the control plane. This added complexity, in turn, adds to the burden of monitoring, understanding, troubleshooting, and managing the network. Removing control plane state, however, is not always a net positive gain for the network as a system; removing control plane state almost always results in decreased optimality in the forwarding and handing of packets travelling through the network. This decreased optimality can be termed stretch, which is defined as the difference between the absolute shortest (or best) path traffic could take through the network and the path the traffic actually takes. Stretch is expressed as the difference between the optimal and actual path. The figure below provides and example of this tradeoff. R1-------+ | | R2 R3 | | R4-------R5 | R6 Assume each link is of equal cost in this figure, and: Retana & White Expires March 03, 2014 [Page 3] Internet-Draft Network Design Complexity August 2013 o R4 is advertising 192.0.2.1/32 as a reachable destination not shown on the diagram o R5 is advertising 192.0.2.2/32 as a reachable destination not shown on the diagram o R6 is advertising 192.0.2.3/32 as a reachable destination not shown on the diagram For R1, the shortest path to 192.0.2.3/32, advertised by R6, is along the path [R1,R2,R4,R6]. Assume, however, the network administrator decides to aggregate reachability information at R2 and R3, advertising 192.0.2.0/24 towards R1 from both of these points. This reduces the overall complexity of the control plane by reducing the amount of information carried past these two routers (at R1 only in this case). Aggregating reachability information at R2 and R3, however, may have the impact of making both routes towards 192.0.2.3/32 appear as equal cost paths to R1; there is no particular reason R1 should choose the shortest path through R2 over the longer path through R3. This, in effect, increases the stretch of the network. The shortest path from R1 to R6 is 3 hops, a path that will always be chosen before aggregation is configured. Assuming half of the traffic will be forwarded along the path through R2 (3 hops), and half through R3 (4 hops), the network is stretched by ((3+4)/2) - 3), or .5, a "half a hop." Traffic engineering through various tunneling mechanisms is, at a broad level, adding control plane state to provide more optimal forwarding (or network utlization). Optimizing network utilization may require detuning stretch (intentionally increasing stretch) to increase overall network utilization and efficiency; this is simply an alternate instance of control plane state (and hence complexity) weighed against optimal forwarding through the network. 3. Configuration State versus Failure Domain Separation A failure domain, within the context of a network control plane, can be defined as the set of devices impacted by a change in the network topology or configuration. A network with larger failure domains is more prone to cascading failures, so smaller failure domains are normally preferred over larger ones. The primary means used to limit the size of a failure domain within a network's control plane is information hiding; the two primary types of information hidden in a network control plane are reachability Retana & White Expires March 03, 2014 [Page 4] Internet-Draft Network Design Complexity August 2013 information and topology information. An example of aggregating reachability information is summarizing the routes 192.0.2.1/32, 192.0.2.2/32, and 192.0.2.3/32 into the single route 192.0.2.0/24, along with the aggregation of the metric information associated with each of the component routes. Note that aggregation is a "natural" part of IP networks, starting with the aggregation of individual hosts into a subnet at the network edge. An example of topology aggregation is the summarization of routes at a link state flooding domain boundary, or the lack of topology information in a distance- vector protocol. While limiting the size of failure domains appears to be an absolute good in terms of network complexity, there is a definite tradeoff in configuration complexity. The more failure domain edges created in a network, the more complex configuration will become. This is particularly true if redistribution of routing information between multiple control plane processes is used to create failure domain boundaries; moving between different types of control planes causes a loss of the consistent metrics most control planes rely on to build loop free paths. Redistribution, in particular, opens the door to very destructive positive feedback loops within the control plane. Examples of control plane complexity caused by the creation of failure domain boundaries include route filters, routing aggregation configuration, and metric modifications to engineer traffic across failure domain boundaries. Returning to the network described in the previous section, aggregating routing information at R2 and R3 will divide the network into two failure domains: (R1,R2,R3), and (R2,R3,R4,R5). A failure at R5 should have no impact on the forwarding information at R1. A false failure domain separation occurs, however, when the metric of the aggregate route advertised by R2 and R3 is dependent on one of the routes within the aggregate. For instance, if the metric of the 192.0.2.0/24 aggregate is taken from the metric of the component 192.0.2.1/32, then a failure of this one component will cause changes in the forwarding table at R1 --in this case, the control plane has not truly been separated into two distinct failure domains. The added complexity in the illustration network would be the management of the configuration required to aggregate the contorl plane information, and the management of the metrics to ensure the control plane is truly separated into two distinct failure domains. Replacing aggregation with redistribution adds the complexity of managing the feedback of routing information redistributed between the failure domains. For instance, if R1, R2, and R3 were configured to run one routing protocol, while R2, R3, R4, R5, and R6 were configured to run another protocol, R2 and R3 could be configured to Retana & White Expires March 03, 2014 [Page 5] Internet-Draft Network Design Complexity August 2013 redistribute reachability information between these two control planes. This can split the control plane into multiple failure domains (depending on how, specifically, redistribution is configured), but at the cost of creating and managing the redistribution configuration. Futher, R3 must be configured to block routing information redistributed at R2 towards R1 from being redistributined (again) towards R4 and R5. 4. Policy Centralization versus Optimal Policy Application Another broad area where control plane complexity interacts with optimal network utilization is Quality of Service (QoS). Two specific actions are required to optimize the flow of traffic through a network: marking and Per Hop Behaviors (PHBs). Rather than examining each packet at each forwarding device in a network, packets are often marked, or classified, in some way (typically through Type of Service bits) so they can be handled consistently at all forwarding devices. Packet marking policies must be configured on specific forwarding devices throughout the network. Distributing marking closer to the edge of the network necessarily means configuring and managing more devices, but produces optimal forwarding at a larger number of network devices. Moving marking towards the network core means packets are marked for proper handling across a smaller number of devices. In the same way, each device through which a packet passes with the correct PHBs configured represents an increase in the consistency in packet handling through the network as well as an increase in the number of devices which must be configured and managed for the correct PHBs. The network below is used for an illustration of this concept. +----R1----+ | | +--R2--+ +--R3--+ | | | | R4 R5 R6 R7 In this network, marking and PHB configuration may be configured on any device, R1 through R7. Assume marking is configured at the network edge; in this case, four devices, (R4,R5,R6,R7), must be configured, including ongoing configuration management, to mark packets. Moving packet marking to R2 and R3 will halve the number of devices on which packet marking configuration must be managed, but at the cost of inconsistent packet handling at the inbound interfaces of R2 and R3 themselves. Retana & White Expires March 03, 2014 [Page 6] Internet-Draft Network Design Complexity August 2013 Thus reducing the number of devices which must have managed configurations for packet marking will reduce optimal packet flow through the network. Assuming packet marking is actually configured along the edge of this network, configuring PHBs on different devices has this same tradeoff of managed configuration versus optimal traffic flow. If the correct PHBs are configured on R1, R2, and R3, then packets passing through the network will be handled correctly at each hop. The cost involved will be the management of PHB configuration on three devices. Configuring a single device for the correct PHBs (R1, for instance), will decrease the amount of configuration management required, at the cost of less than optimal packet handling along the entire path. 5. Configuration State versus Per Hop Forwarding Optimization The number of PHBs configured along a forwarding path exhibits the same complexity versus optimality tradeoff described in the section above. The more types of service (or queues) traffic is divided into, the more optimally traffic will be managed as it passes through the network. At the same time, each class of service must be managed, both in terms of configuration and in its interaction with other classes of service configured in the network. 6. Reactivity versus Stability The speed at which the network's control plane can react to a change in configuration or topology is an area of widespread study. Control plane convergence can be broken down into four essential parts: o Detecting the change o Propagating information about the change o Determining the best path(s) through the network after the change o Changing the forwarding path at each network element along the modified paths Each of these areas can be addressed in an effort to improve network convergence speeds; some of these improvements come at the cost of increased complexity. Changes in network topology can be detected much more quickly through faster echo (or hello) mechanisms, lower layer physical detection, and other methods. Each of these mechanisms, however, can only be used at the cost of evaluating and managing false positives and high rates of topology change. Retana & White Expires March 03, 2014 [Page 7] Internet-Draft Network Design Complexity August 2013 If the state of a link change can be detected in 10ms, for instance, the link could theoretically change state 50 times in a second --it would be impossible to tune a network control plane to react to topology changes at this rate. Injecting topology change information into the control plane at this rate can destabalize the control plane, and hence the network itself. To counter this, most fast down detection techniques include some form of dampening mechanism; configuring and managing these dampening mechanisms represents an added complexity that must be configured and managed. Changes in network topology must also be propagated throughout the network, so each device along the path can compute new forwarding tables. In high speed network environments, propagation of routing information changes can take place in tens of milliseconds, opening the possibility of multiple changes being propagated per second. Injecting information at this rate into the contral plane creates the risk of overloading the processes and devices participating in the control plane, as well as creating destructive positive feedback loops in the network. To avoid these consequences, most control plane protocols regulate the speed at which information about network changes can be transmitted by any individual device. A recent innovation in this area is using exponential backoff techniques to manage the rate at which information is advertised into the control plane; the first change is transmitted quickly, while subsequent changes are transmitted more slowly. These techniques all control the destabalilzing effects of rapid information flows through the control plane through the added complexity of configuring and managing the rate at which the control plane can propagate information about network changes. All control planes require some form of algorithmic calculation to find the best path through the network to any given destination. These algorithms are often lightweight, but they still require some amount of memory and computational power to execute. Rapid changes in the network can overwhelm the devices on which these algorithms run, particularly if changes are presented more quickly than the algorithm can run. Once the devices running these algorithms become processor or memory bound, it could experience a computational failure altogether, causing a more general network outage. To prevent computational overloading, control plane protocols are designed with timers limiting how often they can compute the best path through a network; often these timers are exponential in nature, allowing the first computation to run quickly, while delaying subsequent computations. Configuring and managing these timers is another source of complexity within the network. Another option to improve the speed at which the control plane reacts to changes in the network is to precompute alternate paths at each Retana & White Expires March 03, 2014 [Page 8] Internet-Draft Network Design Complexity August 2013 device, and possibly preinstall forwarding information into local forwarding tables. Additional state is often needed to precompute alternate paths, and additional algorithms and techniques are often configured and deployed. This additional state, and these additional algorithms, add some amount of complexity to the configuration and management of the network. In some situations (for some topologies), a tunnel is required to pass traffic around a network failure or topology change. These tunnels, while not manually configured, represent additional complexity at the forwarding and control planes. 7. Conclusion This document describes various areas of network and design where complexity is traded off against some optimization in the operation of the network. This is (by it's nature) not an exhaustive list, but it can serve to guide the measurement of network complexity and the search for other areas where these tradeoffs exist. 8. Security Considerations None. 9. Acknowledgements The authors would like to thank Michael Behringer and Dave Meyer for their comments. 10. References Authors' Addresses Alvaro Retana Cisco Systems, Inc. 7025 Kit Creek Rd. Research Triangle Park, NC 27709 USA Email: aretana@cisco.com Russ White IETF Email: russw@riw.us Retana & White Expires March 03, 2014 [Page 9]