Industry Solutions and Trends
Technology is more than just networking and Juniper experts share their views on all the trends affecting IT
Paul Gainham

The rise and evolution of SDN – A lesson from history?

by Juniper Employee on ‎05-09-2012 08:38 AM

With almost with the same regularity as I drink tea, I can’t seem to get through a business day at the moment without discussing either SDN or Openflow.  Whether that’s an internal discussion, meetings with partners, customers or press / analysts this is a topic that is clearly gathering momentum.


Before going on, I should declare my position and interest.  From what I have seen so far, what the proponents of SDN are evangelising has an appeal – often networks today are too complex and rigid and have fallen behind the apps / virtualisation world in terms of their agility.  In an increasingly on-demand cloud centric environment, clearly that is something that has to be fixed.  The early proponents of SDN are articulating an approach that creates a new virtual control plane layer outside of the current networking equipment layer.  That virtual control plane is being positioned as more flexible, dynamic and agile than what currently exists.


The interesting dynamic on display in all of this debate is, I guess, who is best placed to fix the challenge of the network lacking the agility of the apps world – is it the existing and incumbent networking equipment vendors or some of the new vendors into this space?


My Colleague Nigel Stephenson shared some excellent perspectives on this topic on a broader front in his blog here


As always when new technologies and architectures such as this first get aired, people’s opinions tend to divide quickly in an almost religious like split and you tend to hear very strong opinions from both sides of the fence.


I think it’s fair to say enough of those opinions are getting an airing in public at present and I don’t think I can add anything further to that, but what I did want to share were some perspectives around this by looking at a case study from history, that has an eerily similar backdrop to it, to see if there are lessons for the future that can be learned from it.


That case study pertains to Provider Backbone Transport (PBT).


PBT was a technology released by Nortel in 2006 whose premise was pretty straightforward.  Nortel’s view at the time was that Ethernet derived services were becoming the main foundation of future carrier based services and that whilst the current widely deployed MPLS networks could deliver those services, Ethernet switching technologies were a much simpler and thus more cost effective solution to that need.  Their approach magnified those potential benefits by relying on relatively simple / off the shelf Ethernet switches at the network equipment layer and building a lot of the intelligence into an external centralised management and provisioning system to control that relatively simple network.


This in itself created a major religious debate at the time – centralised versus distributed control planes and people quickly took sides – see any parallels there?


For context, the main MPLS networking vendors into the highly competitive carrier infrastructure space at that time were Juniper Networks, Cisco and Alcatel Lucent and despite many attempts to enter that market, Nortel had seen little success.  They were however a major and existing vendor into the carrier space at that time for voice, broadband and optical technologies and carried a high degree of credibility.


So they had the brand credibility into their target market, but had not had success in entering the attractive MPLS infrastructure market so it could be argued they attempted a flanking strategy in an attempt to change the game and disrupt the existing market.


What then happened was interesting. 


I was already working at Juniper Networks at the time and to go back to my tea analogy, we could not get through a day without discussing PBT and what Nortel were trying to do.  It quickly got market attention because it was a new, interesting and different approach to solving a need that customers had, plus from the press and analyst perspective, it challenged the ‘big 3’ incumbent MPLS vendors.


In an attempt to garner credibility for their new offering, Nortel began to announce a number of impressive brand wins around the technology and PBT discussions quickly began to outdo my daily tea consumption.


I cannot speak for the other vendors but certainly within Juniper, our approach was to re-emphasise the rounded benefits of MPLS and remind the carriers of how flexible the distributed control model was and that ultimately how extensible it was outside of the core and edge network, ultimately out to the access and aggregation layer.  The final and probably most important aspect was that large scale MPLS deployments were battle hardened and proven in some of the most demanding networks there were at the time. 


To organisations whose business depended on the network being ‘5 9’s’ available, this was a key point.


So what happened?


The  service providers at the time in most cases lauded Nortel for bringing some new and fresh thinking to the table that on the surface promised to deliver some real business benefits and in many cases, used this as a commercial ‘weapon’ against the incumbent vendors.  Some aspects of PBT appealed – mostly its perceived simplicity and this drove some of the incumbent vendors to provide new ways of delivering an MPLS based approach to their needs but introducing simpler provisioning, lower cost delivery solutions etc.


In our case, plug and play MPLS and Seamless MPLS were two derivative developments that came to market as a result of this period.


Ultimately PBT did not find the success that Nortel had hoped for but it did have the interesting impact of driving some fresh thinking amongst the established vendors and played a part in standards based technologies that were to come into the market later on.  Possibly, the fact that at the time of introduction, PBT was effectively a proprietary technology, played against it.


By adopting a much more open approach from the beginning, SDN as an approach has a greater chance of success, both potentially as a ‘standalone’ solution but also in enabling vendors with solutions already deployed to take on board and deliver solutions that are built on the best of both worlds – solid, time served innovation and deployment knowledge coupled with ground breaking new thinking around how applications and network can better co-exist to the betterment of all end users.


Views and Opinions always welcome.

Copyright© 1999-2013 Juniper Networks, Inc. All rights reserved.