Bits and bytes fly all over the world, every day, on well-architected and highly reliable networks.

Bits and bytes fly all over the world, every day, on well-architected and highly reliable networks.

We’re at an interesting point in the Enterprise IT world – the term ‘Software Defined’ is getting applied to about everything — Software Defined Networking, Storage, Radio, Data Centers, Infrastructure, etc.

I was unabashedly not a fan of the initial models described by the pundits lauding praise and hype on Software Defined Networks.  This was mainly because I felt the model was fundamentally broken- the concept of centralizing control for everything from packet/flow forwarding, to topology construction, to policy application seemed to be just plain over-reaching.  Certainly there is tremendous room for improvement in the way network systems architectures work, but there is also incredible amounts of technology that fundamentally works, works well, and is deemed highly reliable.

But controllers are here, and seem here to stay – so where is the right demarcation?  It seems that forwarding is done quite well, routing protocols are fairly well understood and are, when not completely misused, very reliable.  So in a perfectly demarcated and abstracted world I would leave the forwarding decisions to the network elements to do what they have done well for the past twenty-plus years.  However networks have been pretty horrid at implementing policy- some people argue that a network element is absolutely the wrong place to implement policy while others, usually vendors of network equipment, keep trying to put more and more complexity into the network in order to claim that they are the perfect place to implement policy.

Networks have also been pretty bad at being programmed.  We had the CLI, then we had SNMP with all of its drawbacks, and then most people fell back to the CLI.  Networking vendors have evolved and lately have started offering more elegant programmatic interfaces such as Python or their own custom APIs – but these all fall apart when you realize that any code you write for Vendor-X is not portable to Vendor-Y.  Every vendor has done an amazing job of ensuring that any investment a customer makes in automating their infrastructure only works for their infrastructure.  (It’s a really good thing the server industry didn’t follow such a myopic path or we’d not have any applications at all that worked and evolved).

So to me, the primary role of the controller, at least amongst the vendors whom I think will be successful and hopefully be lasting is to provide that abstraction layer between the vendor-specific integrated hardware/software stacks and the systems automation that the enterprise or service provider wants to build.  Done right an enterprise writes a set of automation routines that integrate with the rest of their business and IT applications which then programs the controller.  The controller takes the input and makes the set of programmatic changes necessary across vendors and network tiers to implement the policy change.  The controller vendor that offers the greatest degree of integration with programming frameworks and existing management systems coupled with a reasonably broad set of network architectures and vendor interfaces stands to be quite successful.

The types of policies that seem to be most prevalent today are segmentation, access control, and quality of service policies.  Some of these make perfect sense to be in ‘the network’ — i.e. an aggregate policer/shaper can only be done in the network, on a switch/router, in the data path; and similarly DDOS prevention/mitigation is best done in the SP network before the last mile connection..  However, for many of the other items – access control lists, host-based and VM/container-based quality-of-service – the question has to be asked– is the network the right place for these types of policies?

I ask this not out of malice towards those who think all policy should be in the network, nor in any way trying to steer a conversation towards NFV.  But more out of knowing how hard I’ve worked for 7+ years to try to get network policy bound to a specific workload/VM/container and have the policy be portable with that workload only to find out just how difficult it is.

The challenge with the inverse “put all policy on the host” model is that there are so many well documented attacks that cause kernel-level, hypervisor level, and even recently firmware level rootkits on a host that I have a difficult time trusting that the policy I place on the host will actually be working, that it can be audited, and monitored in a way that ensures it cannot be bypassed.

So, to me, a simpler definition of ‘Software Defined’ is as follows: ‘Software Defined’ is  the addition of modern programming interfaces to anything that used to be woefully difficult to automate and program.  It does not mandate a specific protocol, nor does it mandate a controller (although given the state of networking I see why they exist).  Software Defined  does mandate more open interfaces and acceptance that what operators want to do is to be able to automate entire systems, not just individual nodes, and that they want to use interfaces for machines that were designed for machines, and be able to fall back when troubleshooting on interfaces for humans that were designed for humans.  Yes, we vendors need to do both…

Is there a right answer about where to best place policy?

Does policy belong on the host, in the network, at specific policy enforcement points, all of the above???

Should we just let networks forward packets really well and keep them simple and hopefully more reliable?

So many questions…

dg