Context Problem Solution The problem Requirements priorities and
Context: Problem & Solution The problem: • Requirements, priorities and costs are different for Vendors and Orchestration • Making one model for all is expensive and slow, misses the ONAP goals Model Consumers R 2+, Promoted by Vendors R 3, Promoted by SPs Models Vendors a solid standard agreed on all vendors straightforward mapping to the IM, easy to comprehend and verify not only ONAP Orchestration requires awareness of conventions external to simpleyaml-profile TOSCA promotes adding custom processing logic per service after heavy customization, ONAP parts (SDC, SO, controllers, AI&I) become less replaceable Understanding of advanced TOSCA concepts is not promotes generic processing logic, one for all services really necessary to encode VNFs and just slows down mostly relies on simple-yaml-profile TOSCA, delivery of new VNFs customizations minimized replacement of ONAP parts (SDC, SO, controllers, AI&I) is easier The solution: • Different models: vendor-oriented for onboarding, SP-oriented for composition and orchestration • Common IM • Translation between as part of onboarding process
Discussion Summary https: //wiki. onap. org/display/DW/Why+does+R 3+need+multiple+DMs Concern Raised Answer So, why can’t we have one DM for Lessons learnt during R 2: requirements, priorities and costs are different for Vendors and Orchestration; development of a all? one-for-all DM is expensive and slow, with ONAP goals being missed. What is in it for me? For Vendors: being standard, not only for ONAP For Orchestration: generic logic for all services, minimized customization efforts For ONAP: ability to onboard many models, ability to replace orchestration parts Complexity of translation, Data types on the two ends of translation will be very similar, and thus conversion will not require complex restructuring. especially of data type conversion Some run-time components expect Vendor-type DM The orchestration-oriented DM will promote generic orchestration logic and reduce customization efforts per service, so refactoring to this DM will be beneficial for all Ochestrators. For the transition period, 2 possible solutions were proposed: 1. Having a reverse-translating adaptors with the legacy orchestrators (sounds bad), or 2. (better) Enclosing the vendortype DM fragments as artifacts into the distributed services Translation scope: VNF only? What about Service? The principle is to translate everything that is onboarded. The Service DM should be translated if/when ONAP decides to onboard services. Until then – VNF DM only. Vendor information lost or deformed during translation Preserving vendor-provided information is a top value. Possible mechanisms to ensure this: the target DM is always on public view; cross references between the target and source DMs; nice to have automated consistency checks Verification and testing of the onboarded models Makes sense to perform these steps after translation
- Slides: 2