If you, like me, have spent a lot of time reading about network functions virtualization (NFV) and attending product briefings on how NFV will be implemented, you may have noticed a common thread permeating all the discussions about NFV's key building blocks, such as orchestration, security and service enablement. It's an unacknowledged thread that is not only a key enabler for each of these major building blocks, but also allows the NFV value fabric to be woven together. This common thread is policy management.
Policy, by definition, is a statement of general direction for which rules can be developed. For example, a policy may state: "All US government-related financial accounts are treated as security type alpha." This policy is then broken down into rules that control the behavior of systems, and define where and on what type of hardware government systems can be implemented.
Traditionally, policy like this is a design-time concern, and dictates how procurement and implementations take place. As we move to a virtual infrastructure many of these policies need to be realized at run-time, which is a game-changer.
There are several challenges in implementing policy at run-time: everything from how to accurately build a set of rules that implement the intent of the policy, to properly handling policy and rule conflict; to how to manage change of policy while maintaining performance levels. These challenges, while quite complex, have been proven to be conquerable with the proper application of hardware and advanced reasoning software.
However, my concern is that most of the work on policy is being done in isolated pools, and the ability to recognize policy conflict for end-to-end service delivery has not been adequately considered. If a common policy model for fulfilling the requirements of all of the discussions about NFV's key building blocks is not established and agreed to, we will create unnecessary complication and integration difficulties for our future implementations.
This work is bigger than any one standards group can address. I believe it will require a collaborative effort by the policy experts from a number of the existing standards organizations to tackle this problem in a consistent way. A common core policy information model and agreed-upon semantics that could be used and extended by each organization would go a long way toward solving this potential problem.
If you look past the acronym names of standards organizations to their member lists, you realize these different groups, focused on specific technologies and problems, are really composed of the same companies. Even if the companies that signed the original ETSI NFV ISG white paper would jointly approach the various groups they are members of, and suggest collaboration on a common policy model is critical, it would be a giant step in the right direction. It's time for folks to see the value in policy management, and understand the impact to NFV if holistic policy management remains stay low-profile.
— Ken Dilbeck, VP, Collaboration R&D, TM Forum, and contributor, special to The New IP