When Cisco proposed a policy-exchange protocol as a piece of OpenStack, it raised yet again the profile of the notion of policies as the solution to our network ills. Since then, I’ve had some pretty high-level people suggest that in the critical area of cloud, SDN, and NFV network evolution we could solve all our problems with “policy”. Well, maybe. I think there’s certainly a risk that we’ll embark on a policy hype wave, like we’ve ridden so many other exaggerations recently. Let’s try to nip it in the bud (futile, I know, but hey we have to try!)
The basic premise of policies in networks is that of “managed autonomy”. If you look at a network as a vast cooperative, you can see that simply inducing effective cooperation becomes an issue at some point. Where that point is depends on how big, complex, and multi-service the network is. On something like the Internet or even a big private network, you need to have some way to support scaling without an explosion in complexity. Policies are a proposed strategy.
In a “policy-driven” network, what you do is essentially to set goals rather than to exercise specific control over how those goals are achieved. Don’t tell every box in a metro network what you want it to do on an individual basis, tell logical collections of boxes how you want them to behave collectively, and define your instructions so that your logical collections’ behaviors add up to systemic efficiency and effectiveness.
One example of policy-driven networks that we’ve had around for years is the mobile network. In IMS networks, the routine strategy is to design the network for suitable behavior under specific conditions, then to regulate actual conditions in the network by regulating what you allow into it. Admission control is a policy mechanism, in short.
The current interest in policies comes from the drive toward SDN and NFV, and even the cloud. The reason is that none of these technologies will deploy universally. There will be little enclaves where the business case can be made—inside a service, a geography, a collection of equipment from a single vendor. How do we then create any harmony in the service overall when we can’t expect technical harmony? One approach would be to say that each of our enclaves was one of my “logical collections”, give it a policy to define its target behavior, and then mediate overall service behavior by coordinating these policies.
For today’s service evolution/revolutions, policies could be a kind of NNI or federation strategy. Instead of making it possible for SDN elements to talk to each other at a level detailed enough to support coordinated traffic management, give every logical collection instructions on how to be a “black box” with specific properties. Outside the box there’s no need to worry about how those properties are achieved. That solves problems of how to make SDN and NFV and legacy talk to each other.
I’m a fan of policies. I’m a fan of steering wheels. My two fan-doms are alike in that both are necessary things for effectively meeting a goal, but neither are sufficient. I commented when Cisco came out with OpFlex that it was a useful step toward a useful goal, but not a complete definition of the route. That’s actually true of policies overall. What policies really are, in terms of how we’d use them in modern networks, are an element in an abstraction strategy and an opening into orchestration. Without recognition of these connections, policies are just another media show.
Abstraction? Well, if our community of cooperative things is given a set of policies to allow it to internally meet an externally visible goal, then something that receives and enforces the policy is simply implementing an abstraction. The community is a black box, with properties seen from the outside that are enforced by policies on the inside. However, black boxes are not only opaque to specific measures, they’re opaque to everything, including whether policies are used at all. An SDN enclave can meet its goals any way that works. Policies could be one way, but not necessarily the only way.
The orchestration side? Well, think for a moment about a network made up of our black-box abstractions. We have services to build, so what happens. Policy guys will tell you that we’ll send policies to the black boxes that represent the goal-based definition of the role of each in the service. Gosh, that sounds a lot like orchestration to me. In fact, if we don’t have some kind of formal service orchestration to the level needed to identify which of our black boxes are actually involved in the service, we don’t know who to send policies to. Should we send them to everyone? Should every enclave or black box know about every service? That’s starting to sound like the problem of connection-oriented sessions at the scale of the Internet.
Then we have the question of what happens if something doesn’t fulfill its mission. How does somebody tell the Master Policy Agent in the Sky that they screwed up? What does the MPAitS do about it? We’re inventing management here, so now we have management and orchestration, which some people think they’re getting rid of by adopting policies.
We can’t get rid of them no matter what we adopt, because complex multi-national, multi-tenant, services are inherently hierarchies and are always going to have to be addressed as a series of nested abstractions. We can argue over how to communicate with the abstractions, but not with the fact we need them, and somehow need to communicate.
Any rational orchestration model will have a mechanism to define how, at a given level in the service hierarchy we need to create, the role of each element is coerced from the behaviors of what the element represents. Policies are one way to do that, and so Cisco in that sense is doing us all a service by pointing that out. But we need to ask Cisco to draw the whole picture, and we need to ask those who don’t like what Cisco does (or just don’t like Cisco, or just want to disagree with Cisco as a matter of “policy”) to define their whole picture too. You can’t choose policies as your strategy if you don’t know the whole picture, including the alternatives.