The first two attendees that I spoke with last week at NGON Africa in Cape Town expressed often held views that leading edge technology does not apply to Africa. The first was a young technologist who came by as we were unpacking equipment for display at the ECI booth. He asked about the hardware and I explained the 100Gbps transponder that we had installed in a 3RU Apollo™ shelf. His reaction was, “I can’t imagine we need anything that fast in Africa.” The second was a critical infrastructure operator who explained that he was not convinced yet that Africa was ready for the move from copper to fiber.
This is the sixth in a series of blogs on the topic of the evolving enterprise WAN that is based on a survey that was completed in May 2016 by 110 network professionals. The previous blogs were:
Through this (probably far too long) series on SDNs, we have looked at BGP, Fibbing, and Openflow. BGP and Fibbing would be described as augmented control planes; the distributed control plane is not replaced, but rather augmented with a controller that modifies the best path decisions of the control plane by interacting with the control itself in a somewhat “native” way.
This is the fifth in a series of blogs on the topic of the evolving enterprise WAN that is based on a survey that was completed in May 2016 by 110 network professionals. The previous blogs were:
In 2012, an executive who worked for one of the largest European service providers shared his dream with the attendees of Layer123’s first software-defined networking (SDN) & OpenFlow World Congress in Darmstadt, Germany. According to him, the reason for all the misery in carrier-land were not permanent price battles, flat-rates, and cut-throat competition; it was us, the vendors.
Openflow is the “father of software defined networks” in the minds of many engineers. To understand Openflow, however, you cannot just look at the protocol itself; rather you must go back to the beginning, in the mists of old networking.
This is the fourth in a series of blogs on the topic of the evolving enterprise WAN that is based on a survey that was completed in May 2016 by 110 network professionals.
The SDN Controller concept was originally developed as the intelligent centralized point of network control and programmability in an SDN environment. However, the name was very quickly adopted by several vendors who claimed that their traditional NMS was a “controller” because it allowed network-wide management and point-and-click provisioning of their equipment. As a result, for many people the line between an NMS and a Controller is blurred, resulting in confusion across the industry.
The last post on the topic of SDNs discussed BGP as a southbound interface to control policy. This form of SDN was once common in hyperscale data centers (though not as common as it once was). In our pursuit of out of the way (and hence interestingly different) forms of SDNs (hopefully this series will help you understand the scope and meaning of the concept of SDNs by examining both common and uncommon cases), it’s time to look at another unusual form of policy injection—Fibbing. In fibbing, a centralized controller engineers traffic flow in a link state network by interacting with the control plane directly, rather than interacting with the forwarding plane or the RIB.
In the last post on SDNs, I spent a little time discussing just a bare minimum of some internal router architecture—specifically the difference between the RIB and the FIB, and thinking a little about management. In this post, I want to add one more dividing point to the mix, and then start thinking about how we can classify various “software defined” solutions in a way that makes more sense out of the field of options.