From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7980.txt | 1347 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1347 insertions(+) create mode 100644 doc/rfc/rfc7980.txt (limited to 'doc/rfc/rfc7980.txt') diff --git a/doc/rfc/rfc7980.txt b/doc/rfc/rfc7980.txt new file mode 100644 index 0000000..841c9ac --- /dev/null +++ b/doc/rfc/rfc7980.txt @@ -0,0 +1,1347 @@ + + + + + + +Independent Submission M. Behringer +Request for Comments: 7980 A. Retana +Category: Informational Cisco Systems +ISSN: 2070-1721 R. White + Ericsson + G. Huston + APNIC + October 2016 + + + A Framework for Defining Network Complexity + +Abstract + + Complexity is a widely used parameter in network design, yet there is + no generally accepted definition of the term. Complexity metrics + exist in a wide range of research papers, but most of these address + only a particular aspect of a network, for example, the complexity of + a graph or software. While it may be impossible to define a metric + for overall network complexity, there is a desire to better + understand the complexity of a network as a whole, as deployed today + to provide Internet services. This document provides a framework to + guide research on the topic of network complexity as well as some + practical examples for trade-offs in networking. + + This document summarizes the work of the IRTF's Network Complexity + Research Group (NCRG) at the time of its closure. It does not + present final results, but a snapshot of an ongoing activity, as a + basis for future work. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This is a contribution to the RFC Series, independently of any other + RFC stream. The RFC Editor has chosen to publish this document at + its discretion and makes no statement about its value for + implementation or deployment. Documents approved for publication by + the RFC Editor are not a candidate for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7980. + + + + + + +Behringer, et al. Informational [Page 1] + +RFC 7980 Complexity Framework October 2016 + + +Copyright Notice + + Copyright (c) 2016 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 + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Behringer, et al. Informational [Page 2] + +RFC 7980 Complexity Framework October 2016 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. General Considerations . . . . . . . . . . . . . . . . . . . 5 + 2.1. The Behavior of a Complex Network . . . . . . . . . . . . 5 + 2.2. Complex versus Complicated . . . . . . . . . . . . . . . 5 + 2.3. Robust Yet Fragile . . . . . . . . . . . . . . . . . . . 6 + 2.4. The Complexity Cube . . . . . . . . . . . . . . . . . . . 6 + 2.5. Related Concepts . . . . . . . . . . . . . . . . . . . . 6 + 2.6. Technical Debt . . . . . . . . . . . . . . . . . . . . . 7 + 2.7. Layering Considerations . . . . . . . . . . . . . . . . . 8 + 3. Trade-Offs . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.1. Control-Plane State versus Optimal Forwarding Paths + (Stretch) . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.2. Configuration State versus Failure Domain Separation . . 10 + 3.3. Policy Centralization versus Optimal Policy Application . 12 + 3.4. Configuration State versus Per-Hop Forwarding + Optimization . . . . . . . . . . . . . . . . . . . . . . 13 + 3.5. Reactivity versus Stability . . . . . . . . . . . . . . . 13 + 4. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 5. Elements of Complexity . . . . . . . . . . . . . . . . . . . 16 + 5.1. The Physical Network (Hardware) . . . . . . . . . . . . . 16 + 5.2. Algorithms . . . . . . . . . . . . . . . . . . . . . . . 17 + 5.3. State in the Network . . . . . . . . . . . . . . . . . . 17 + 5.4. Churn . . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 5.5. Knowledge . . . . . . . . . . . . . . . . . . . . . . . . 17 + 6. Location of Complexity . . . . . . . . . . . . . . . . . . . 17 + 6.1. Topological Location . . . . . . . . . . . . . . . . . . 17 + 6.2. Logical Location . . . . . . . . . . . . . . . . . . . . 18 + 6.3. Layering Considerations . . . . . . . . . . . . . . . . . 18 + 7. Dependencies . . . . . . . . . . . . . . . . . . . . . . . . 18 + 7.1. Local Dependencies . . . . . . . . . . . . . . . . . . . 19 + 7.2. Network-Wide Dependencies . . . . . . . . . . . . . . . . 19 + 7.3. Network-External Dependencies . . . . . . . . . . . . . . 19 + 8. Management Interactions . . . . . . . . . . . . . . . . . . . 20 + 8.1. Configuration Complexity . . . . . . . . . . . . . . . . 20 + 8.2. Troubleshooting Complexity . . . . . . . . . . . . . . . 20 + 8.3. Monitoring Complexity . . . . . . . . . . . . . . . . . . 20 + 8.4. Complexity of System Integration . . . . . . . . . . . . 21 + 9. External Interactions . . . . . . . . . . . . . . . . . . . . 21 + 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 + 12. Informative References . . . . . . . . . . . . . . . . . . . 22 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 + + + + + + +Behringer, et al. Informational [Page 3] + +RFC 7980 Complexity Framework October 2016 + + +1. Introduction + + Network design can be described as the art of finding the simplest + solution to solve a given problem. Complexity is thus assumed in the + design process; engineers do not ask if there should be complexity, + but rather, how much complexity is required to solve the problem. + The question of how much complexity assumes there is some way to + characterize the amount of complexity present in a system. The + reality is, however, this is an area of research and experience + rather than a solved problem within the network engineering space. + Today's design decisions are made based on a rough estimation of the + network's complexity rather than a solid understanding. + + The document begins with general considerations, including some + foundational definitions and concepts. It then provides some + examples for trade-offs that network engineers regularly make when + designing a network. This section serves to demonstrate that there + is no single answer to complexity; rather, it is a managed trade-off + between many parameters. After this, this document provides a set of + parameters engineers should consider when attempting to either + measure complexity or build a framework around it. This list makes + no claim to be complete, but it serves as a guide of known existing + areas of investigation as well as a pointer to areas that still need + to be investigated. + + Two purposes are served here. The first is to guide researchers + working in the area of complexity in their work. The more + researchers are able to connect their work to the concerns of network + designers, the more useful their research will become. This document + may also guide research into areas not considered before. The second + is to help network engineers to build a better understanding of where + complexity might be "hiding" in their networks and to be more fully + aware of how complexity interacts with design and deployment. + + The goal of the IRTF Network Complexity Research Group (NCRG) [ncrg] + was to define a framework for network complexity research while + recognizing that it may be impossible to define metrics for overall + network complexity. This document summarizes the work of this group + at the time of its closure in 2014. It does not present final + results, but rather a snapshot of an ongoing activity, as a basis for + future work. + + Many references to existing research in the area of network + complexity are listed on the Network Complexity Wiki [wiki]. This + wiki also contains background information on previous meetings on the + subject, previous research, etc. + + + + + +Behringer, et al. Informational [Page 4] + +RFC 7980 Complexity Framework October 2016 + + +2. General Considerations + +2.1. The Behavior of a Complex Network + + While there is no generally accepted definition of network + complexity, there is some understanding of the behavior of a complex + network. It has some or all of the following properties: + + o Self-Organization: A network runs some protocols and processes + without external control; for example, a routing process, failover + mechanisms, etc. The interaction of those mechanisms can lead to + a complex behavior. + + o Unpredictability: In a complex network, the effect of a local + change on the behavior of the global network may be unpredictable. + + o Emergence: The behavior of the system as a whole is not reflected + in the behavior of any individual component of the system. + + o Non-linearity: An input into the network produces a non-linear + result. + + o Fragility: A small local input can break the entire system. + +2.2. Complex versus Complicated + + The two terms "complex" and "complicated" are often used + interchangeably, yet they describe different but overlapping + properties. The RG made the following statements about the two + terms, but they would need further refinement to be considered formal + definitions: + + o A "complicated" system is a deterministic system that can be + understood by an appropriate level of analysis. It is often an + externally applied attribute rather than an intrinsic property of + a system and is typically associated with systems that require + deep or significant levels of analysis. + + o A "complex" system, by comparison, is an intrinsic property of a + system and is typically associated with emergent behaviors such + that the behavior of the system is not fully described by the sum + of the behavior of each of the components of the system. Complex + systems are often associated with systems whose components exhibit + high levels of interaction and feedback. + + + + + + + +Behringer, et al. Informational [Page 5] + +RFC 7980 Complexity Framework October 2016 + + +2.3. Robust Yet Fragile + + Networks typically follow the "robust yet fragile" paradigm: they are + designed to be robust against a set of failures, yet they are very + vulnerable to other failures. Doyle [Doyle] explains the concept + with an example: the Internet is robust against single-component + failure but fragile to targeted attacks. The "robust yet fragile" + property also touches on the fact that all network designs are + necessarily making trade-offs between different design goals. The + simplest one is "Good, Fast, Cheap: Pick any two (you can't have all + three)", as articulated in "The Twelve Networking Truths" [RFC1925]. + In real network design, trade-offs between many aspects have to be + made, including, for example, issues of scope, time, and cost in the + network cycle of planning, design, implementation, and management of + a network platform. Section 3 gives some examples of trade-offs, and + parameters are discussed in Section 4. + +2.4. The Complexity Cube + + Complex tasks on a network can be done in different components of the + network. For example, routing can be controlled by central + algorithms and the result distributed (e.g., OpenFlow model); the + routing algorithm can also run completely distributed (e.g., routing + protocols such as OSPF or IS-IS), or a human operator could calculate + routing tables and statically configure routing. Behringer + [Behringer] defines these three axes of complexity as a "complexity + cube" with the respective axes being network elements, central + systems, and human operators. Any function can be implemented in any + of these three axes, and this choice likely has an impact on the + overall complexity of the system. + +2.5. Related Concepts + + When discussing network complexity, a large number of influencing + factors have to be taken into account to arrive at a full picture, + for example: + + o State in the Network: Contains the network elements, such as + routers, switches (with their OS, including protocols), lines, + central systems, etc. This also includes the number and + algorithmic complexity of the protocols on network devices. + + o Human Operators: Complexity manifests itself often by a network + that is not completely understood by human operators. Human error + is a primary source for catastrophic failures and therefore must + be taken into account. + + + + + +Behringer, et al. Informational [Page 6] + +RFC 7980 Complexity Framework October 2016 + + + o Classes/Templates: Rather than counting the number of lines in a + configuration or the number of hardware elements, more important + is the number of classes from which those can be derived. In + other words, it is probably less complex to have 1000 interfaces + that are identically configured than 5 that are configured + completely different. + + o Dependencies and Interactions: The number of dependencies between + elements, as well as the interactions between them, has influence + on the complexity of the network. + + o Total Cost of Ownership (TCO): TCO could be a good metric for + network complexity if the TCO calculation takes into account all + influencing factors, for example, training time for staff to be + able to maintain a network. + + o Benchmark Unit Cost (BUC): BUC is a related metric that indicates + the cost of operating a certain component. If calculated well, it + reflects at least parts of the complexity of this component. + Therefore, the way TCO or BUC is calculated can help to derive a + complexity metric. + + o Churn / Rate of Change: The change rate in a network itself can + contribute to complexity, especially if a number of components of + the overall network interact. + + Networks differ in terms of their intended purpose (such as is found + in differences between enterprise and public carriage network + platforms) and differences in their intended roles (such as is found + in the differences between so-called "access" networks and "core" + transit networks). The differences in terms of role and purpose can + often lead to differences in the tolerance for, and even the metrics + of, complexity within such different network scenarios. This is not + necessarily a space where a single methodology for measuring + complexity, and defining a single threshold value of acceptability of + complexity, is appropriate. + +2.6. Technical Debt + + Many changes in a network are made with a dependency on the existing + network. Often, a suboptimal decision is made because the optimal + decision is hard or impossible to realize at the time. Over time, + the number of suboptimal changes in themselves cause significant + complexity, which would not have been there had the optimal solution + been implemented. + + + + + + +Behringer, et al. Informational [Page 7] + +RFC 7980 Complexity Framework October 2016 + + + The term "technical debt" refers to the accumulated complexity of + suboptimal changes over time. As with financial debt, the idea is + that also technical debt must be repaid one day by cleaning up the + network or software. + +2.7. Layering Considerations + + In considering the larger space of applications, transport services, + network services, and media services, it is feasible to engineer + responses for certain types of desired applications responses in many + different ways and involving different layers of the so-called + network protocol stack. For example, Quality of Service (QoS) could + be engineered at any of these layers or even in a number of + combinations of different layers. + + Considerations of complexity arise when mutually incompatible + measures are used in combination (such as error detection and + retransmission at the media layer in conjunction with the use of TCP + transport protocol) or when assumptions used in one layer are + violated by another layer. This results in surprising outcomes that + may result in complex interactions, for example, oscillation, because + different layers use different timers for retransmission. These + issues have led to the perspective that increased layering frequently + increases complexity [RFC3439]. + + While this research work is focused on network complexity, the + interactions of the network with the end-to-end transport protocols, + application layer protocols, and media properties are relevant + considerations here. + +3. Trade-Offs + + Network complexity is a system-level, rather than component-level, + problem; overall system complexity may be more than the sum of the + complexity of the individual pieces. + + There are two basic ways in which system-level problems might be + addressed: interfaces and continuums. In addressing a system-level + 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 system-level + problem as a continuum, we seek to understand the impact of a single + change or element to the entire system as a set of trade-offs. + + While network complexity can profitably be approached from either of + these perspectives, in this document we have chosen to approach the + system-level impact of network complexity from the perspective of + continuums of trade-offs. In theory, modifying the network to + + + +Behringer, et al. Informational [Page 8] + +RFC 7980 Complexity Framework October 2016 + + + resolve one particular problem (or class of problems) will add + complexity that results in the increased likelihood (or appearance) + of another class of problems. Discovering these continuums of trade- + offs, and then determining how to measure each one, become the key + steps in understanding and measuring system-level complexity in this + view. + + The following sections describe five such continuums; more may be + possible. + + 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 + +3.1. 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 handling + of packets traveling 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 an example of this trade-off. + + + + + + + + + +Behringer, et al. Informational [Page 9] + +RFC 7980 Complexity Framework October 2016 + + + +---R1---+ + | | + (aggregate: 192.0.2/24) R2 R3 (aggregate: 192.0.2/24) + | | + R4-------R5 + | + (announce: 192.0.2.1/32) R6 + + Assume each link is of equal cost in this figure and that R6 is + advertising 192.0.2.1/32. + + For R1, the shortest path to 192.0.2.1/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.1/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 utilization). 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.2. 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. + + + + + +Behringer, et al. Informational [Page 10] + +RFC 7980 Complexity Framework October 2016 + + + 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 + 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 trade-off 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 derived 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 control-plane + information, and the management of the metrics to ensure the control + plane is truly separated into two distinct failure domains. + + + + + +Behringer, et al. Informational [Page 11] + +RFC 7980 Complexity Framework October 2016 + + + 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 + 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. Further, R3 must be configured to + block routing information redistributed at R2 towards R1 from being + redistributed (again) towards R4 and R5. + +3.3. Policy Centralization versus Optimal Policy Application + + Another broad area where control-plane complexity interacts with + optimal network utilization is 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 it 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 that 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 + + + +Behringer, et al. Informational [Page 12] + +RFC 7980 Complexity Framework October 2016 + + + 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. + + Thus, reducing the number of devices that 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 trade-off 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. + +3.4. Configuration State versus Per-Hop Forwarding Optimization + + The number of PHBs configured along a forwarding path exhibits the + same complexity versus optimality trade-off described in the section + above. The more classes (or queues) traffic is divided into, the + more fine-grained 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. + +3.5. 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. + + + + + +Behringer, et al. Informational [Page 13] + +RFC 7980 Complexity Framework October 2016 + + + 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. + + If the state of a link change can be detected in 10 ms, 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 destabilize the control + plane, and hence the network itself. To counter this, most + techniques that quickly detect link-down events include some form of + dampening mechanism; configuring and managing these dampening + mechanisms increases complexity. + + 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 control 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 destabilizing 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 a device running these algorithms becomes + 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 + + + +Behringer, et al. Informational [Page 14] + +RFC 7980 Complexity Framework October 2016 + + + and thus allow 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 + 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. + +4. Parameters + + In Section 3, we describe a set of trade-offs in network design to + illustrate the practical choices network operators have to make. The + amount of parameters to consider in such trade-off scenarios is very + large, and thus a complete listing may not be possible. Also, the + dependencies between the various metrics themselves is very complex + and requires further study. This document attempts to define a + methodology and an overall high-level structure. + + To analyze trade-offs it is necessary to formalize them. The list of + parameters for such trade-offs is long, and the parameters can be + complex in themselves. For example, "cost" can be a simple + unidimensional metric, but "extensibility" and "optimal forwarding + state" are harder to define in detail. + + A list of parameters to trade off contains metrics such as: + + o State: How much state needs to be held in the control plane, + forwarding plane, configuration, etc.? + + o Cost: How much does the network cost to build and run (i.e., + capital expenditure (capex) and operating expenses (opex))? + + o Bandwidth/Delay/Jitter: Traffic characteristics between two points + (average, max, etc.) + + o Configuration Complexity: How hard is it to configure and maintain + the configuration? + + + + +Behringer, et al. Informational [Page 15] + +RFC 7980 Complexity Framework October 2016 + + + o Susceptibility to Denial of Service: How easy is it to attack the + service? + + o Security (Confidentiality/Integrity): How easy is it to + sniff/modify/insert the data flow? + + o Scalability: To what size can I grow the network/service? + + o Stability: How stable is the network under the influence of local + change? + + o Reactivity: How fast does the network converge or adapt to new + situations? + + o Extensibility: Can I use the network for other services in the + future? + + o Ease of Troubleshooting: Are failure domains separated? How hard + is it to find and correct problems? + + o Optimal Per-Hop Forwarding Behavior + + o Predictability: If I change a parameter, what will happen? + + o Clean Failure: When a problem arises, does the root cause lead to + deterministic failure? + +5. Elements of Complexity + + Complexity can be found in various elements in a networked system. + For example, the configuration of a network element reflects some of + the complexity contained in this system, or an algorithm used by a + protocol may be more or less complex. When classifying complexity, + "WHAT is complex?" is the first question to ask. This section offers + a method to answer this question. + +5.1. The Physical Network (Hardware) + + The set of network devices and wiring contains a certain complexity. + For example, adding a redundant link between two locations increases + the complexity of the network but provides more redundancy. Also, + network devices can be more or less modular, which has impact on + complexity trading off against ease of maintenance, availability, and + upgradability. + + + + + + + +Behringer, et al. Informational [Page 16] + +RFC 7980 Complexity Framework October 2016 + + +5.2. Algorithms + + The behavior of the physical network is not only defined by the + hardware but also by algorithms that run on network elements and in + central locations. Every algorithm has a certain intrinsic + complexity, which is the subject of research on software complexity. + +5.3. State in the Network + + The way a network element treats traffic is defined largely by the + state in the network, in form of configuration, routing state, + security measures, etc. Section 3.1 shows an example where more + control-plane state allows for a more precise forwarding. + +5.4. Churn + + The rate of change itself is a parameter in complexity and needs to + be weighed against other parameters. Section 3.5 explains a trade- + off between the speed of communicating changes through the network + and the stability of the network. + +5.5. Knowledge + + Certain complexity parameters have a strong link to the human aspect + of networking. For example, the more options and parameters a + network protocol has, the harder it is to configure and troubleshoot. + Therefore, there is a trade-off between the knowledge to be + maintained by operational staff and desired functionality. The + required knowledge of network operators is therefore an important + part in complexity considerations. + +6. Location of Complexity + + The previous section discussed in which form complexity may be + perceived. This section focuses on where this complexity is located + in a network. For example, an algorithm can run centrally, + distributed, or even in the head of a network administrator. In + classifying the complexity of a network, the location of a component + may have an impact on overall complexity. This section offers a + methodology to find WHERE the complex component is located. + +6.1. Topological Location + + An algorithm can run distributed; for example, a routing protocol + like OSPF runs on all routers in a network. But, it can also be in a + central location such as the Network Operations Center (NOC). The + physical location has an impact on several other parameters, such as + availability (local changes might be faster than going through a + + + +Behringer, et al. Informational [Page 17] + +RFC 7980 Complexity Framework October 2016 + + + remote NOC) and ease of operation, because it might be easier to + understand and troubleshoot one central entity rather than many + remote ones. + + The example in Section 3.3 shows how the location of state (in this + case configuration) impacts the precision of the policy enforcement + and the corresponding state required. Enforcement closer to the edge + requires more network-wide state but is more precise. + +6.2. Logical Location + + Independent of its physical location, the logical location also may + make a difference to complexity. A controller function, for example, + can reside in a NOC and also on a network element. Generally, + organizing a network in separate logical entities is considered + positive because it eases the understanding of the network, thereby + making troubleshooting and configuration easier. For example, a BGP + route reflector is a separate logical entity from a BGP speaker, but + it may reside on the same physical node. + +6.3. Layering Considerations + + Also, the layer of the TCP/IP stack in which a function is + implemented can have an impact on the complexity of the overall + network. Some functions are implemented in several layers in + slightly different ways; this may lead to unexpected results. + + As an example, a link failure is detected on various layers: L1, L2, + the IGP, BGP, and potentially more. Since those have dependencies on + each other, different link failure detection times can cause + undesired effects. Dependencies are discussed in more detail in the + next section. + +7. Dependencies + + Dependencies are generally regarded as related to overall complexity. + A system with less dependencies is generally considered less complex. + This section proposes a way to analyze dependencies in a network. + + For example, [Chun] states: "We conjecture that the complexity + particular to networked systems arises from the need to ensure state + is kept in sync with its distributed dependencies." + + In this document, we distinguish three types of dependencies: local + dependencies, network-wide dependencies, and network-external + dependencies. + + + + + +Behringer, et al. Informational [Page 18] + +RFC 7980 Complexity Framework October 2016 + + +7.1. Local Dependencies + + Local dependencies are relative to a single node in the network. For + example, an interface on a node may have an IP address; this address + may be used in other parts of the configuration. If the interface + address changes, the dependent configuration parts have to change as + well. + + Similar dependencies exist for QoS policies, access-control lists, + names and numbers of configuration parts, etc. + +7.2. Network-Wide Dependencies + + Routing protocols, failover protocols, and many others have + dependencies across the network. If one node is affected by a + problem, this may have a ripple effect through the network. These + protocols are typically designed to deal with unexpected consequences + and thus are unlikely to cause an issue on their own. But, + occasionally a number of complexity issues come together (for + example, different timers on different layers), resulting in + unexpected behavior. + +7.3. Network-External Dependencies + + Some dependencies are on elements outside the actual network, for + example, on an external NTP clock source or an Authentication, + Authorization, and Accounting (AAA) server. Again, a trade-off is + made: in the example of AAA used for login authentication, we reduce + the configuration (state) on each node (in particular, user-specific + configuration), but we add an external dependency on a AAA server. + In networks with many administrators, a AAA server is clearly the + only manageable way to track all administrators. But, it comes at + the cost of this external dependency with the consequence that admin + access may be lost for all devices at the same time when the AAA + server is unavailable. + + Even with the external dependency on a AAA server, the advantage of + centralizing the user information (and logging) still has significant + value over distributing user information across all devices. To + solve the problem of the central dependency not being available, + other solutions have been developed -- for example, a secondary + authentication mode with a single root-level password in case the AAA + server is not available. + + + + + + + + +Behringer, et al. Informational [Page 19] + +RFC 7980 Complexity Framework October 2016 + + +8. Management Interactions + + A static network generally is relatively stable; conversely, changes + introduce a degree of uncertainty and therefore need to be examined + in detail. Also, the troubleshooting of a network exposes + intuitively the complexity of the network. This section proposes a + methodology to classify management interactions with regard to their + relationship to network complexity. + +8.1. Configuration Complexity + + Configuration can be seen as distributed state across network devices + where the administrator has direct influence on the operation of the + network. Modifying the configuration can improve the network + behavior overall or negatively affect it. In the worst case, a + single misconfiguration could potentially bring down the entire + network. Therefore, it is important that a human administrator can + manage the complexity of the configuration well. + + The configuration reflects most of the local and global dependencies + in the network, as explained in Section 7. Tracking those + dependencies in the configuration helps in understanding the overall + network complexity. + +8.2. Troubleshooting Complexity + + Unexpected behavior can have a number of sources: the configuration + may contain errors, the operating system (algorithms) may have bugs, + and the hardware may be faulty, which includes anything from broken + fibers to faulty line cards. In serious problems, a combination of + causes could result in a single visible condition. Tracking the root + causes of an error condition may be extremely difficult, pointing to + the complex nature of a network. + + Being able to find the source of a problem requires, therefore, a + solid understanding of the complexity of a network. The + configuration complexity discussed in the previous section represents + only a part of the overall problem space. + +8.3. Monitoring Complexity + + Even in the absence of error conditions, the state of the network + should be monitored to detect error conditions ideally before network + services are affected. For example, a single link-down event may not + cause a service disruption in a well-designed network, but the + problem needs to be resolved quickly to restore redundancy. + + + + + +Behringer, et al. Informational [Page 20] + +RFC 7980 Complexity Framework October 2016 + + + Monitoring a network has itself a certain complexity. Issues are in + scale; variations of devices to be monitored; variations of methods + used to collect information; the inevitable loss of information as + reporting is aggregated centrally; and the knowledge required to + understand the network, the dependencies, and the interactions with + users and other external inputs. + +8.4. Complexity of System Integration + + A network doesn't just consist of network devices but includes a vast + array of backend and support systems. It also interfaces a large + variety of user devices, and a number of human interfaces, both to + the user/customer as well as to administrators of the network. A + system integration job is required in order to make sure the overall + network provides the overall service expected. + + All those interactions and systems have to be modeled to understand + the interdependencies and complexities in the network. This is a + large area of future research. + +9. External Interactions + + A network is not a self-contained entity, but it exists to provide + connectivity and services to users and other networks, both of which + are outside the direct control of a network administrator. The user + experience of a network also illustrates a form of interaction with + its own complexity. + + External interactions fall into the following categories: + + o User Interactions: Users need a way to request a service, to have + their problems resolved, and potentially to get billed for their + usage. There are a number of human interfaces that need to be + considered, which depend to some extent on the network, for + example, for troubleshooting or monitoring usage. + + o Interactions with End Systems: The network also interacts with the + devices that connect to it. Typically, a device receives an IP + address from the network and information on how to resolve domain + names, plus potentially other services. While those interactions + are relatively simple, the vast amount of end-device types makes + this a complicated space to track. + + o Internetwork Interactions: Most networks connect to other + networks. Also, in this case, there are many interactions between + networks, both technical (for example, running a routing protocol) + as well as non-technical (for example, tracing problems across + network boundaries). + + + +Behringer, et al. Informational [Page 21] + +RFC 7980 Complexity Framework October 2016 + + + For a fully operational network providing services to users, the + external interactions and dependencies also form an integral part of + the overall complexity of the network service. A specific example + are the root DNS servers, which are critical to the function of the + Internet. Practically all Internet users have an implicit dependency + on the root DNS servers, which explains why those are frequent + targets for attacks. Understanding the overall complexity of a + network includes understanding all those external dependencies. Of + course, in the case of the root DNS servers, there is little a + network operator can influence. + +10. Examples + + In the foreseeable future, it is unlikely to define a single, + objective metric that includes all the relevant aspects of + complexity. In the absence of such a global metric, a comparative + approach could be easier. + + For example, it is possible to compare the complexity of a + centralized system where algorithms run centrally and the results are + distributed to the network nodes with a distributed algorithm. The + type of algorithm may be similar, but the location is different, and + a different dependency graph would result. The supporting hardware + may be the same and thus could be ignored for this exercise. Also, + layering is likely to be the same. The management interactions, + though, would significantly differ in both cases. + + The classification in this document also makes it easier to survey + existing research with regards to which area of complexity is + covered. This could help in identifying open areas for research. + +11. Security Considerations + + This document does not discuss any specific security considerations. + +12. Informative References + + [Behringer] Behringer, M., "Classifying Network Complexity", + Proceedings of the 2009 Workshop on Re-architecting the + Internet (Re-Arch '09), ACM, DOI 10.1145/1658978.1658983, + December 2009. + + [Chun] Chun, B-G., Ratnasamy, S., and E. Eddie, "NetComplex: A + Complexity Metric for Networked System Designs", + Proceedings of the 5th USENIX Symposium on Networked + Systems Design and Implementation (NSDI '08), pp. + 393-406, April 2008, . + + + +Behringer, et al. Informational [Page 22] + +RFC 7980 Complexity Framework October 2016 + + + [Doyle] Doyle, J., Anderson, D., Li, L., Low, S., Roughnan, M., + Shalunov, S., Tanaka, R., and W. Willinger, "The 'robust + yet fragile' nature of the Internet", Proceedings of the + National Academy of Sciences of the United States of + America (PNAS), Volume 102, Number 41, + DOI 10.1073/pnas.0501426102, October 2005. + + [ncrg] IRTF, "IRTF Network Complexity Research Group (NCRG) + [CONCLUDED]", . + + [RFC1925] Callon, R., "The Twelve Networking Truths", RFC 1925, + DOI 10.17487/RFC1925, April 1996, + . + + [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural + Guidelines and Philosophy", RFC 3439, + DOI 10.17487/RFC3439, December 2002, + . + + [wiki] "Network Complexity - The Wiki", + . + +Acknowledgements + + The motivations and framework of this overview of studies into + network complexity are the result of many meetings and discussions + with too many people to provide a full list here. However, key + contributions have been made by John Doyle, Dave Meyer, Jon + Crowcroft, Mark Handley, Fred Baker, Paul Vixie, Lars Eggert, Bob + Briscoe, Keith Jones, Bruno Klauser, Stephen Youell, Joel Obstfeld, + and Philip Eardley. + + The authors would like to acknowledge the contributions of Rana + Sircar, Ken Carlberg, and Luca Caviglione in the preparation of this + document. + + + + + + + + + + + + + + + + +Behringer, et al. Informational [Page 23] + +RFC 7980 Complexity Framework October 2016 + + +Authors' Addresses + + Michael H. Behringer + Cisco Systems + Building D, 45 Allee des Ormes + Mougins 06250 + France + + Email: mbehring@cisco.com + + + Alvaro Retana + Cisco Systems + 7025 Kit Creek Rd. + Research Triangle Park, NC 27709 + + United States of America + Email: aretana@cisco.com + + + Russ White + Ericsson + 144 Warm Wood Lane + Apex, NC 27539 + United States of America + + Email: russ@riw.us + URI: http://www.ericsson.com + + + Geoff Huston + Asia Pacific Network Information Centre + 6 Cordelia St + South Brisbane, QLD 4101 + Australia + + Email: gih@apnic.net + URI: http://www.apnic.net + + + + + + + + + + + + + +Behringer, et al. Informational [Page 24] + -- cgit v1.2.3