A Framework for Defining Network Complexity
RFC 7980
Document | Type |
RFC - Informational
(October 2016; No errata)
Was draft-behringer-ncrg-complexity-framework (individual)
|
|
---|---|---|---|
Authors | Michael Behringer , Alvaro Retana , Russ White , Geoff Huston | ||
Last updated | 2018-12-20 | ||
Replaces | draft-retana-network-complexity-framework, draft-irtf-ncrg-complexity-framework, draft-irtf-ncrg-network-design-complexity | ||
Stream | ISE | ||
Formats | plain text html pdf htmlized bibtex | ||
IETF conflict review | conflict-review-behringer-ncrg-complexity-framework | ||
Stream | ISE state | Published RFC | |
Consensus Boilerplate | Unknown | ||
Document shepherd | Adrian Farrel | ||
Shepherd write-up | Show (last changed 2016-07-18) | ||
IESG | IESG state | RFC 7980 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | "Nevil Brownlee" <rfc-ise@rfc-editor.org> | ||
IANA | IANA review state | IANA OK - No Actions Needed | |
IANA action state | No IANA Actions |
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 . . . . . . . . . . . . . . . . . . . . 18Show full document text