Friday, May 01, 2015

Skill Development Planning by the Dozen


I’ve been going to Cisco Live as one of the speakers for several years now. As Cisco employee, you can go to Cisco Live (for free) only if you are a speaker, or part of the World of Solutions exhibition, or if you come for the customers, or to support the network infrastructure for the event.

For the past three years at Cisco Live I’ve been sharing strategy and tips and tricks of how to become CCIE based on my own experience. My part of the session is focusing on skill development planning to achieve the objective, which is to pass CCIE lab exam. There are many technical sessions available during the event, but only very few talk about how to build learning plan and walk you through step by step of sample plan created by someone who has done it. I believe the session material can be applied outside CCIE context, and it’s relevant with my previous post, so I’m going to share it here with some updates.



Robert Grant mentioned that strategy is the means by which individuals achieve their objectives. In short, successful strategy can be achieved by having clear and consistent goal, understanding the environment or the industry as well as our capabilities, and executing with effective structure and system.

You must have a strategy for your skill development. And here are a dozen steps you can follow to build one:

1. Begin with End in Mind

What do you see at the end of the road? What is your objective? What are you planning to accomplish? Having a clear goal can help you to plan on how to achieve it. Your goal can be your one thing. Whatever it is, you must have a goal or objective. If you don’t have it yet, go find one.

To make it easier to digest, I will use an example here. Let’s say today you are a network engineer who puts a goal to become Network Function Virtualization (NFV) Solutions Architect someday.

2. Break It Down

How to eat an elephant? Cut it into pieces and eat one piece at a time. Big goal must be dismantled into pieces so we can understand it well.

What is NFV? What does Solutions Architect do?

As per Wikipedia, NFV is a network architecture concept that proposes using IT virtualization related technologies to virtualize entire classes of network node functions into building blocks that may be connected, or chained, to create communication services. As described by ETSI NFV whitepaper, Virtualization eliminates the dependency between a network function (NF) and its hardware, as seen in typical physical network appliances, by creating a standardized execution environment and management interfaces for the Virtualized Network Functions (VNFs). ETSI defined NFV framework into three main components: Virtualized Network Function (VNF), NFV Infrastructure, and NFV Management and Orchestration (MANO).


If we break down each NFV component, we can see sample of a product or solution that we have to learn:

- VNF is the actual Network Function application, could be run as Virtual Machine (VM). Sample of this are virtual router, virtual switch, virtual firewall, virtual load balancer, virtual web filter and so on
- NVF Infrastructure consists of virtualization layer, that can be server hypervisor such as VMware ESXi or Linux KVM, and physical hardware resources for compute, network and storage. This includes the server host operating system (e.g. Linux), physical server, networking devices and underlying protocols (routing, switching), and storage disk, SAN as well as protocols such as iSCSI, NFS and FCoE
- NVF MANO includes Virtualized Infrastructure Manager like OpenStack, VMware, SDN controller such as Open Daylight, VNF Life cycle manager and Cross Domain Orchestrator such as Tail-f NCS

Don’t forget the northbound/southbound and interface to connect between the components: Rest API, OpenFlow, NetConf, data format with Json and XML, and if you are into data modeling: YANG. And some of the components require customization and module expansion using programming language such as Python and Java.

Solutions Architect is someone who can articulate problem statements, solution capabilities and the gaps between the two. He or she must correlate business issues around technology and processes, and able to create an architectural solution specific to a given customer or segment. Solutions Architect needs to interpret business requirements and strategies, and mapping them to solution capabilities, and driving the integration of the solution into an existing infrastructure, which would drive systems integration and implementation approaches.

Solutions Architect skill requirements go beyond the end-to-end technical architecture:

- deep expertise in several technology domains (network/infrastructure, data, applications/middleware)
- fluency in network technologies and related advanced technologies
- expertise in several soundness disciplines (availability, security) as well as operational disciplines (systems management, change management)
- fluency in key IT business architecture areas including business process design and governance

To become Solutions Architect one must possess customer skill, business oriented mindset, communication, ability to collaborate, planning skill, leadership, and problem solving skill. Above all, it is important for a Solutions Architect to be able to solve the puzzle, put all the pieces together, and to connect the dots.

3. Self Assessment

Now you have a better picture of your goal, it is important to understand where you are standing today and see the gaps. Bruno, CCIE program manager and my co-speaker at Cisco Live, is very famous with his mantra: "Know what you don’t know".

If you know what you don’t know, then you can build the plan to acquire the knowledge. My advise is to build some kind like checklist, let’s say listing both the NFV components and the Solution Architect skillset from the above point. Then make self assessment about your current situation with scale between 1 to 5 with level 1 as the lowest (no knowledge at all) and level 5 as the highest (posses the expertise to design, implement and advise others, being the “go-to guy”):


