RFC 1925 as one of the major Network evolution drivers

Last couple of years I was wondering in which direction the world of networking is going. I am a network engineer and I was not sure what path the network industry will follow. The only thing I truly believed were the 12 networking truths expressed in RFC 1925.

I was wondering what way to follow. All those battles like CISCO vs Juniper, Nokia and Siemens vs Ericsson (all surprised from behind by companies like Huawei) were looking somehow a bit wrong from my perspective. The world of ISPs and Telecoms was trying to respond to the needs of the society with more and more complexity and that was going to a wrong direction .

My personal decision was to move from the networking to the software industry. So I moved from a typical network integrator to a software company dealing with OSS/BSS. It looked like the OSS/BSS was the right answer. Basically a single properly designed Fulfillment solution might overtake the jobs of an army of CCIEs engineers.  However after some years in that industry I have realized that the fulfillment by itself is not sufficient to evolve the network. Fulfillment was always behind it. All the projects were quite complex with quite a lot of hardcodes and once done and delivered -> the major principle was please do not touch them. Every change costs quite a lot and therefore all the time the OSS/BSS software was  lagging behind the network.

It might be one of the reasons why the large telecoms and ISPs somehow missed the service part of the game and lost the battle for  service from the Internet companies like google, facebook, skype and others. Basically Internet players were much more flexible than the telecoms with their large and clumsy combination of networks + OSS/BSS.

However as a result of that some of the complexity has shifted from the telecom and ISP industry to the infrastructure of the Internet companies. Currently some of them have the largest IP network infrastructures including internal and external network, peering, connectivity services and data centers. The solution was to try to simplify the setup and as a result the ideas expressed by Urs Hölzle in books like “The Datacenter as a Computer: An Introduction to the Design of Warehouse-Scale Machines” flourished into the cloud. So in the end the complexity of the network offering went from the typical network players to the cloud. In order to achieve a scalable cloud offerings the Internet players had to simplify the network and as a result appeared SDN.

The idea of SDN is quite simple. You got a dump network devices working on L2 and outsourcing the forwarding plane building process to an external software controller.
The realization hmm. It looks like quite difficult to build a scalable distributed controller able to handle all that traffic. However let’s say that this is not a problem and sooner or later such a controller will be a fact. However the simplification of the cloud network infrastructure again results to a complication of the cloud offering itself. People stopped to instantiate VMs manually and now there is a bunch of cloud orchestration engines able to automate and fulfill the cloud service delivery. The question is what will happen next?

The answer is that the offering will be simplified and the complexity will shift again in quite different direction. There will be millions of billions of intelligent network devices hungry to communicate with the cloud and that won’t be that simple.

The evolution of the network and the society is a never ending process. There might be a need of software able to capture and track that process ;) and that is something I would be happy to do.

The context is quite clear. The major stakeholders not really. However definitely some of the major players will be the internet companies, the governments and as an ecosystem we will have the society itself. For the functional requirements and quality attributes I would say that RFC 1925 will be still valid :) The rest of the architecture drivers will appear as a result of combination of chaos and some architectural thinking.

Nikolay Milovanov

 

This entry was posted in Uncategorized and tagged , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *


two + = 11