Segment routing what the hell is this?


In the last couple of years the awareness that the network somehow become too complex is rising more and more. Somehow the “stupid network” described by David Isenberg’s [1] become complex again… So it is time to turn the wheel one more time and to try to reduce the network state that has to be maintained and to try to shift the complexity in yet another direction.

Let’s track the network evolution

Consider the fact that before the complexity has been shifted from the network to the terminals so as a result we got quite capable end hosts instead of a dull telephones.

The initial packet networks were designed to sustain to a nuclear blast and the major concern in designing their architecture was network survivability. Now the world of networking is moved by a bit different business concerns. Such are the ability to utilize fully each network link, client isolation on common network infrastructure, ability to resist on DDOS attacks, selective performance, selective high availability.

Each one of those is not that easy to be achieved on pure IP network infrastructure. Some of those are possible to be fulfilled in pure MPLS based infrastructure and almost any could be fulfilled in MPLS + MPLS based network infrastructure. However that comes with its cost and the cost is the ability to maintain more and more network state in more and more complex control plane. So here comes the question can’t we somehow reduce the complexity of the issue with maintaining so many control plane protocols.

The answer is that there is such – why not connect all the nodes in a network to a controller make them all speak a common protocol with it through an out of band channel and then just let’s play with the controller.

Software Defined Networking

Ready set and done -> You got the openflow and SDN (Software Defined Networking). The idea is not new it somehow looks similar to the one of the intelligent telephony network described by Isenberg. In that one the network is controlled by intelligent nodes through a common protocol – SS7 (Signaling System No7) and its extensions (TCAP, INAP, MAP and so on).

It is important to understand that the SDN comes with its impact to the network quality attributes. Obviously it will reduce the network state maintained by each of the network nodes and will reduce the cost for achieving qualities such as network utilization, isolation, DDOS resistance, QOS and selective high availability on a per flow basis. However this will come on a certain cost. The cost will be inhibiting  network survivability. Obviously there will be controllers that will have centralized control on the network state. The complexity of the current network will be shifted towards those nodes and it won’t be easy to make them high available, work with the required performance and able to resist on different kinds of network based attacks.

Most of us have sensed what happens with the telephony network on New Year or when there is a problem with the main telephony switch. Same will happen with the packet network.

Anyway what is Segment Routing

SR (Segment Routing) is currently (30.03.2013) described in an IETF draft. The draft is driven by CISCO systems and is supported by leading Telecom Companies. The nutshell is expressed in the draft itself.

Segment Routing (SR) enables any node to select any path (explicit or derived from IGPs SPT computations) for each of its traffic classes.The path does not depend on a hop-by-hop signaling technique (neither LDP nor RSVP). It only depends on a set of “segments” that are advertised by the IS-IS routing protocol. These segments act as topological sub-paths that can be combined together to form the desired path.

There are two forms of segments: node and adjacency. A node segment represents a path to a node. An adjacency segment represents a specific adjacency to a node. A node segment is typically a multi-hop path while an adjacency segment is a one-hop path. SR’s control-plane can be applied to IPv6 and MPLS dataplanes.

Segment Routing control-plane can be applied to the MPLS dataplane: a node segment to node N is instantiated in the MPLS dataplane as an LSP along the shortest-path (SPT) to the node. An adjacency segment is instantiated in the MPLS dataplane as a cross-connect entry pointing to a specific egress datalink.

As per its designers it clings to the network qualities by offering Scale and Simplicity.

– less protocols to operate
– less protocol interactions to troubleshoot
– avoid directed LDP sessions between core routers – deliver automated FRR for any topology

– avoid millions of labels in LDP database
– avoid millions of TE LSP’s in the network
– avoid millions of tunnels to configure

Segment Routing and SDN

The draft describes how SR brings some of the SDN qualities without the introduction of a centralized control point. However
at the same time both technologies could co-exist.

Some of the SDN requirements are:

  • Guarantees of Tight SLA’s (FRR and bandwidth admission control).
  • Efficient use of the network resources.
  • Very high scaling to support application-based transactions.

Segment Routing (SR) is a compelling architecture to support SDN for the following reasons.

  • SR supports a simple but efficient capacity planning process based on centralized optimization.
  • SR optimizes network resources by providing a very simple support for ECMP-based shortest-path flows.
  • SR provides for much better scaling than alternative solution: several orders of scaling gains have been illustrated in the simplicity and Capacity Planning sections.
  • SR provides for guaranteed-FRR for any topology.
  • SR provides for ultimate virtualization as the network does not contain any application state.The state is in the packet. It is encoded as a list of segments.
  • SR provides for very frequent transaction-based application as the network does not hold any state for the SR-encoded flows.

More for Segment routing

[1] Isenberg D., Rise of the Stupid Network

Posted in MPLS Core Networks, Network Architecture Evolution, NGN Backbone Networks | Tagged , , | 3 Comments

Clean state vs Evolutionary research?

Obviously the current IP networks and the Internet as an ecosystem integrating many other IP networks are far away from perfection. Obviously comes the question shall we try to redesign it avoiding all the mistakes that were done and start from scratch (clean state) or shall we gradually evolve it into something that better fits the need of the  surrounding socio-technial ecosystem (e.g evolutionary research and development).

I strongly vote for the second option. However in order to do it the network engineering community should have tools for capturing the network state and performing  architectural  analysis and comparisons of the differences between any two or more network states. This will allow us to reason about the evolutionary changes that happen to the network and will be a base for future network evolution. Obviously that’s not easy without software intensive tools and there are not so many tools for network evolution.

Here is a nice article of Jenifer Rexford and Constantine Dovrolis about shall we focus our efforts in designing a new network architectures or shall we focus on how to evolve the current one.