- how good are you with linux OS? (1-5)
- how good are you with hypervisor e.g. ESXi, KVM? (1-5)
- how good are you with OpenStack? (1-5)
- how fluent are you in Java? (1-5)
And so on.

You can do the same with non-technical skills:

- how is your communication skill? (1-5)
- how is your ability to articulate solution? (1-5)
- how good is your problem solving skill? (1-5)
- how good is your understanding of customer business? (1-5)
And so on.

4. Define Target Performance Level

This is the question I always ask from time to time: How do you define success?
If you have the list of required skills to become NFV Solutions Architect from both technical and non-technical, and you have done self assessment to understand your current situation, what level should you target for each skill?

In a perfect world, we need to be 5 in everything. But we don’t live in a perfect world.

The challenge will be the time. Our time is limited so we have to prioritize. We need to define which skills we have to develop to reach level 5 and which skills we can develop only to reach level 2 or 3, at least for time being.

To pass CCIE Routing & Switching lab, for example, you must possess level 5 of core knowledge such as IGP Routing, BGP, MPLS. They are defined as core knowledge due to the amount of exam questions about the topic, and in the lab that technology is the foundation that put everything together. You can’t build a working solution if you are unable to make the core technology works. You may reach only level 3 for QoS or security, and still able to pass the exam since they are not the core knowledge.

But how we define target performance level for NFV Solutions Architect?
My advise is to start from the top. NFV solution comes from the business (top) to the physical implementation (bottom).

Solutions Architect must be proficient with the top level: business requirement and strategy, and end to end solution architecture. You should target for level 5 on that. Then going down to the translation of the requirement into the technical solutions. Then going down to how the orchestration can manage multiple domains. Once you are good with all those, you can go down to virtualized infrastructure manager such as OpenStack. If you still have time, build capabilities on VNFs, hypervisor and host operating system. Then all the APIs and interfaces between components. Then programming language, and so on. Try to target the highest level on the top, and moderate level as you go down.

Nothing stopping you to pursue and master physical network knowledge first. But if you are really good in individual technical component, but can’t understand the business driver as well as the overall solution, then you are still at engineer level. A very good engineer perhaps, but not a Solutions Architect.

5. Use Tree Traversal for Development Planning

To give point 4 more concrete example, you may want to use Tree Traversal as I wrote in my previous post. It offers two different approach in visiting each node in a tree data structure:  Depth-first, go down first e.g. first child, then grandchild before second child, and Breadth-first, go across first e.g. first child, then second child before grandchildren.


Your decision to pick which approach, depends on your current situation. Perhaps you are in a work environment where everyone is expected to become a domain expert first, hence you may choose Depth-first. Or perhaps you are being supported to become a Solutions Architect and it is better to start by knowing the whole picture to begin with, then go with Breadth-first approach.

6.  Build Learning Path

How to build learning path for non-technical skills?
Indeed certain skills such as communication, leadership or connecting the dots usually comes with experience. But you can still equip yourself with some books or courses that teach foundation knowledge of those topics. And you don’t have to take MBA to understand the business, but it may help to look at the program curriculum and pursue the knowledge defined in it.

For technical skills, the path can be set by following certification program. Not everyone is a big fan of certification, but the program creator usually spent quite amount of time to define the level of expertise as well as the scope of each level, why not leveraging this instead of reinventing the wheel? And you don’t have to take the exam if you don’t want to, just follow the learning blueprint of the program. You can use Cisco certification for networking, RedHat or Linux Foundation for Linux OS, VMware for virtualization and hypervisor, Mirantis or RedHat for OpenStack and so on.

7. Get Feedback

When you are in process of learning something, it is important to get a feedback to measure your progress. The exam in certification program can be a feedback: if you pass it means you have reached the knowledge level as defined by its creator. Or you may want to get a feedback by getting involved into the discussion. Find out who is the domain expert and try to discuss with him or her to validate your assumption of what you think you already know. Or provide assistance for those who have just started to learn. Seek a feedback by teach the knowledge to others. It was Albert Einstein who said "If you can't explain it simply, you don't understand it well enough."

8. Remove Barriers to Knowledge

I’m just stating the obvious here, but please make sure you have all the access to learn the knowledge. From a simple Internet connection, training material, online library, whitepaper, books, to lab equipment to practice and allocated time and place to study, make sure you don’t have anything to stop you in learning.

9. Make Learning as Habit


In The Power of Habit, Charles Duhigg takes us to the thrilling edge of scientific discoveries that explain why habits exist, and how the right habits were crucial to the success of Olympic swimmer to CEO. There are many examples in the book of how implementing so-called keystone habits can earn billions and mean the difference between failure and success, life and death.

