I get a little worked up when I see network designers describing our craft as an ‘art.’ I understand where the thought comes from; there is certainly a level of creativity required to arrive at an optimal network design for a given set of constraints and business challenges. It is nevertheless my opinion that we are working within a science, not an art. The key differentiator is whether we can judge one network design to be superior to another. With the traditional arts, it not objectively possible to say one song/painting/movie is ‘better’ than another. We can measure them on various points (Rotten Tomatoes [link] scores for movies, sale price for paintings, etc), but how any one individual perceives an artist’s creation is not open to debate. I like Dumb & Dumber more than Casablanca, and no amount of objective information is going to change my mind! 😃
This is not true with network design. If two network designers review a set of business and technical requirements, they may generate unique proposals. When this occurs, invariably one or more of the following are at the root of the disagreement.
A) They interpreted the requirements differently, or the requirements were defined well enough
With good network designers, this is often the root cause. It is possible that they did not receive the same requirement information. More often, one of the engineers overlooked a key piece of information, such as a customer preference or existing technology choice that must be taken into account. If the requirements were not well-defined, assumptions must be made. These assumptions become quasi-requirements, which lead to different solutions.
B) Have differing personal opinions on the implementation details of a solution
Also known as ‘practical experience’ — These are the biases that we have developed over the years of deploying and managing technologies. Pretty much every network engineer has a preferred IGP, for example. Perhaps you have worked more often with OSPF networks, and therefore you are more comfortable using it to solve most problems. That does not make it the right choice for every proposed network design. This point of disagreement can also result from negative experiences, especially as they relate to implementation-level problems. Remember that Cisco OSPF in IOS-XR bug that kept you up for several consecutive nights, or the time IS-IS ‘blew up’ for you because you added a Juniper router to a Cisco network (hopefully not real examples for you). While implementation-level details should factor into real-world designs, do not let them talk you out of the correct technology solution (especially on a CCDE exam, hint hint).
C) Do not share the same knowledge base / understanding of the design elements
This is the category of disagreement related to the knowledge of our network designers. If one engineer proposes an IS-IS solution, and the other engineer has no experience with the protocol, there is very likely to be a disagreement.
For humble network architects, this should not be a problem. We all have our areas of expertise, and I can assure you no one is an expert in all possible technologies. Those technologies with which I have less practical experience can still be valid solutions to a problem. It is my responsibility as a network architect to have a solid understanding of these options, and if one appears viable I must put in the time to study it to see if there is a place for it in my proposal. I recommend knowing enough about each networking technology to answer the following questions:
1) What problems can it solve?
2) What are the pre-requisites?
3) How well can it scale?
4) How manageable is the resulting design?
That short list is in my experience sufficient to know when/where a technology can be useful. I can quickly rule out those that won’t fit (for example, if L2 adjacency is required, I can rule out L3VPN) and then spend time researching the remaining options to find the best answer.
Note that none of these points of disagreement allow us to develop unique, equally-valid solutions to the original problem. Perhaps in the simplest cases it does not matter if we choose OSPF or EIGRP as our IGP, but with enough probing we should be able to find information that leads us to one specific solution. Maybe we could ask the following questions:
1) Are you concerned with vendor lock-in?
2) What is your convergence requirement?
3) Does your support team have operational experience with either protocol?
4) To what size do you intend to scale the network?
5) Might you deploy dynamically-calculated MPLS-TE tunnels in the future?
After getting honest answers to these questions, two network designers should be able to come to an agreement on the correct IGP.
BTW, I am not disagreeing with the core tenet of Art of Network Architecture, and not just because Russ and Denise are two of my favorite people in networking. The point I am making is that there is a difference between network architecture and design.
Jeremy Filliben is a network architect and CCDE instructor for Pristine Packets. Details about his training can be found on his website, www.jeremyfilliben.com. Jeremy has trained over 80 CCDEs in his 7 years in the industry.
No comments:
Post a Comment