This page will capture issues to be addressed in the overall architecture of OPNFV components.

policy_architecture.pptx

• Policies are reflected in two high-level goals
  • Ensure resource requirements of VNFs are applied per VNF designer intent
  • Ensure that generic policies are not violated, e.g. networks connected to VMs must either be public or owned by the VM owner
• Policies are distributed through two main means
  • As part of VNF packages, customized if needed by Service Design tools
  • As generic policies provisioned through into VIMs or in a closed loop policy management system through distribution mechanisms
• Policies are mostly locally applied at the resource manager
  • Components (e.g. VIMs) can execute some policies locally
  • VIMs may need assistance of other actors, e.g. for use cases that can’t be locally applied, or where info from multiple VIMs is needed
• Policies are localized as they are distributed/delegated
  • High-level policies (e.g. expressing “intent”) can be translated into VNF package elements or generic policies, perhaps using distinct syntaxes
  • Delegated policy syntaxes are likely VIM-specific, e.g. Datalog (Congress) or YANG (SDNC)
• Policy may take multiple paths toward the ultimate component handler
  • Config intent as expressed in OVSDB/OpenFlow is likely inadequate for all policy purposes
  • Policies expressed as security templates and engineering rules may require use of a model-driven or API-driven interface to the SDNC, if the intent can’t be realized through the OVSDB/OpenFlow interface from Neutron

General requirements for a policy architecture are below, with an assessment of the current state of support for these across major OPNFV components (1=poor, 5=excellent).