You have to make learning as your habit. And you can do that by starting it slowly, but be consistent. If you plan to spend at minimum an hour a day to learn something new, then do that and stick with it. Later you can increase the amount of time you want to allocate. Later, once it has become your habit, you will find that it is part of your daily routine and something you can’t skip.

10. Take Classroom Training

If you asked me 15 years ago if classroom training is necessary, my answer would be no. Why would you waste your time sitting inside the class, listening to someone who may know only how to teach, instead of doing the reading yourself and trying to apply the knowledge directly? I passed all my CCIE and CCDE exams with a very minimum number of trainings.

But if you ask me again now, my answer is: you may want to consider to go to classroom training. Not because you can’t learn by yourself, but the training can accelerate your learning and shorten the time required to understand the new knowledge. We are all busy so it is good to have someone helping in explaining complex subject to us. Just make sure the instructor is someone who has experience in applying the knowledge in real world, so you will get the knowledge not only the one from the training material.

Another reason is classroom training gives us break from our daily work. You are excused not to reply to your email immediately or to pick up the phone since it is in silence mode: you are inside the classroom listening to the instructor! Your boss or colleague or even customer can be informed in advance and usually they respect your training time and give some space.

11. Exploit Strengths, Manage Weaknesses

By now I believe you have already know what are your strengths and weaknesses. If communication is your strength point, exploit it. Put yourself as the key person to discuss with the customer to get the requirement. So even if technical skills are your weaknesses, you can manage them by delegating the technical tasks to the engineers.

It is important to emphasize that as Solutions Architect your strength point should be the one that is closer to the business on the top. This can cover your weakness at the bottom such as technical implementation, at least for the time being while you are developing the skills. So if you feel that technical detail is your only strength, while you really have to develop your business mindset and communication skills, exploit it by becoming Subject Matter Expert in some technical domains. You are not a Solutions Architect yet, not from the business people perspective, but at least you have a good value to contribute to the team and slowly you can develop the required skills to become one.

12. Believe That It Can Be Done

Last but not least, you have to believe you can achieve your goal. Your mind can play trick with you. Many have not even tried to pursue their goal because they don’t believe it can be done. Skill development plan is important, but what more important is the process in planning it. Start developing the plan and follow it. Achieve small success at a time. Believe it is possible as long as you continue to execute your plan.

Only by believing that he is the one, Neo is able to stop the bullet.



So start building your career strategy now using the points above as guidance. Then implement it with commitment, consistency and determination. Don’t forget to have fun during the process.

Good luck.

“We must learn how to be the CEO of our own careers"
-- Peter Drucker

Thursday, March 05, 2015

SDN, NFV and Skill Development for Network Engineers

I came to Cisco Brussels 14 years ago to take my first CCIE lab. I didn’t pass that time. I went to Tokyo a month later and got my number there. Several years later I kept coming back to Brussels to pass my two other CCIEs.


Many people say there is no value anymore in taking CCIE these days. With SDN and NFV, everything will be done "auto-magically". We don’t even need network engineers anymore! Yeah, right. Last week I went back in Brussels to work on Network Control System, multi-vendor network device management tool from Tail-F that was acquired by Cisco June last year. NCS is the cornerstone of Cisco Network Service Orchestration framework for Cisco SDN and NFV solution offering. And I’m here to tell you that the world still need lots of network engineers, and CCIEs, or those who have CCIE-level skill set.

But first, let me talk more about NCS, a service orchestration for real-time service provisioning across multivendor networks.

Network devices were, and are still, configured using CLI. Then SNMP was created to help. Soon, we realized SNMP is great to monitor the network but it fails to become configuration management, as stated by RFC 3535. So more than 70% networks today are still managed by CLI. Arista Networks CEO Jayshree Ullal once said “it’s the way real men build real networks today.” And when we need automation, we create script to send sequential CLI command to devices.


When we use CLI, or Web interface, or SNMP, or send the command over REST API or Netconf to the device directly, this is called Stove Pipe approach. Tail-F NCS puts itself in the middle of the communication between all those protocols with the network devices or Managed Objects (MO). Think its function as mechanism to “normalize” devices configuration into one standard data model then push that configuration into devices using one standard protocol. NCS supports multiprotocol and multivendor by design.

NCS uses YANG, a data modeling language that represents data structures in Extensible Markup Language (XML) tree format. The data modeling language can be used to model both configuration data as well as state data of network devices. YANG can be used to define the format of event notifications emitted by network devices and it allows us to define the signature of remote procedure calls that can be invoked on network devices via the Netconf protocol. Network Configuration Protocol (Netconf) provides mechanisms to install, manipulate, and delete the configuration of network devices. Its operations are realized on top of a simple remote procedure call (RPC) layer. YANG was published by IETF as RFC 6020, and Netconf was published as RFC 4741 and later revised and published as RFC 6241.


