Cisco Blogs

Cisco Blog > Architect & DE Discussions

Complexity is just like Chocolate…

ChocolateConfession time: If someone puts a nice chocolate in my reach, I find it very hard to resist. In fact, there are few days where I don’t get my dose of dark chocolate. Chocolate is one of the pleasures in life. Of course we all know that eating too much chocolate will get you into big trouble: With your blood sugar levels, your shirt-size, your partner, and with your kids (albeit for different reasons).

Complexity is really the same thing! Let’s be honest: Can we ever resist the latest features and functionalities on our networks? And with each new feature, we ask for even more visibility, control, and sub-features? But just like with chocolate, we all know that too much isn’t good for us.

Yes, we all love complexity!

Hang on – that’s not what we hear in the press, is it? “IT Complexity considered most important inhibitor to innovation and effectiveness” (1) “What causes enterprise data breaches? The terrible complexity and fragility of our IT systems” (2) You can find many quotes in this direction. So – we hate complexity?

The truth is: it’s just like with chocolate – small improvements can add lots of value, but eat too much and you become sluggish and might even get seriously sick.

The funny thing is, there is actually no definition of the term “network complexity”. Researchers have dug deep into certain areas, such as software complexity, graph complexity, routing complexity, and many others. However, networks have a bit of all of that, and there is no global view on network complexity. The Internet Research Task Force tried to get to the bottom of the topic, created the “Network Complexity Research Group”(3) in 2011, but concluded in 2014 without tangible results. Researchers and industry specialists collaborated at, with lots of materials posted and discussed, but again no clear results.

What we do see is that too much complexity tends to slow us down. It becomes hard to make changes to the network, because we don’t really know what will happen. Introducing new systems requires serious up front testing, because there are just too many interactions on the network, and we can’t really judge the impact of change.

But complexity can also deliver value that we want. If you want a branch office that is robust against failures, you have to do a redundant set-up (middle of the graph). But that’s more complex than the single device/line solution (on the left of the graph), isn’t it? You need some failover protocols and mechanisms that you don’t need on the simple layout? Yes, you *do* want a certain level of complexity, because it provides value, in this case robustness against outages. Other values can be: Security, agility, programmability, and so on (there are lots!). There is no right or wrong here: In my home network, the left model is perfectly ok, in a branch office of a bank it might not be. All depends on the use case and its requirements.

Obviously, there are limits: Adding a third row to this layout (right) intuitively will not increase availability, but probably cause more failures due to more complex protocol interactions that are not widely deployed.

When eating chocolates, your waist line tends to grow over time. The same is true for network and IT complexity: Most networks start out reasonably simple, but then new requirements need to be supported, you move to a new device and OS types in parts of the network, ever growing security concerns add layer by layer of protections, and so on. And: Nobody ever removes components that aren’t used any longer. When have *you* last removed some feature from a network?

The Cynefin framework(4) (left) illustrates this process, and helps understanding the progression of complexity over time: Most networks start out as “obvious”, simple and consistent architecture, uniform devices, OSs, and initially simple requirements. As we add new components, make changes, allow exceptions, the network becomes more complicated. But “complicated” still means that an expert can, albeit with some effort, model the effect of a proposed change. Complex systems show an emergent behaviour: Even with massive analysis, the outcome of a change is not fully predictable. Finally, a system becomes chaotic if there is no relationship between a change and the result any more – This is unpredictability. Most networks today operate in the “complex” area, which is why analysis on paper is usually not enough. The only way to really know whether it works or not is to test it. No paper analysis can safely predict the behaviour of a complex system.

In summary:
• Complexity isn’t all bad. It’s important to balance the right level of complexity with the features you require.
• The level of complexity typically changes over the lifetime of a network.
• Complexity and Chocolates are best enjoyed in moderation.

In the next blog we’ll suggest some high level measures to control complexity. And, hopefully not surprisingly, there are actually a lot of innovations happening in Cisco which reduce complexity. Stay tuned!

This blog was prepared as part of a team project on complexity, actively supported by: Bruno Klauser, Patrick Charretour, Mehrdad Ghane, Dave Berry and Rebecca Holm Breinholdt.

(1) A.T.Kearney Study 2009
Photo credit: Dominic Lockyer, shared under the creative commons licence 2.0.





Tags: , , ,

Autonomic Networking: Where Do We Go From Here?

It’s great to be back at another Cisco Live event, this time in the great city of San Francisco.  This is the last day of the event, and if you have some time, please do stop over at the World of Solutions, where you can see Autonomic Networking in action.  We have set up a live demo of the Autonomic Networking Infrastructure (ANI) at the Service Provider area!  The following figure shows a summary of the functionality, and i’d like to refer you to a previous blog for a more thorough explanation.


