Russ White began his network engineering career installing terminal emulation cards and inverse multiplexers in the United States Air Force. In 1996, he moved to Raleigh, N.C., to join Cisco Systems in the Technical Assistance Center (TAC) routing protocols team. From TAC, Russ moved to the global escalation team, and then into engineering, and finally into sales as a Distinguished Architect. He is currently a network architect working in the area of network complexity and large scale design, a member of the IETF Routing Area Directorate, an active speaker and writer, and active in the Internet Society.

He holds CCIE #2637, CCDE 2007:001, the CCAr, a Masters in Information Technology from Capella University, and a Masters in Christian Ministry from Shepherds Theological Seminary. He lives in Oak Island, N.C., with his wife and two children, and is currently a P.h.D student at Southeastern Baptist Theological Seminary.

Jeff Tantsura started his network engineering career in early 1990s at a small ISP as system/network administrator, later working for bigger ISPs where he was responsible for network design and architecture, vendor selection. Currently Jeff is heading Technology Strategy Routing at Ericsson as well as chairing IETF Routing Working Group. Jeff holds MSc in Computer Science and Systems Analysis from University of Georgia and Executive Certificate of Business Excellence from Haas School of Business, Berkeley.

He also holds CCIE R&S #11416 and Ericsson Certified Expert IP Networking #8.

Jeff lives in Palo Alto, CA, with his wife and youngest child.

Introduction . . . . . . . . . . . . xvii

How This Book Is Organized . . . . . . . xvii

Chapter 1: Defining Complexity . . . . . . . . . 1

What Is Complexity? . . . . . . . . . 3

Anything I Don’t Understand . . . . . . 3

Anything with a Lot of Parts . . . . . . . 5

Anything for Which There Is More State Than Required to

Achieve a Goal . . . . . . . . . 9

Unintended Consequences . . . . . . 11

Why So Much Complexity? . . . . . . . . 13

Future Extensions versus New Protocols . . . . 16

Unexpected Errors . . . . . . . . 17

Why Not Build Infinitely Complex Systems? . . . . . 18

Quick, Cheap, and High Quality: Choose Two . . . 20

Consistency, Availability, and Partition Tolerance:

Choose Two . . . . . . . . . 21

Journey into the Center of Complexity . . . . . . 22

Chapter 2: Components of Complexity . . . . . . . 25

Network Convergence . . . . . . . . . 26

Path Vector: A BGP Example . . . . . . 26

Distance Vector: An EIGRP Example . . . . . 28

Link State: OSPF and IS-IS Convergence . . . . 30

State . . . . . . . . . . . . 31

Amount of Information . . . . . . . 32

An Example of State Failure in the Real World . . . 33

Final Thoughts on State . . . . . . . 34

Speed . . . . . . . . . . . . 35

The Network That Never Converges . . . . . 35

The Flapping Link . . . . . . . . 37

Final Thoughts on Speed . . . . . . . 38

Surface . . . . . . . . . . . . 38

The Hourglass Model . . . . . . . . . 41

Optimization . . . . . . . . . . . 44

A Final Thought . . . . . . . . . . 46

Chapter 3: Measuring Network Complexity . . . . . . 47

Some Measures of Network Complexity . . . . . 49

Network Complexity Index . . . . . . 49

Modeling Design Complexity . . . . . . 51

NetComplex . . . . . . . . . 53

Organized Complexity . . . . . . . . . 55

Is This a Waste of Time? . . . . . . . . . 58

A Final Thought . . . . . . . . . . 58

Chapter 4: Operational Complexity . . . . . . . . 61

Exploring the Problem Space . . . . . . . . 61

The Cost of Human Interaction with the System . . . 61

Policy Dispersion versus Optimal Traffic Handling . . 66

Solving the Management Complexity Problem . . . . 69

Automation as a Solution to Management Complexity . 69

Modularity as a Solution to Management Complexity . 72

Protocol Complexity versus Management Complexity . 74

A Final Thought . . . . . . . . . . 77

Chapter 5: Design Complexity . . . . . . . . . 79

Control Plane State versus Stretch . . . . . . . 81

Aggregation versus Stretch . . . . . . . 83

Traffic Engineering . . . . . . . . 85

State versus Stretch: Some Final Thoughts . . . . 87

Topology versus Speed of Convergence . . . . . . 88

Ring Topology Convergence . . . . . . 88

Redundancy versus Resilience . . . . . . 90

Topology versus Speed of Convergence:

Some Final Thoughts . . . . . . . 93

Fast Convergence versus Complexity . . . . . . 94

Improving Convergence with Intelligent Timers: Talk Faster . . . . . . . . . 96

Removing Timers from Convergence: Precompute . . 99

Working around Topology: Tunneling to the Loop-Free

Alternate . . . . . . . . . 101

Some Final Thoughts on Fast Convergence . . . 104

Virtualization versus Design Complexity . . . . . 106

Functional Separation . . . . . . . 108

Forwarding Plane Complexity . . . . . . 109

Control Plane Complexity . . . . . . 109

Shared Fate Risk Groups . . . . . . . 111

A Final Thought . . . . . . . . . . 111

Chapter 6: Managing Design Complexity . . . . . . 113

Modularity . . . . . . . . . . . 113

Uniformity . . . . . . . . . 114