In short: The Netconf protocol allows a manager to set configuration, query configuration and state and execute actions on the device (much like SNMP). The YANG models describe everything there is to configure, monitor, admin actions, notifications for each device type and version (much like a MIB).

Many network management tools are misleading since they are actually only device management. What we really need is a service management. When we want to enable service, let’s say MPLS L3VPN, we may have to configure multiple devices. So it’s a network wide transactions based tool that we need. NCS acts as central repository to store network services logically using YANG data model for data structure. The structure represents service instance, and network configuration and state. It then maps between service operation to network configuration changes. NCS has transactional integrity. The service configuration is pushed using Netconf to all relevant network devices as one transaction. So it has to be successful in all, or nothing at all. If one device is failed to accept the configuration change, then all devices must be rolled back to its previous state. And there is no internal order inside a transaction, it is a set of changes, not a sequence. And any parallel transactions do not interfere with each other.


So what’s the relationship between NCS and SDN/NFV?

Cisco has been talking about Evolved Services Platform (ESP), that uses software-defined networking (SDN), Network Functions Virtualization (NFV), Open APIs, and advanced orchestration capabilities to forge a flexible and modular platform. With the Cisco ESP, and the physical and virtual infrastructure service delivery capabilities of the Cisco Evolved Programmable Network (EPN), service providers can quickly deploy new personalized offerings through integrated services modules. Imagine offering prepackaged tiers of enterprise services with default features, security, and service-level agreements (SLAs), that customers can select from an online portal and activate with a click of a mouse.


So the network operator can create a catalog of customized service offers that they make available through the active service catalog. The operator uses the business logic of the network service and resource orchestration modules to start up the virtual machines, activate the Virtualized Network Functions (VNFs), and dynamically create the specific service function chain, which creates appropriate linkages that support the service profile and steer the customer traffic through them. That is the idea behind Virtualized Managed Services solution, Cisco ESP services modules that may be deployed today.

And NCS plays important role as the Orchestration Engine in the solution.

Skill Development for Network Engineers

With the long explanation above, if you are a network engineer, what should you do now? What should you learn? How to develop skills to be able to work with the new networking paradigm like SDN and NFV?

As I wrote in my last blog post, someone needs to translate business requirement into technical requirement. That someone needs to understand business language as well as the technical solutions. Then the same person or someone else needs to create end-to-end architecture just like Virtualized Managed Services. Another person needs to design the service profile and create service catalog. Tool like NCS still requires input from someone to make those services into YANG model. And even if all physical and virtual infrastructure will be provisioned and managed using tool, we still need people who are proficient with network, compute, storage as well as various virtualized network functions. There are still many network protocols today such as OSPF, ISIS, BGP, overlay like MPLS or IPSec tunnel, that will continue to be used in the solution. So you still need to know networking technology in details. We still need many network engineers.

Any SDN/NFV solution and implementation will have so many components connected to each other using different types of API. There are lots of moving parts. Lots of complexity. We still need CCIEs, or rather those who possess CCIE skill set to handle the complexity. Then they have to adapt and to learn something beyond networking.

We need those who want to go up, to get closer to the business, and those who want to have the wide and broad knowledge beyond networking: hypervisor, OS, programming logic, scripting, API and so on. Dave Tucker suggested the transition from NetOps to DevOps, and he would predict that the Network DevOps engineer will need:
  • Strong Networking Skills
  • Knowledge of Linux System Administration
  • Experience with Puppet/Chef/Ansible/CFEngine/SaltStack would be desirable
  • Scripting skills in Bash, PHP, Ruby or Python
  • Ability to work under Source Control (git)
  • Experience in consuming (REST) APIs
  • Experience with OpenStack and OpenStack Networking
  • Appreciation of Software Defined Networking (SDN)
  • Knowledge of Agile Methodologies
  • Knowledge of Test-Driven Development
  • Ability to write Unit and Integration Tests
With so many things to learn, where and how to start?


Introduce tree-traversal. It is a form of graph traversal and refers to the process of visiting each node in a tree data structure in a systematic way. Basically in the example above there are two ways to traverse a tree: Depth-first, go down first e.g. first child, then grandchild before second child, and Breadth-first, go across first e.g. first child, then second child before grandchildren.


Let’s look at my tree-traversal above. I used Depth-first approach. So I spent my time to learn Networking technology first, in Routing & Switching, then Service Provider and Security. Then I spent time to learn Compute with various Linux OS distributions. And these days I put my focus on SDN/NFV technology from Cloud, Virtualization and network programmability.

So which way is the best for you? It depends.

