Page History

...

2a) OOF Processing - the fetched Policy (example below) is stored in a local data structure and is available for further use (need OOF code changes).

The "OOF Homing Enhanced Capacity Check & Cloud Selection Policy Example" described below is an exemplary policy.

{

"service": "cloudSelectionPolicy",
"policyName": "oofMulti-cloudCasablanca.cloudSelectionPolicy_vCPE_VNF",
"description": "Cloud Selection Policy for vCPE VNFs",
"templateVersion": "0.0.1",
"version": "oofMulti-cloudCasablanca",
"priority": "3",
"riskType": "test",
"riskLevel": "2",
"guard": "False",

"content": 
{
	{
		"cloudOwner": "All", //can be a specific cloud owner such as Azure, VMware VIO, Wind River Titanium Cloud etc.
		"cloudRegion": "All", //can be a specific cloud region for a cloud owner
		"capacityCheck": "TRUE", //perform capacity check per <cloud owner, cloud region>
		"dollarCostEvaluationVM-Type": "TRUE", //evaluate dollar cost per VM type if operator has configured a policy
		"dollarCostEvaluationVM-FeatureGroup": "TRUE" //evaluate dollar per feature/group of features if operator has configured a policy
	},		 			  	
}

"resources": ["vgw", "vgmux"], //"vgw" is also interchangeably used as "vg"
"applicableResources": "any",
"identity": "cloud-atrributes",
"policyScope": ["vCPE", "US", "INTERNATIONAL", "ip", "vgw", "vgmux"],
"policyType": "AllPolicy"

}

3. OOF → A&AI - Fetch Cloud-Agnostic (Standardized) Capabilities for the Service Instance

3a) OOF Processing - Perform Cloud Agnostic Capability check for each <cloud owner, cloud region>

4. OOF → MC - Push Cloud Agnostic Policy for the Service

...

Instance 

4a) OOF Processing

The enhanced OOF ↔ MC capacity check API, described below, is filled based on the enhanced Capacity Check & Cloud Selection Policy for Homing retrieved in step 2) – need OOF code changes.

...

• Parse OOF → MC Policy API 
• For each cloud region // Public cloud could have different costs in different geographic locations
  • Compute net_value based on cost
    • net_value = net_value + workload_deployment_cost 
      • The workload deployment cost is computed per <instance type, cloud region> based on workload deployment cost policy described in Step 5b).
        • Instance Type is derived from <Service, VNFC, cloud owner>
        • More details are in 5b)
      • Implementation Notes:
        • It is not mandatory for all plugins to implement this feature since the OOF → MC API has the flexibility of turning on this feature per <cloud owner, cloud region>
  • Capacity Check 
    
    • Private Clouds (OpenStack based)
      • Perform capacity check per specified Tenant (OpenStack Project)
      • If Capacity check fails, drop the cloud region out of the candidate list
    • Public Clouds or Other Clouds
      • Capacity check always succeeds //assumption: public cloud has infinite capacity

5b) Workload Deployment Cost Policy Configuration - Configured by the Operator

...

• Parse Template (e.g. OpenStack Heat Template)
  
  • For each VNFC, instance type in the template
    
    • Fetch Cloud-Agnostic Workload Deployment Policy (Intent) based on <Service (e.g. vCPE), VNFC (e.g. vGW)>
      • Value/Content: <Policy JSON> 
      • Note: The policy details are in Section 7b).
    • Parse Policy JSON
    • Modify template according to Intent - intent examples below
      • "Infrastructure High Availability (HA) for VNF" 
      • "Infrastructure Resource Isolation for VNF"   
        • "Burstable QoS"

• Policy (Intent) Realization

  • "Infrastructure High Availability (HA) for VNF"
    • OpenStack-based Cloud realization 
      • For R3, Host-based anti-affinity using server groups //Beyond R3, Support other anti-affinity models at availability zone level etc. 
      • Implementation Notes: 
        • Instance "count" in heat template specifies VNFC scale out factor 
        • While dynamic injection of server group into heat template is ideal, a simple starting point could be just switching to an alternate heat which is identical to the deployment template and additionally has server group
    • Azure realization 
      • Availability Set?

  • "Infrastructure Resource Isolation for VNF" – { "qosProperty": { {"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "25"} } }

    • OpenStack-based VMware VIO Cloud realization

      • This can be achieved through min guarantee -- Max or limit (upper bound) & Min or Reservation (guarantee) are part of OpenStack flavor metadata

        • https://docs.openstack.org/horizon/latest/admin/manage-flavors.html

        • https://blogs.vmware.com/openstack/resources-guarantee-openstack-and-vmware-integrated-openstack/

  • • • Example 
        • VNFC with "Guaranteed QoS" 
          • "flavor-xyz-no-oversubscription"
          • vCPU (Min/Max) - 16, Mem (Min/Max) - 32GB 
        • Same VNFC with "Burstable QoS", 25% over-subscription 
          • "flavor-xyz-25-percent-oversubscription"
          • vCPU (Min) - 16, Mem (Min) - 32GB 
          • vCPU (Max) - 20, Mem (Max) - 40GB  
      • Only certain pre-defined over-subscription values are allowed to simplify implementation
      • Implementation Notes:
        • While dynamic injection of limit/reservation into flavor is ideal, a simple starting would be to be to switch to a pre-defined flavor in the environment file
          • For aforementioned example
            • Original flavor - "flavor-xyz-no-oversubscription"
            • Modified flavor based on Policy - "flavor-xyz-25-percent-oversubscription" 

7b) Cloud-Agnostic Workload Deployment Policy (Intent) Database

• For R3, Cloud-Agnostic Workload Deployment Policy (Intent) can be stored in the form of configuration file(s) in the OOM K8S Persistent Volumes to simplify implementation.
• An exemplary policy is depicted below.

//Policy Example 1 - VNFC VGW which is part of vCPE service
{
	"Service": "vCPE"
	"VNFC": "vgw", //"vgw" is also intechangeably used as "vg"	
	
	{
		"cloudOwner": "VMware VIO", //can be a specific cloud owner such as Azure, VMware VIO, Wind River Titanium Cloud etc.
		"intent": 
		{
			"name": "Infrastructure Resource Isolation for VNF", 
				// realization possible without dedicating CPU and Memory, refer to section on "Cloud Resource Partitioning for Differentiated QoS" 
				// on how this can help in offering tiered services
			"qosProperty": 
			{
				{"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "25"}

			}
		}
	}
}


//Policy Example 2 - VNFC vDNS which is part of vLoadBalancer/vDNS service
{
	"Service": "vDNS",
	"VNFC": "vDNS", 
	
	//By default, Policy (Intent) is applicable to all cloud owners/regions unless specified.
	{		
		"intent": 
		{
			"name": "Infrastructure High Availability (HA) for VNF", 
		}
	},
	
	{
		"intent": 
		{
			"name": "Infrastructure Resource Isolation for VNF", 
				// realization possible without dedicating CPU and Memory, refer to section on "Cloud Resource Partitioning for Differentiated QoS" 
				// on how this can help in offering tiered services
			"qosProperty": 
			{		
				{"Guaranteed QoS": "TRUE"}
			}
		}
	}
}

Cloud Resource Partitioning for Differentiated QoS (Combined with Previous)

Value:

• Applicable to all use cases
• Casablanca Targets:
  • vCPE (Enable Tiered service offering); 5G Network Slicing (Stretch Goal) 

...