|IM-D||Admin||Kam / Nigel|
- Hing-Kam Lam Kam to ask Timon whether ONF has received the BBF December liaison announcing its adoption of open structure and now BBF is an Open Source organization.
- In a TAPI calls in December 2019, it was suggested that a VNF should be represented by a PC.
- Malcolm has analyzed the options for representing a network function that is independent of the implementation (in a VNF or PNF).
- TAPI 2020.01.14 call noted the need of a VNF model in mid-year 2020.
- This drives the need to start the VNF modeling now in the Core model.
- In addition to the considerations in the analysis, the discussion also noted that
- Should not have a VNF that has all three planes (data plane, management plane, and control plane)
- What is the TAPI need in managing ETSI VNF
- Need clarification from TAPI on its exact needs, requirements,
- May related to topology. Topology creation/deletion with respect to VNF (similarly w.r.t. equipment)
- Next step
- Need the TAPI requirements
- Further discussion within OIMT
- Socialize with TAPI:
- Consider adding an example (Ethernet Switch)
- Consider converting into a position paper
- ConstraintDomain (reversal of association - dependency)
- ConstraintDomain (CD) has incoming and outgoing constraints, thus it may create loop.
- Problem to resolve: Avoid looping
- Should we revert the "contraints" to "constrainted by"?
- In the diagram, there are two loops
- ViewMappingFunction (VMF) - ExposureContext (EC) - ConstraintDomain (CD) - ViewMappingFunction (VMF)
- ViewMappingFunction (VMF) - ExposureContext (EC) - ControlConstruct (CC) - ViewMappingFunction (VMF)
- The Party model will be for review next week
- The Location model will be for review the week after.