You may go with Depth-first like me: learn networking until CCIE level, then go deep with Linux, before moving to scripting, API, orchestration and so on. Or you may go with Breadth-first: learning networking to mid level, then switch to Linux, then try scripting a bit, then get some hands on with OpenStack, then coming back to learn networking in more detail, Linux in more detail, and so on. Both ways have pros and cons.

And you may use certification program to help you to learn. For networking, Cisco certification program is still the gold standard. For linux OS you may go with RedHat or Linux Foundation. Even OpenStack has certification program from company like Mirantis or RedHat.

If you do use certification program to learn, please remember one thing: in learning, process matters. At work, obviously outcome or result matters. But when you learn something, don’t focus on the outcome or to get the certification, but focus on the process to gain the knowledge. So you will always be ready to learn any new skills and technology.

And that, I believe, is the only way to become the next generation network engineers.

So stop reading now. And start planning for your skill development.
Good luck.

“Plans are nothing; planning is everything.”
-- Dwight D. Eisenhower

Tuesday, October 07, 2014

Go Up or Go Wide

You say, the world doesn't need CCIE anymore with the raise of SDN. I say, we still need CCIE, but those who can adapt. You say, my words are just futile last ditch effort to show the importance of CCIE certification. I say, even I still work for Cisco but I don't work for CCIE program, and I get paid not because of my certifications.

If we have data, let's look at data. If all we have are opinions, let's go with mine
(Jim Barksdale, former CEO of Netscape )

So let's look at the data to make the discussion more fruitful. If you look at Cisco revenue of each product line for the past 5 years, we see there is decline for NGN Routing and Switching business. And yes, Data Center business is growing in fast rate. And Data Center business includes unified computing, next generation fabric, cloud and most Cisco SDN solutions that are available today.


However, if you do a simple math you can see the combined revenue of Routing & Switching business is still close to half Cisco revenue as of today. We are talking about more than 20 billion USD business. It's declining indeed, but it will take number of years for Data Center business with the same growth rate to reach the same size of revenue.

And below is the revenue comparison between product vs. service.


It shows that the hardware business is declining, but the service business is increasing in size. It can be interpreted freely as there is still demand for those who are able to deliver service. It means as long as you the network engineers don't lock yourself in to particular product, you should be fine. Don't become a product admin but try to really understand the technology. Learn deep about how protocols work not only how to enable the feature.

So I say, if you are still interested to work in computer networking, you can continue pursuing CCIE to gain the skillset. Long gone those days when CCIE gets paid only just because of being certified. You need to be in the right company, you need to be in the right position. You need to be relevant to company's business.

But the requirement for network programmability, virtualization and overlay is real. Those are what SDN has promised even though we are still yet to see the mass implementation of it. Company like Cisco has released its own SDN solution with Application Centric Infrastructure (ACI) and it requires different type of skillset to understand and implement it.

We, as network engineers, must evolve. We, as CCIE, must adapt.

So my message to all CCIE out there: the time has come for you to choose.
Either to go "up" or to go "wide".

We are all here in this field to support company's business. The promise of SDN model is to create abstraction layer to hide the complexity. There is a growing need for customers to put main focus to their core business activities, and let the SDN solution to deal with how to provision and to run the networking infrastructure. There is a dream in the future where customers can just describe their business requirement and what they need from the infrastructure, and let the SDN controller to automatically re-program all the network elements to answer the requirement.

But someone must translate that business requirement into technical requirement. That someone needs to understand business language as well as the technical solutions. That someone has to show the tangible outcome like Capex and Opex reduction that any SDN solution can offer to the business. That someone must be familiar with PERL - performance, efficiency, risk, liquidity of the company, at the same time at least understand the position of PERL language within SDN big picture.

That's go up.

These days I work with several "Cisco" Solutions Architects who posses different type of skillset. Some of them are not even certified in CCNA. They know very little about IGP, BGP and MPLS, but very proficient with hypervisor, OS, scripting, API and SDK. They speak Scrum. They are object oriented type of persons. They always see the overlay and virtual layer while most people still see the physical infrastructure.

Their type of skillset is still incomplete. CCIE type of skillset is far from complete either. Don't expect one type of skillset to dominate the workforce of the future. But imagine the next generation network engineers who possess both types of skillset.

That's go wide.

Possess CCIE skillset only is indeed no longer sufficient. Know only how to pass CCIE exam is even very less useful these days.

Go up or go wide is not similar with red pill - blue pill options. Both options are red pill. Both options are real.

Welcome to the new reality in computer networking.


Disclaimer: Cisco revenue is being used here due to its position as the market leader in computer networking industry. And all the information to make the graphs above is available publicly in Cisco annual financial report. You are more than welcome to analyze other vendor's revenue if you wish.

Friday, September 19, 2014

