Edge Automation Link: Edge Scoping MVP for Casablanca - ONAP Enhancements

Note: This is likely to be a stretch goal for Casablanca, based on discussions with AAI. 

Distributed Edge Cloud Cloud Infrastructure Resource Modeling

Carrying forward some discussion resulting out of the Cloud Infrastructure Aggregate Representation Classes

The following image captures the potential challenges to Homing when abstracting away the Physical DC information from the homing solution, which currently homes to a cloud region.



  • No labels

3 Comments

  1. Arun Gupta

    So, for public cloud, where the physical data center locations are typically not available, we'll have to live with this; but yes, the data model should be able to handle the more favorable situation for owner-operated cloud.

  2. Shankaranarayanan Puzhavakath Narayanan

    Arun Gupta, thanks for your thoughts on this. I was worried that the current workflows involving (SO, SDNC, MultiCloud, etc) assume homing to happen at the granularity of Cloud Regions. Some of these components that depend on homing recommendations being cloud regions, may need to understand this composition of physical DC endpoints into Cloud regions and/or use the physical DC end point returned in the homing solution during the instantiation/scaling.  

  3. Srinivasa Addepalli

    Shankaranarayanan Puzhavakath Narayanan and Arun Gupta,

    Based on my brief discussion here in Beijing on similar subject, it looks there is some confusion on the term "Cloud Region".    "Cloud region of cloud provider " so far has been used to represent the physical location of the site hosting the set of compute nodes with a VIM.  And that is the reason,  OOF is returning the cloud region information as part of its placement decision.   But this term is used by AWS and AZure to represent the coarse level geography, like east-coast, west-coast etc... For each geography region, there could be physical data centers, but many of these hyper cloud providers don't expose physical data centers.  So, both of you are right.  But, the confusion with the term "cloud-region". 

    It is true that the Edge-automation group is suggesting to use edge-regional-provider, which will control multiple physical sites. In this case, ONAP will communicate with the edge-regional-providers to instantiate resources (VNFs/networks) in various physical locations.  Even in this case, the thought is to have "cloud-regions" to represent physical locations and only have reachability information specified at the edge-regional-provider level  to avoid duplication of this information.

    That is,

    "cloud-region" in ONAP represents the cloud-regions as hyper-scale CSPs (This is the granularity they expose). It is physical location in case of operator clouds, even with/without edge-regional-provider.