NFV adhoc Shitao li Huawei Content and status
- Slides: 10
NFV adhoc Shitao li Huawei
Content and status (1) • 7. 1. 3. 2 Vnf. Ext. Cpd information element partial done • 7. 1. 3. 3 Address. Data information element done • 7. 1. 4 Vnfd. Element. Group information element empty • 7. 1. 5 Information elements related to the configuration of VNF lifecycle management operations empty • 7. 1. 6 Information elements related to the Vdu 7. 1. 6. 3 Cpd information element done 7. 1. 6. 4 Vdu. Cpd information element done 7. 1. 6. 5 Sw. Image. Desc information element done 7. 1. 6. 6 Virtual. Network. Interface. Requirements information element done • 7. 1. 6. 7 Vnfc. Configurable. Properties information element done • • 2021/12/29 2
Content and status (2) • 7. 1. 7 Information elements related to the VLD done • 7. 1. 8 Information elements related to the Deployment. Flavour empty • 7. 1. 9 Information elements related to Virtual Resource descriptors • 7. 1. 9. 2. 2 done • 7. 1. 9. 4. 2 partial done • 7. 1. 10 empty • 7. 1. 11 2021/12/29 Virtual. Compute. Desc information element Virtual. Storage. Desc information element Information elements related to scaling Information elements related to monitoring 3
Plans End of March End of April 2021/12/29 4
Plans End of March Middle of April End of April Middle of April IFA 011 2021/12/29 IFA 011 maintenance CRs empty Dependency on IFA work plan 5
Discussion for Deployment flavour 2021/12/29 6
Discussion • Discussion points • Principle: each DF (different topology) would be its own Service Template • Applies to different target platforms • Today in tosca: • No mechanism can be used to choose from different service template • One possible way suggested by Michael and Matt: manifest file (key word used to identify each service template), to be solved in a TOSCA general way. • questions: • How to link two service templates with some relationship 2021/12/29 7
Meeting Summary • Conclusions: • No mechanism right now to specify how to choose among different service templates • No method at this version of tosca-nfv-profile is needed to specify anything in TOSCA service template schema. To be solved in a TOSCA general way in the future • Specification changes for tosca-nfv-profile: • All the common attributes of VNFD should be described in as properties within VNFD capability type. • Which attributes (from the VNFD in IFA) should be considered as properties within the (TOSCA) VNFD Capability Type is TBD (further study). • Matt believes we should start with the premise that all attributes are viable properties. • The VNFD Capability (Type) should be part (element) of the VNFD(or VNF) node type definition. • Principle: each DF (different topology) would be represented in its own Service Template • This is consistent with a general TOSCA approach where different Service Templates would be used to describe applications or services that would be used to describe similar functions for deployment on different target platforms Related notes for further study: • General CSAR packaging work item (Matt & Michael): TOSCA CSAR manifest file needs to allow for describing more than 1 Service Template (more than one “main” that are functionally equivalent but have some other differentiating characteristic; architecture|platform|composition|SLA|etc. (key word used to identify each service template), to be solved in a TOSCA general way in the future. 2021/12/29 8
Next Step • Next F 2 F meeting plan (need to be confirmed) • First week of May • San Jose (together with NFV world congress) • Host By Intel • 5. 1~5. 2 • Adhoc • Extend to two hours every week • Start time move one hour earlier 2021/12/29 9
Thank you! 2021/12/29 10