Some New Old Books


The Lean Startup approach is for companies that want to be more capital efficient and that leverage human creativity more effectively.  It relies on “validated learning,” rapid scientific experimentation, as well as a number of counter-intuitive practices that shorten product development cycles, measure actual progress without resorting to vanity metrics, and learn what customers really want. It enables a company to shift directions with agility, altering plans inch by inch, minute by minute.

The products lean startup builds are really experiments: the learning about how to build a sustainable business is the outcome of those experiments. That information is much more important, because it can influence and reshape the next set of ideas. And it uses the Build-Measure-Learn feedback loop at the core of Lean Startup model.



In short: build Minimum Viable Product (MVP) or Minimum Viable Service (MVS), launch, collect data to learn in order to perfect the ideas. Or if it doesn't work, fail fast, and pivot to another ideas.

Rather than wasting time creating elaborate plans for new product, it's better to launch quickly and find a way to test the idea continuously, to adapt and adjust before it’s too late.

How to decide which ideas to develop first?



In Four Steps to the Epiphany, Steven Blank offers the practical and proven four-step Customer Development process for search and offers insight into what makes some startups successful.

Rather than blindly execute a plan, The Four Steps helps uncover flaws in product and business plans and correct them before they become costly. Rapid iteration, customer feedback, testing your assumptions are all explained in this book.



What will be the next step if we want to use lean principle to launch new product/service?
We still need to create a plan. But don't waste time in creating plan.

Business Model Generation explains the most common Business Model patterns, based on concepts from leading business thinkers, and can help us reinterpret them for our own context. We can learn how to systematically understand, design, and implement a game-changing business model--or analyze and renovate an old one. Along the way, it will make us understand at a much deeper level our customers, distribution channels, partners, revenue streams, costs, and our core value proposition.


Business Model Generation advises us to use "Business Model Canvas" to analyze quickly any product/service we want to build. We can even use a modified model which is the "Lean Canvas" that is closer to the lean startup principle.



Each of us just need to spend few minutes to learn about the Lean Canvas model in order to use it.

Ideas are cheap. Execution is everything.
Think, build, launch. Get feedback, iterate, update. Repeat.

Tuesday, July 22, 2014

Six Phases of Network Evolution


Last month I was asked to speak about Next Generation Networks at Indonesian Network Operators Group (IDNOG) forum. Whenever I speak about this subject with my customers, I usually use top down approach: started by talking about the business drivers and requirements, NGN architecture, to high level and low level design, before going deep into details to each supporting technology.

This time I decided to take a different approach. Instead, I tried to demonstrate how to build a new SP network from bottom to up. The objective is to show how the network can be transitioned from the simple one that offers a single service, to the one that carry multiple services and become resilient Next Generation Networks. I don't know if the message was received by the attendees, but I run out my 30 minutes time so I continued that effort by conducting the webex session few weeks ago.


The presentation I made for that session inspires me to write down about the six phases of network evolution below. And the phase will end up with the one thing that has become hot topic these days: Software Defined Network (SDN).

Phase 1: It begins with connectivity
When we build the network from ground up, the first and most important thing to focus is all about connectivity. Site A can connect to site B. User can access the server. This means we need to build the physical topology, enable layer 2 and L3 routing protocols (IGP, BGP) to provide connectivity. And it is common to deliver only single service (Internet/data) on global routing table.

Phase 2: Converged network and multi-services
Then comes the next requirement to use the same network to deliver multiple services. MPLS is definitely the protocol of choice by industry to provide overlay in the network, even other tunneling protocols can still be used as long as the objective is achieved. The network now must be able to provide L3VPN and L2VPN services over MPLS, High speed Internet, voice over IP, IPTV for both multicast stream and unicast video on demand, even mobile services and multimedia. Convergence happens in access layer too: one IP MPLS network to carry different types of last-mile access networks technology.

Phase 3: Scalability
When we have big number of users accessing multiple services, especially for Service Provider, scalability factor becomes important. Nowadays we use IGP routing protocol only to connect between SP routers while the customer networks are carried using BGP. IGP must be fine tuned and link-state protocol area design must be done properly to make it scalable. BGP RR design becomes crucial when the number of BGP speakers is high. Multiple BGP AS must be able to work between each other to carry the services seamlessly. Even the design of every part of the network need to be unified and consistent in order to make it easier to scale up.

Phase 4: Services level differentiation
QoS will kick in when there is congestion in the network. When there is no congestion, QoS is applied to limit the service in order to differentiate service level provided to end user. QoS implementation in Service Provider network is obviously different with Enterprise network. In SP it's common to share network infrastructure that spread across the nation connected with WAN links, with potential of network congestion, to serve big number of users trying to access multiple services. QoS makes sense to be applied to prioritize certain type of traffic, or to charge the customer differently depending on the agreed service level. In Enterprise network such as LAN campus network or data center, it is already considered low latency network with sufficient bandwidth pipe hence the QoS implementation focus is most likely on the WAN link.


