The first part of this blog led you briefly through the age of modern networking. In this new edition, we will get down from the time-machine and walk around the era of policies.
Coming back to the same question where we left: why does ACI relies on policies to describe the networking model?
To answer this question, we can reflect at the traditional way the network is controlled. There is a standard management console that is governed by a network administrator. He defines in an imperative way, specific traffic patterns and security enforcement decisions. Currently, DevOps, automation, and infrastructure as a code, enable a network management by a single invocation of repetitive tasks applied on pre-defined templates. These powerful concepts coupled together with the application-driven networking, provide a neutral language for infrastructure description and faster network (re)provisioning. Automation allows for thousands of workloads to be tagged with a common set of rules, that are defined by a single line in a JSON file, or by a template in a GUI. We call these set of rules defined within a template – a Policy. A policy describes the desired network state in a declarative way, abstracted from the actions that lead to that state. Orchestrating reproducible policies in reusable templates that link the desired state to the respective actions, today is a paramount for network programmability and automatic control. The ACI takes care of translating dynamically the application policies into actions that are comprehensive to both, the APIC and the fabric.
Figure 1. ACI Object-Oriented Data Model
But it wasn’t only about automation
The core of the ACI model is the management information tree (MIT), a framework aimed to overcome the complexity of network programmability by formalizing the data representation. A policy in ACI represents a specification of the network state, which is described using objects and relations between them. For instance, managed objects are correlated to Ports, Links etc., as the policies are being parsed into a network configuration, Figure 1. MIT maps the logical objects to concrete networking elements and provides REST APIs that allow manipulation of the object model state. The ACI policy language abstracts the application developer from the physical network details by providing logical network representation. Therefore, the policies are meant to be created as a higher level configuration, since they encapsulate the business rules to be enforced by the APIC. Having said that, managing policies in ACI requires the right expertise from the right people, and a bit more of their coordination, that’s all.
Policy-based networking is not a new concept
Since the year 1999, there have been studies [1,2,3] that identified the need for a generic policy-based representation. Some attempted to develop a common language and a framework to serve this purpose. Cisco appeared among the main contributors in implementing support for policy into the fabric. A Policy-based management system for IP networks is an IETF standardization draft, which was crafted by the big industry leaders including Cisco in the year 2000 [4]. Despite that methods have been developed towards using policy in network management [5], the practical justification of those started to be evident only in the last 5 years. And then it happened, thanks to the progressive move of the Cisco networking team to bring up a new vision for the old network as we know it. When it appeared, ACI revolutionized the policy-based network management and control, and it was the first de-facto leader that implemented it in practice.
We observe nowadays a significant increase of policies in ACI, due to their uniform and simple way to describe a desired network state. Currently there are policies for diverse application/network requirements. Below are some of the domains where policies are used in ACI today:
- Policy for QoS – prioritize specific application patterns of some services
- Policy Based Routing (PBR) for: VXLAN BGP EVPN fabric and Layer 4-7 Services
- Policy for security by using micro-segmentation
- Policies for containers and Kubernetes integration
- Policy for public cloud integration: Amazon AWS, Azure, IBM Cloud and Google Clouds
- Policy for multi-clouds: VMware, Hyper – V/WAP/AzureStack
- Policy control across multiple hypervisors and bare metal
To summarize, this blog set in focus the ACI policy model and pointed out how by using policies, ACI helped the network to become more agile and self-driven. We also reviewed the history of Policy-driven network and some of the current policy types that are present in ACI. Eventually we redesigned networking and infrastructure and we redefined applications and security.
Why are we then reluctant to reshape the way we deliver modern services, networking and security?
Agree, one solution can lead to another problem. But then, we will find a solution for it; and return of investment; and innovation. And so forth. Stay tuned for the next blog that will reveal how the policies inspired the Intent-driven datacenter age.
References
[1] S. J. Shepard, Policy-Based Networks: Hype and Hope, in IT Professional, vol. 2, no. , pp. 12-16, 2000. doi:10.1109/6294.819933, URL: https://www.computer.org/csdl/mags/it/2000/01/f1012.pdf
[2] Dave Kosiur, Understanding Policy-Based Networking, John Wiley & Sons, Inc., New York, NY, USA, 2000, URL: https://www.wiley.com/en-us/Understanding+Policy+Based+Networking-p-9780471013747
[3] A. R. Choudhary, Policy-based network management, in Bell Labs Technical Journal, vol. 9, no. 1, pp. 19-29, 2004. doi: 10.1002/bltj.20002, URL: https://onlinelibrary.wiley.com/doi/pdf/10.1002/bltj.20002
[4] M. Stevens et al., Policy Framework, IETF draft, URL: https://tools.ietf.org/id/draft-ietf-policy-framework-00.txt
[5] D. Raymer, J. Strassner, E. Lehtihet and S. van der Meer, End-to-end model driven policy based network management, Seventh IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY’06), London, Ont., 2006, pp. 4 pp.-70. doi: 10.1109/POLICY.2006.17, URL: https://ieeexplore.ieee.org/document/1631156/
Authors