Interchangeable Modules . . . . . . . 120

How Modularity Attacks the Complexity Problem . . 121

Information Hiding . . . . . . . . . 122

Aggregation . . . . . . . . . 122

Failure Domains and Information Hiding . . . . 126

Final Thoughts on Information Hiding . . . . 128

Models . . . . . . . . . . . 129

Waterfall . . . . . . . . . . 129

Places in the Network . . . . . . . 131

Hierarchical . . . . . . . . . 132

UML . . . . . . . . . . . 134

A Final Thought . . . . . . . . . . 136

Chapter 7: Protocol Complexity . . . . . . . . 137

Flexibility versus Complexity: OSPF versus IS-IS . . . . 138

Layering versus Protocol Complexity . . . . . . 141

The Seven-Layer Model . . . . . . . 143

The Four-Layer Model . . . . . . . 146

The Iterative Model . . . . . . . . 147

Protocol Stacks and Design . . . . . . 148

Protocol Complexity versus Design Complexity . . . . 149

Microloops and Fast Reroute . . . . . . 149

EIGRP and the Design Conundrum . . . . . 158

Final Thoughts on Protocol Complexity . . . . . 162

Chapter 8: How Complex Systems Fail . . . . . . . 163

Feedback Loops . . . . . . . . . . 164

Positive Feedback Loops in Network Engineering . . 169

Speed, State, and Surface: Stability in the

Network Control Plane . . . . . . . 174

Shared Fate . . . . . . . . . . . 177

Virtual Circuits . . . . . . . . . 177

TCP Synchronization as a Shared Fate Problem . . 179

A Final Thought . . . . . . . . . . 181

Thoughts on Root Cause Analysis . . . . . 181

Engineering Skills and Failure Management . . . 182

Chapter 9: Programmable Networks . . . . . . . 185

Drivers and Definition . . . . . . . . . 186

Business Drivers . . . . . . . . 186

The Ebb and Flow of Centralization . . . . . 188

Defining Network Programmability . . . . . 191

Use Cases for Programmable Networks . . . . . 193

Bandwidth Calendaring . . . . . . . 193

Software-Defined Perimeter . . . . . . 196

Programmable Network Interfaces . . . . . . 200

The Programmable Network Landscape . . . . . 201

OpenFlow . . . . . . . . . . 202

YANG . . . . . . . . . . 204

Path Computation Element Protocol . . . . . 207

Interface to the Routing System . . . . . 210

A Final Thought . . . . . . . . . . 212

Chapter 10: Programmable Network Complexity . . . . . 215

The Subsidiarity Principle . . . . . . . . 216

Policy Management . . . . . . . . . 217

Policy Dispersion . . . . . . . . 220

Policy Consistency . . . . . . . . 222

Policy Complexity . . . . . . . . 223

Surface and the Programmable Network . . . . . 224

Impact on Failure Domains . . . . . . . . 226

Wide Area Failure Domains . . . . . . 227

Data Center Failure Domains . . . . . . 228

Application to Control Plane Failure Domain . . . 229

Controller to Controller Failure Domain . . . . 229

Final Thoughts on Failure Domains . . . . . 229

A Final Thought . . . . . . . . . . 230

Chapter 11: Service Virtualization and Service Chaining . . . . 233

Network Function Virtualization . . . . . . . 234

NFV: A Use Case . . . . . . . . 236

Service Chaining . . . . . . . . . . 242

Service Function Chaining . . . . . . 243

Segment Routing . . . . . . . . 245

A Final Thought . . . . . . . . . . 248

Chapter 12: Virtualization and Complexity . . . . . . 249

Policy Dispersion and Network Virtualization . . . . 250

State and Service Chaining . . . . . . 253

State and Optimization . . . . . . . 254

Surface and Policy Interaction . . . . . . 255

Surface and Policy Proxies . . . . . . 255

Other Design Considerations . . . . . . . 256

Coupling and Failure Domains . . . . . . 257

Troubleshooting . . . . . . . . 260

The Orchestration Effect . . . . . . . . 262

Managing Complexity . . . . . . . . . 264

A Final Thought . . . . . . . . . . 266

Chapter 13: Complexity and the Cloud . . . . . . . 267

Where Does the Complexity Live? . . . . . . 268

Cloud Centric . . . . . . . . . 269

Vendor Centric . . . . . . . . . 270

Network Centric . . . . . . . . 271

Is There a “Right Way?” . . . . . . . 271

Centralize What? . . . . . . . . . . 272

Cloudy Complications . . . . . . . . . 273

Security . . . . . . . . . . 273

Data Portability . . . . . . . . 276

A Final Thought . . . . . . . . . . 277

Chapter 14: A Simple Ending . . . . . . . . . 279

Defining Complexity . . . . . . . . . 279

Difficult to Understand . . . . . . . 280

Unintended Consequences . . . . . . 280

Large Numbers of Interacting Parts . . . . . 280

What Makes Something “Too Complex”? . . . 281

Complexity Is a Tradeoff . . . . . . . . 282

Modeling Complexity . . . . . . . . . 284

Managing Complexity in the Real World . . . . . 286

Don’t Ignore Complexity . . . . . . . 286

Find a Model to Contain the Complexity . . . . 287

A Final Thought . . . . . . . . 288

TOC, 9780133989359, 10/28/2015