Do network engineers dream of software defined sheep – computer systems design 9gag

############

Almost ten years ago in 2009, Kate Green coined the term Software-Defined Networking in an article describing the newly-created OpenFlow specification that would be released later that year. The idea was revolutionary: Decouple the forwarding plane from the control plane and move the latter to a centralized controller. electricity fallout 4 The controller would then manage the forwarding plane of the individual devices in the network from a global perspective. This would allow the entire network to be managed via a single interface to the controller. 1 unit electricity cost in bangalore For some time following this, SDN became synonymous with OpenFlow, but the philosophy has exceeded the implementation.

In an admittedly questionable Wikipedia page , SDN is defined as "an approach to cloud computing that facilitates network management and enables programmatically efficient network configuration in order to improve network performance and monitoring." This is an interesting perspective, considering that OpenFlow appears to have been developed with large service provider networks in mind. So where does it go from being a service provider technology to a cloud technology? Large service providers and cloud (particularly public cloud) providers have one thing in common: scale.

Since I began my career in networking (too) many years ago, technologies were placed in seemingly arbitrary categories and vendors tended to develop equipment with feature sets that followed these silos . electricity rate per kwh philippines Invariably, there’s bleed from one category to another when new requirements surface. So why are we maintaining these categories in the first place? Networking is networking. If the solution for an enterprise business requirement is traditionally a data centre networking or service provider networking technology, use it.

One of the key concerns about SDN that I’ve heard over the years is the problem of relying on a controller (or cluster of controllers) to make forwarding decisions. gas utility worker This approach is really good for standard routing and network functions that can be addressed globally. power company near me It falls down a bit when it comes to things like security policies at the edge, policy-based routing, and other exception-based items that are device-centric rather than network-centric.

When I first considered writing this article, I was running under the working title of "When SDN Isn’t" because I was frustrated with the number of solutions that purported to be SDN, but really weren’t for various reasons. Some of them did not centralize the control plane under a controller. gas oil ratio calculator Others didn’t provide open northbound APIs into their controller. Now I’m starting to think it’s time to expand the practical definition a bit.

If the component devices are programmed at the flow level by a controller that has the entire control plane centralized, and it meets the needs of the organization, that’s awesome. If those devices have their own control planes and their decision making is defined at a higher level by the controller, that’s just great too, again, so long as it meets the needs of the organization.

SDN, or a relaxed definition of it, has the potential to be the holy grail of networking in general, but we’re still stuck thinking in networking silos: cloud, data centre, service provider, enterprise, small/medium business, etc. What we want is a central and programmable interface to the entire network and to stop micromanaging devices. e gaskell north and south How that is accomplished below the controller level should be immaterial.