10 pragmatic ideas about SDN/NFV
After some months learning about SDN and NFV topics I have been composing some ideas in my mind I would like to share with you.
This month I attended to two interesting events. First, in Madrid, where I participated on the Autlesi Forum about SDN and NFV, sharing experiences among Service Providers, Manufacters and End Users. And just this week I enjoyed a really interesting 2-day workshop by Ivan Pepelnjak, and some coffee breaks with experienced network engineers. All this together, with my own background, bring some basic concepts which, I believe, should be taken into account to understand SDN and NFV on a pragmatic way.
1 - Technology is a tool not the goal, you should start understanding "what" do you want to solve and "why" before starting working on apply whatever new hype technology. This has a lot of sense but sometimes you put it out of your priority list.
2 - SDN is not only OpenFlow, SDN is about abstraction, putting intelligence into your network, so the idea is something like creating an orchestrator which knowing what happens and what should be happening on the network can modify it automatically. To get there you have to change the way you see your network, you shoud simplify everything to standarise and automate network processes and finally, get the holy grial of abstraction.
3 - There is not an unique SDN architecture, from a complete separation between the data and forwarding plane to partial approaches (leaving some intelligence inside the boxes), and independently of your prefered approach, try to avoid reinventing the wheel every time and learn from what 30-years of networking history shows us to make a actual reliable SDN network.
4 - Today we have many tools to improve our network operation towards an easy-configured network using reliable transactions (NETCONF, YANG) or, moving further to an easy-provisioned network to face large scale deployments where fast deployment, scalability and reliability is a must. Tools as Racnid, Git, Chef, Puppet, Ansible, Gerrit or Jenkins can help us to solve most of the challenges on network automation. Moreover, the arise of linux-based operating system opens the door for deployments of new applications inside network nodes. So don't be lazy and start applying them on your network! (first on test environments, please)
5 - Application development and systems and networking operation should be seen as a whole, all together make services up and running, so everybody is (should be) working on the same direction and with a common understanding on how the "processes" are executed to achieve the best result. This don't means that network engineers need to become programmers, but at least they should be able to thing like them to speak a common language and create an actual SDN network (although, some scripting skills should be necessary).
6 - Open your mind to consider well-known technologies as BGP capable of solving a lot of issues on current networks, using the traditional implementation or new functionalities as BGP FlowSpec (RFC 5575), L3VPN (RFC 4364), EVPN (RFC 7432) or BGP-LS. And, keep in mind, most of ToR switches support BGP! Regarding BGP let me mention an open source project, PMACCT, which is, basically, a network information collector which brings you the power to create most suitable inteligence for your network. Furthermore, also some issues with OpenFlow, as controller federation to scale-out architectures, could be solved using BGP between zones.
7 - Keep your core network simple (and reliable) and start innovating on the edge (where your services or users are connected). This approach brings you more advantages (and earlier) because it is easy to focus on small issues than bigger ones.
8 - NFV promises a lot of benefits regading delpoying and scaling capabilities but you should take into account several constraints solved today by HW appliances. Anyway, the market is moving on this way so a lot of new solutions are appearing every day. The performance of NFV solutions could present some doubts but is not usually an issue (you can get amazing performace over x86 customised NFV appliances!), but always check the feature parity between appliance and NFV solutions and the licensing terms to verify if it makes sense to you.
9 - NFV doesn't mean cheaper network functions because you are actually paying for the software (not the hardware) so this remains the same here. You have two options: buy something that works and has support (as you are currently doing) or do it yourself (only reasonable for enormous companies as Google, Facebook or Amazon). Likewise, deploying NFV relies on having a private or public cloud, an automated network and to bring traffic to these devices where they appear (not so easy).
10 - Please do not only read press headlines or vendor datasheets, dive into product documentation to understand how it works, which is its architecture, because then you can understand the actual limitations and specific operation aspects (time for a demo?). And, please, always start this time-consuming effort when you have your needs (and scope) clearly defined!
If you have reached this point you should be as much interested as me in this topic, so congrats to you! we are going to enjoy interesting coming years redefining networking!