Phase 5: High availability and resiliency
The target for HA and resiliency in the network depends on how much we can tolerate services unavailability. Some customers can afford network downtime for days while others can only tolerate fraction of seconds. Some applications can continue to work, or to resume immediately, when it gets disconnected for more than few seconds while some others can show serious disruption when the network is down within miliseconds. So we need to look at high availability and resiliency from end to end perspective. Physical topology redundancy is good but may not be enough. Link down or network node down detection becomes crucial. IGP can be fined tune to react below 500 ms. Hardware availability combined with NSF, NSR and GR may be able to provide 0 packet drop during route-processor failover. BGP fast convergence is done in forwarding plane, even in control plane it still relies on IGP convergence. Multicast streams can be active-active and in parallel using path diversity to provide always-on IPTV service. MPLS TE and IP FRR may be used to achieve sub-50 ms while waiting for the IGP to fully converged, in exchange of more complexity in the network. And infrastructure security is another factor to consider to ensure network availability.

Phase 6: Manageability, agility and efficiency
"Simplicity is the prerequisite for reliability". In order to provide reliable services it should be simple enough to run the network. Some believe if network management works as expected we won't even talk much about SDN. The fact that the network today has become very complex to manage, even with various management tools available in the market, makes many of us are looking for the solution that seems to be promised by SDN. We still need to run lots of management protocol like SNMP and RMON. We still need to secure management channel through SSH or other encrypted channel. But now we want the network to be agile to adopt to the changes that come from lots of new applications. We need to be able to provision new services quicker. We are talking more and more about automation and network programmability. We want the network to be efficient. We want to hide all the complexity that happens in the network to make it efficient for the operator to run and manage it. And SDN may be able to do so by providing the abstraction to provide the simplicity to run the network.



In the end, with the amount of complexity built up when the network transforms from one phase to the other as above, it's clear why SDN looks promising. It's easier now to understand why people believe SDN is the answer.
Because it's simply the part of the network evolution.

Friday, May 02, 2014

The New Cool


I thought it was cool to be an MCSE.

The year was 1999. I didn't have any background in IT. I had just graduated and got my degree in Mechanical Engineering, and was struggling to get a job in that field. That's why I switched to IT, and the first thing I learned (FYI my previous computer skills were Warcraft and Doom) was Windows NT server and workstation. For someone without any IT background, Windows NT looked very interesting at that time! So I thought it was cool to be an MCSE, until I attended a CCNA course.

I thought it was cool to be a Network Engineer.

I felt in love to computer networking since the first day of CCNA training. I loved every moment during the 10-day course and in the last day I passed the CCNA exam. There were not many CCNA around during that time, so the certification landed me my first real job as network engineer early 2000. I thought OSPF was so cool, IGP redistribution was amazing, and BGP policy between different AS was an art. And I thought it was cool to be the guy who managed and monitored the corporate network, received customer calls and performed troubleshooting tasks almost every day, until I heard something about CCIE.

I thought it was cool to be a CCIE.

The company was crazy about CCIE. They spent lots of money to get the engineers certified. They sent several senior network engineers abroad just to take a complete CCIE training package. CCIE was the target for everyone. At that time I couldn't even imagine how difficult it is to pass CCIE, but I wanted to be one. I thought it was cool to be among the first who pass CCIE. Even I didn't get any training. Even I had to sleep at office and spent my nights studying. So then I passed one certification at a time, from CCDA to CCNP and CCDP. Until I passed the written test. I went for my first CCIE lab attempt in Brussels on August 2001. I failed. Then I passed in Tokyo a month later.

At that time, having CCIE made me the special one in the company. And it's eventually landed me a job with Cisco gold partner in Dubai early 2002. Without any interview. Not even a phone interview. The company sent the offering letter over email, and asked me to come immediately once I got my working permit. How cool was that?


I thought it was cool to be a security expert.

Working in system integration company made me realize CCIE skill set is not enough. Even the company was a Cisco partner but we used to have projects where we have to deliver end-to-end system from network, servers, desktops, security, wireless and telephony. So I learned Unix/Linux and took Sun Solaris certification. I went deep with wireless using Planet3 certification and I used to perform wardriving on Dubai streets. I got more and more interested with network security. Not only I took several certifications like CCSP, CEH, CISSP and the one from Checkpoint and SANS, I also set up a home lab with all security tools and honeypots. I did lots of security projects, and I even helped customers to response for security incidents. It felt cool to know something most people don't know. It felt cool to be called a security expert by customers. Until the day I found out some students I caught hacking their university server, were expelled. I thought it was just a curiosity game, for someone like me or for those students. When things got serious and impacted people's life and future, I felt that it was not the right game for me. So I stopped pursuing career in security.

