In this post I’d like to share my opinion about SDN. This is very interesting and fashion topic which growth in popularity with each day. What it is in the reality? Let’s clarify it together.
Disclaimer
This article is written under deep impression of the new O’Relly book «MPLS in the SDN Era» authored by Antonio “Ato” Sánchez-Monge and Krzysztof Grzegorz Szarkowicz. These two guys work at Juniper but the book is vendor agnostic. It’s about MPLS in the current and future world, and about interoperability between Cisco and Juniper.
SDN isn’t only about OpenFlow
SDN launched with the idea to have a centralized controller, may be redundant, that controls all the network devices to provision a path for the traffic flow between sender and receiver. It stated that network devices can be very silly and therefore cheap. I remember somewhere in 2013 I saw the presentation of SDN solution by NEC. They described the advantages of their solution focusing on TCO (Total Cost of Ownership) reduction for the network as well as decreasing time to the market.
Well, with the second key pillar I agree. At that time the company, where I worked, didn’t have the provisioning system and all the news services had to be configured per CLI. It was just the case of that certain company, but it was obvious that provisioning system could incredibly speed up the launch of new services.
But the first idea about TCO reduction was just nonsense. What is actually TCO? It’s all expenses related to your system. It has CAPEX (capital expenses) and OPEX (operational expenses) parts. CAPEX is actually the costs of the network equipment, its installation, licenses and so on. OPEX is support, maintenance and operation of the system. So TCO reduction in SDN is achieved due to decreasing the CAPEX and a little bit OPEX. It might sounds well if you build the network just from the beginning without need to integrate it with something. If you have a built network and you are looking for the opportunities to reduce OPEX, SDN isn’t for you. Even if you want to upgrade part of your network, at that time it was too difficult to integrate OpenFlow with existing network protocols if even possible.
Long time for me it wasn’t clear why SDN is so popular and its popularity increases. Let’s search “SDN” at the working market in the Germany.
It’s quite popular, isn’t it? But since I’ve started to read this book, it’s clear now.
What is SDN about?
In their book guys cover the core idea for SDN very well. It’s actually about abstraction and automation. If we take a look in the abbreviation of SDN itself, it stands for Software-Defined Network. It means that the network controller defines the path for the traffic flow based on the parameters of the flow. The network controller has a full visibility into network therefore there can be no loops. Sounds good, isn’t it? So the idea is to make provisioning for the traffic flow automatically (automation) and based on the full vision of the network (abstraction).
If we speak about new datacenter, it might be true. We can build redundant controllers and connect the cheap dummy switches to them via out-of-band (OOB) network. But the enterprise network or service provider network is much larger then a couple of rooms. Moreover due to geographical distribution the new questions arise. How is it about reliability of connectivity to controller or just response time of the controller, if it’s located in thousands of kilometers away? It’s just dangerous to make the centralization.
One of the jokes or myths that are related to the development of the Internet and IP protocol in general says that Internet was developed with the idea to survive even during nuclear attack. Such degree of survival is possible only in highly distributed environment, like IP with routing protocols and/or MPLS, where each node can independently make best decision based on available routing information.
SDN and MPLS
In MPLS we already have all the necessary capabilities. LDP label distribution and traffic forwarding based on LDP labels provides us possibility to use full power of highly redundant network taking proper action in failure scenarios. RSVP-TE adds possibility to predict end-to-end path for traffic flow as well as pre-provision load-sharing or redundant paths. BGP and LDP provide possibility to transfer any traffic (L2/L3) over MPLS cloud taking into consideration flows parameters. So I’m fully agree with authors that MPLS is just ready platform for SDN that can be further developed.
Lessons learned
Sometimes the most obvious things are very difficult to spot. Making labs from this book has helped to deeper understand how different technologies and vendors can interoperate.
Conclusions
Though I’ve just started to read this book a couple of days ago, it has just opened me eyes and helped to clarify many things about SDN and MPLS. Though I’m already CCIE RS with this book I’ll definitely start my way to CCIE SP. Thank you guys!