Orhan Ergun 5 Comments

Network Design should be simple! Simplicity is the first network design best practice that I want you to remember. If you have been in the field long enough, you have probably heard about the KISS principle.

If you are a regular follower of my blog, you have maybe heard about the SUCK principle as well.

KISS stands for Keep It Simple Stupid. But do you really know what the simple part is ?  Can every part of the network be a simple ?

Unfortunately NOT ! It just cannot be ! But still you should on simplifying as much of your network as possible.

As I have indicated in the past here, intelligence should be at the edge of the networks and network core should be as simple as possible. If you read the above article, you will see some examples. ( There are different opinions about the place of simplicity in networks. Some researchers believe that if the core has some intelligence the overall network complexity is reduced ).

Networks have many protocols, technologies. Understanding each of them might be easy but interaction between them creates complexity.

In my CCDE training sessions, I like to give the Pepper and Salt example to explain this point.

network complexity

Which one is salt and which one is pepper ? It needs to be so simple for a basic object, doesn’t it ?But I almost always confuse this !

Network design is exactly the same. There are many technologies that interact with each other.
Although each one might be simple,the end result may not be so simple to predict.

You summarize the prefixes in one place of the network, and you create sub optimality in another place.

You enable a new feature,such as IPv6 or Multicast, in one part of the network and the result is that you open the network to a lot of new security attacks.

Those features were needed for robustness, but they create fragility.

You may not see the impact immediately but it can be huge. This is known as Butterfly Effect in design.

A butterfly flapping its wings in South America can affect the weather in Central Park.

This is the first post of the Network Design Rules series that I decided to share with my blog readers. Thanks for reading and please share your thoughts in the comment box below.

 
0.00 avg. rating (0% score) - 0 votes
  • gaso

    Hi Orhan,

    I think some of the problems with network complexity are caused by us as network engineers, and that’s because we love to solve complex things applying all kind of kludges to the network just to solve other people mistakes.

    Great post.

    • @gaso , Human is always involved in complexity measurement. Hope you checked my network complexity article as well. Thanks for the comment 🙂

  • IMHO there are couple of things to consider here:

    – Some level of complexity just cannot be removed and is going to be there.

    For example to drive a car on road you need to have driving license. But to get driving license you need to know how to drive a car. So it’s a chicken and egg problem again.

    – There needs to be clear bussiness drivers and ROI behind any network project which most network engineers don’t understand unless they start thinking about design and larger picture.

    – Some Engineers just have this urge to come up with fancy ideas without understanding additional level of complexity that brings. Some of it is ofcourse driven by marketing about particular technology or product.

    – Some Engineers add additional level of complexity to ensure they are the only one that understands a given network end to end ( Perhaps it gives them comfort from job security standpoint 🙂 )

    – In many cases when it comes of redesign a given network, you just need to reverse engineer the things to get the background you need to begin with. Documents are either in nonsense formats or too old to be referred. I still don’t understand why good , standardized documentation along with regular review process from Network Architect/Designer as idea never made into Network Design books and under MTTR sections and they only focus on HA, Resliancy, Redundancy etc.

    Also curious to know how SDN ( Open Source or Vendor Specific ) still solves these basic fundamental problems. Perhaps SDN is just a fancy word to bring new and exitings ways to bring additinal level of complexity. Per flow bahaviors ? …. They must be kidding or been never into Operations side of things.

    • It seems this will be fun discussion 🙂 Let me share my thoughts as well.

      Some level of complexity cannot be removed you said. Definitely true. As I said in my network complexity article, complexity is good but unnecessary complexity is bad and I defined what could be unnecessary ones.

      Chicken and Egg , hmmm. I think I will be disagree since you wouldn’t learn it on the same way where you drive. If you do , then yes.

      Marketing about particular technology and product. Definitely agree. Biggest one nowadays is ACI , just one word , it is bad idea and will not live so long.

      Sometimes some engineers add complexity on purpose 🙂 I know many people who did this , so yes people think that they are cool..

      How SDN will solve the complexity problem ? or would it be helpful ? I shared my thoughts about this in my Network Complexity article since my thoughts are the same and I explain them in detail , I recommend to people who read this comment to check that article particularly.

      Thanks for your thoughts Deepak.

      Cheers,
      Orhan

  • Pingback: Design considerations for network mergers and acquisitions | Cisco Network Design and Architecture | CCDE Bootcamp | orhanergun.net()