I thought it was cool to have multiple CCIEs.

It was 2005 and those who have multiple CCIEs lived like kings. People hailed them in Internet forum. Their profiles were shown everywhere. They were called the geek in computer networking industry. I wanted to be one. I thought if having multiple CCIEs was special, it may even land me a job in Cisco. So I spent my personal saving to build CCIE Security lab. I didn't want to continue working in security, but looking at my background that track was the closest. At the same time I grew interest in MPLS so I learned it with CCIP. It took me about 6 months and two lab attempts to become a Double CCIE. I was happy and confident my future would be bright. I was one of 600 multiple CCIEs out there. Joining Cisco would be like walking to the main door and getting the offering letter from the reception.

But, I didn't even get a chance for a job interview with Cisco.
I learned that skills and experience alone was not enough. Nor the reputation built over the years and track records of successful project. I left my job in Cisco partner, to comply with Cisco policy not to hire from the partners, but I didn't manage to get even a phone interview. I still needed the network. The human network. The connection. At the end one of my connections in Cisco put my CV through internal reference system. And after years of waiting finally I got in. In 2006 I joined Cisco Advanced Services APAC in Singapore. I still had to use my skills and experience to pass tough interview process, but the first fight was to get noticed.


I thought it was cool to be Cisco Consulting Engineer. I thought it was cool to work anytime, anywhere. I thought it was cool to travel the world.

When I was in partner, I had a chance to work with Cisco AS Consulting Engineers in several projects. I was impressed with the way they delivered the work. I was amazed with the depth of their knowledge. Not only they know how to configure and troubleshoot the network like a CCIE, they also went very deep with the design, the protocols and hardware architecture. And some of them were not even CCIE. So becoming part of Cisco AS was the new cool for me. And I think it's still cool. Who doesn't want to work from the cafe, airport or even the side of hotel swimming pool? Who doesn't want to travel the globe to work with Cisco's large SP and enterprise customers? I like the feeling when I was leading complex migration projects in Malaysia, Vietnam and KSA. I felt accomplished when I was able to help the customers to transform their network. But other Consulting Engineers around me did pretty much the same. As much as I like to work anytime, anywhere, and to travel the world, these are no longer cool to me. They have become a norm. Daily activity.

Once again I used my connections, skills and reputations to try to move to a global team. I felt that I wanted more exposure. More challenges. I wanted to feel cool again. And after a tough interview process (yes, there is interview process even to move internally within Cisco), I managed to get into an NGN global team in 2008. I moved back to Dubai. The team filled up with senior Solutions Architects, they made me feel like the least experience in the team even I had my third CCIE in SP. We did many large scale and complex projects across EMEA together.

I thought it was cool to be a Cisco Solutions Architect. I thought it was cool to be a global consultant. I thought it was cool to provide solution architecture and technical design to answer customer's requirements and problems.

I still like to be a Cisco Solutions Architect. I still like to be a global consultant. I still like to meet the customers to provide solution architecture and technical design to answer their requirements and problems. But I've been doing that for many years.


I like to redesign the whole network architecture for customer in Middle East. I like to design and transform the MPLS backbone for mobile operator in Africa. I like to create architecture blueprint, or build IPv6 strategy for customer in Europe. I like to discuss more about the new SDN, virtualization, network programming and Internet of Everything. But these days I want to have more business-oriented discussion. I like to understand more about customer's business challenges. I like to have more meeting with business leaders from the customer. And this is inline with my MBA study.

I think it's still cool to continue presenting at Cisco Live. 

I still like to meet customers and present a technical session at Cisco Live. I still like to talk about CCIE and CCDE during the event.

I think it's still cool see my name on Ciscopress book someday.
 
I would like to spend some time to write technical book, but it looks like the time has come for me to make a choice.

I think it's still cool if someday I can become a distinguished engineer in Cisco. I think it's still cool to get Cisco Certified Architect certification.

But at the same time I think it's cool to try to make impact. It's cool to try to transform Indonesian students and young professionals to become globally competitive professionals. Even if I can only transform one person at a time.

I think it's cool to be a 50preneur while still working for Cisco. I think it's cool to build my own organization. To set the vision and goals. To hire people to execute them. Until one day I become a full-time entrepreneur.

And I also think it's cool to be able to spend more time with family. I think it's cool to be able to play snowboarding together with my daughter. It's cool to teach math to my other kids. I think it's cool to drop the kids to school every morning, then to have breakfast with my wife at beachfront cafe, before I start working from home.

So those are my new cool. What's yours?