Posted in IPv4 to IPv6 network transformation, Network Architecture Evolution | Leave a comment

Something on global warming and climate change

Bryan Lovell, the President of the Geological Society of London discuss global warming in relationship to carbon emissions. He says that those who say, “We don’t know what happens when you pump several hundred gigatons of carbon into the atmosphere,” are wrong. We do know. “The rock record” shows an event 183 million years ago that gives us a benchmark for today. The planet warmed, the oceans turned acid, and there were many extinctions. These new findings, first published in 1999 and subsequently reconfirmed, give a clear model for what’s happening right now. The difference is only in the source of the carbon.

Posted in Uncategorized | Tagged , | Leave a comment

David Isenberg – “The Rise of the Stupid Network”

Let’s remember for David Isenberg.

Many years ago he wrote “The rise of the stupid network” explaining why when we have dump terminals the network shall be smart e.g “intelligent” and why when we have “clever” terminals like PCs, smartphones and tablets the network should be “dump”.

The original paper could be found here and a newer version here.

Mr. Isenberg wrote his pappers in 1998 reading it is not that difficult to understand why the so called “Inteligent Network” actually failed and why only a small portions of NGN (Next Generation Networks) and IMS (IP Multimedia Subsystem) actually worked in real business cases.

It is interesting also to relate this article to more modern network architecture evolution tendencies such as Context Aware Networks and standartization steps such as SDN (Software Defined Networking)  and ABNO (Application based Network Operations). SDN and ABNO in particular are trying to simplify network control plane through the introduction of inteligent network controllers on L2 for SDN and on L3 for ABNO and thus make most of the devices in the stupid network even more stupid than they were.

The ability to have an inteligent controllers that could be controlled by external applications through  a simplified northbound will have an interesting impact on network qualities such as reliablility, simplicity and performance.

Posted in Network Architecture Evolution, Remeber the Guy | Tagged , | Leave a comment

SOA in Action

“In software engineering, a service-oriented architecture (SOA) is a set of principles and methodologies for designing and developing software in the form of interoperable services. These services are well-defined business functionalities that are built as software components (discrete pieces of code and/or data structures) that can be reused for different purposes. SOA design principles are used during the phases of systems development and integration of many current software systems”. [wikipedia].

On 16.12.2012 from 11:20 till 12:50 in NBU building 2, as part of “Architecture for Software Systems” NBU course we will have a guest lecture – “SOA in Action”. As a lecturers we will have Dimitar Dimitrov (VP Technology & Innovation Platform) и Bogdan Vatkov (Development Architect Technology & Innovation Platform) from SAP Labs Bulgaria.

Please come prepared for the lecture and be able to participate in SOA based discussion. For the purpose you may focus on those two readings.

If you are not among my students  but would like to come to the lecture please let me know everybody is welcome.



Posted in Architectures for Software Systems | Tagged , , | Leave a comment


Posted in Uncategorized | Leave a comment

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


Posted in Uncategorized | Tagged , , , , | Leave a comment

Masters Program – Embedded Systems, NBU

I would like to present you something new and interesting – an early bird in Bulgarian IT Masters programs and one of the few that will really give students a chance to design and develop their own products in an unique and exciting environment once they graduate.

Last couple of years our society is having a wonderful transformation. From the era or PC’s and fixed dull electronic devices we are slowly but surely moving to the world of Internet of Things – billions of billions uniquely identifiable devices integrated in one common Internet like structure.

Now is common each one of us to have a few mobile phones and iPad or any other tablet an iPod or other music player an intelligent TV or why not an intelligent home. Won’t it be nice if our house is able to organize a party for us and to take care about the invitations for the guests, the list of foods and drinks and to handle all the preparation work. Now it might be not really possible but in a few years why not…

If you want to learn more about it and how to make it happen now is your chance.

New Bulgarian University is offering a Master’s program in Embedded systems one of the few such one in Bulgaria and the region. NBU will offer you  unique learning environment and professional approach for mastering the discipline of embedded system’s engineering.
The program is led by Dr. Zdravko Karakehaiov a well known figure in the field. The program will offer classes in the following fields:

  • Embedded computing
  • Digital design
  • Hardware platforms
  • Embedded software
  • Real-time systems
  • Algorithms for embedded systems
  • Embedded systems design Cognitive systems Wireless sensor networks Low-power design
  • Control theory
  • Control algorithms
  • Hardware and software co-design Re-programmable systems Embedded systems security Distributed systems and computer communications
  • Digital signal processing
  • Dependable systems

I will also personally support the program by lecturing two of the Carnegie Mellon Courses as part of it.

  • Architectures for software systems I, Carnegie Mellon
  • Architectures for software systems II, Carnegie Mellon

Each of the courses will be combined also with a self study in which you and your colleagues will have to form a studio team and develop a real project.

Embedded systems Master’s program flyer

Architectures for software systems course description


Nikolay Milovanov


Posted in IPv4 to IPv6 network transformation, IT sector in Bulgaria | Tagged , , , | Leave a comment


This year I got plenty of travelings. After my visit to the USA and Carnegie Mellon University I had a chance to meet with colleagues and customers in UK&Ireland.
I had a chance to make some photos in Dublin and Portsmouth. Also spent some time in London and Cambridge. On the way back even had a wonderful evening with friends in Frankfurt.

Fingers crossed that one will be the final journey for this year and hopefully next one I will have more time to spent with my family instead of on business trips.

Have a look on some of the photos I made.



Posted in My Travelings | Tagged , | Leave a comment

Vidin and Belogradchik

In September we also got a chance to visit Vidin and Belogradchick. Vidin’s bridge still has not reached Romania but it is almost nearly there. Otherwise Belogradchik is something that has to be seen no doubts about it!



Posted in My Travelings | Tagged , | Leave a comment