Simplified use of policy abstractions (SUPA), a new working group (WG) in the OPS Area, held its first meeting at IETF 94. The rapid growth of traffic flowing over service provider networks brings new challenges in network operations and management applications. Policy-based service management is one efficient approach that uses policy rules to manage the behavior of one or more managed entities. Unlike conventional policies, which are interpreted into devices as ACLs (Access Control Lists) and packet filters, SUPA introduces policies at the service-management level. More specifically, SUPA works on policy models, but not policy content. Operators can use the policy model to define their policies at a different abstraction level.
The SUPA WG’s History and First Session
The first IETF activity to propose policy abstractions to help simplify service management, SUPA made its initial call for interest at IETF 91, where it held a bar-BoF, followed by BoFs at IETF 92 and 93. During the second BoF session, more than ten operators supported the work and were willing to use this mechanism with standardized policy models. After public and Internet Engineering Steering Group (IESG) reviews the WG was created before the 94th meeting and held its first session in Yokohama.
Chaired by Daniel King and Nevil Brownlee, the first meeting focused on four topics: SUPA’s value, the policy-information model, the policy-data model, and applicability. There was also discussion about the possibility of using the SUPA policy model to guide specific policy design in routing systems. Finally, a SUPA policy engine demo was prepared for Bits-N-Bites.
During the WG meeting, Maxim Klyus introduced the value proposition of the SUPA work. For example, the Interface to the Routing System (I2RS) WG is considering whether the SUPA policy framework can be used to benefit I2RS. John Strassner presented a generic policy-information model that defines a common set of terms independent of protocol and technologies. A key point of the work is knowing how to use the information model to design data models. Michiaki Hayashi presented the current status of the event-condition-action policy-data model, the key component of deliverables in the current charter. Audience feedback indicated that one measure of success is whether operators can use the policy model to handle service management. The chair and Area Director encouraged more operators to get involved with the design of the policy-data model.
Another interesting aspect of the SUPA WG is the implementation and possible contribution to the Open Source community. Yiyong Zha introduced a policy engine demo which focused on building a working system to take a policy and translate it into configuration changes.
SUPA’s Bits-N-Bites Demo
A SUPA policy engine was demonstrated in Bits-N-Bites. The demo presented VPN service management in a packet transport network with a demo topology including 5000 nodes (Figure 1). In this schematic, the user of the external API selects the policy model and defines the policies, and the policy engine derives the policies using a constraint solver. Information from the network infrastructure devices is also needed to evaluate the policies and make the configuration changes. For a VPN service with connectivity from node A to node B, the user may want the connection to have two paths: a main path and a backup path. In reality, the user may want the two paths to be disjoint for resilience purposes. The user will express the policy of two disjoint paths using the given policy models and then the policy engine will find two disjoint paths and do the rest. Note that the user does not need to know the details of the path computation and network infrastructure, the user only expresses the policy using policy models. The policy models decide the level of abstraction to meet the user’s needs.
Q&A On Phe SUPA Demo
Was the demo based on the SUPA drafts?
Yes, the demo was based on the SUPA framework as described in draft-klyus-supa-proposition1. The policy engine’s role is to perform the policy translation. The policy model used here follows the style in the policy model draft2.
Why was it called policy-based service management?
The user needs only to express its policy using the given policy model for the policy engine to generate the configuration change. There is no need to rewrite the code for different policy needs. For example, a user can set up a VPN connection with more than two pairs of disjoint paths by simply changing the policy.
Was it only used for path changes in VPN management?
Not really. The policy model is defined for one problem domain, but anything that can be expressed via the policy model is supported for more than only VPNs. However, we are working on more problem domains, such as inter-datacentre traffic optimization, load balancing for NFV (Network Functions Virtualisation), and network operations, administration, and management (OAM).
Acknowledgements
This work has benefited from the reviews, suggestions, comments, and proposed text provided by the following individuals: Juergen Schoenwaelder, John Strassner, and Liya Zhang.
References
1. Maxim Klyus, John Strassner, SUPA Value Proposition, draft-klyus-supa-proposition-02 (work in progress), July 2015.
2. John Strassner, Generic Policy Information Model for Simplified Use of Policy Abstractions (SUPA), draft-strassner-supa-generic-policy-info- model-01 (work in progress), July 2015.