Summarising, the ANI allows networks to grow and self-organize organically, merely by  devices at the edge of the Autonomic Domain joining the Autonomic Control Plane.  A new device is cabled up and powered up and will be discovered by a  device at the edge of the Autonomic Domain/Network through the Channel Discovery Process.  The new device offers its identity to the Network, and the Network, after successful authentication, will deliver a Domain Certificate to the New Device as a result, and this is achieved using the Adjacency Discovery Process.  The New Device can then leverage this Domain Certificate to join the Autonomic Control Plane (ACP), which is essentially an IPv6 based, routed IP infrastructure that is secure/encrypted, self-organising and self-healing, and which cannot be de-configured and is not prone to mis-configurations. Read More »

Tags: , , , , , , , , , ,

Setting the Stage for the Cisco Mobile Workspace Solution with Citrix CVD

CiscoWotrkSpaceSolutionThe times keep changing: first there were devices, then there were apps, and today, if you don’t develop a strategy for enterprise mobility and get ahead of the trend, the mobile wave will leave you behind. A year ago, after talking with many of our customers, partners, and our own technical sales teams, we realized that IT organizations were facing enormous challenges when making the transition from simple BYOD to adopting an enterprise mobility strategy across the business. As is typical during such tremendous market transitions like mobility, IT organizations were spending a lot of time figuring out how to line up the pieces required to support a mobile workforce, sorting through and weighing the many technology and vendor choices.

Today in conjunction with our friends at Citrix, we are happy to highlight the  Cisco Mobile Workspace Solution with Citrixbuilt on the Citrix Workspace Suite. We are very excited to deliver this first of its kind, comprehensive solution to our customers. Today I’d like to take a step back and set the stage for the Cisco Mobile Workspace Solution with Citrix by taking you through our thought process in creating the right enterprise mobility solution for our customers. Read More »

Tags: , , , , , , , , , , , , , , , , , , , ,

Autonomic Networking at Cisco Live Milano!

Welcome to Milano!

Wow, what an activity on the first day at the Cisco Campus / World of Solutions. It’s great to see all these people thirsty for knowledge, and all these people looking for intelligent solutions for their business needs.

One of those business needs is removing complexity from networks by making networks self-managing, or in other words Autonomic Networking.  2014 will be the year that we are shipping the first sets of functionality in this space, so that makes us really exited.  After all we have been working on this for more than 3 years internally, and its great to finally see the fruits of that hard work.

Michael has explained in his blog that Autonomics is all around us, but until now there wasn’t a solution that allowed other applications to leverage a common autonomic infrastructure.  Finally it is here!  The Autonomic Networking Infrastructure allows Service Providers to bootstrap new devices completely zero touch, in a secure fashion, without pre-staging the devices and/or a back-end DHCP Server, and this totally topology independent!  Just plug in the device, and watch it getting authenticated, receiving a Domain Certificate, joining the Autonomic Domain, and joining the Autonomic Control Plane, which provides indestructible IPv6 end-to-end connectivity!  If an mdns-enabled TFTP server is connected to the network, it will leverage the Autonomic Control Plane to announce its service, upon which the devices will pull in their configuration! Read More »

Tags: , , , , , , , , ,

Building a useable Autonomic Networking Infrastructure from the Ground Up

Yep, that’s what we did, and yes we are shipping it today!

As Michael’s blog explained, autonomics are all around us, both in feature implementation (e.g. a routing protocol like OSPF) as well as in architectural frameworks like GANA.  But while the former has created isolated, per feature domains of autonomicity, the latter has never really resulted into a useable implementation used by a network engineer to date!

Lets go back to what we said out the vision of Autonomic Networking was going to be, as in the below figure, which I essentially repeated from my DON’T PANIC blog. The observant reader  will notice that I changed the term ‘simple management tools’ into ‘SDN/NMS Controller across a simplified northbound interface’.  After all we can’t ignore markets trends like SDN.

Autonomic Networking: The Vision

The vision remains the same whether you use an iPAD versus a super-duper controller though: you ingest a network wide behavior into the  network, as we can model the totality of the network in an abstract, location-independent, network-wide manner.  Autonomic Processes turn this network wide behavior into local state, and might invoke control loops between nodes to do this effectively.  This ultimately results into the good-ole legacy network protocols to become self-managing, without changing the protocols themselves.  Genius! But how do we get there in practice?  And can customers trust us to do the right thing from day 1? Read More »

Tags: , , , , , ,