...
PRH update handling of Logical Links (move to SO) - introduced in R4 Dublin for BBS/Re-registration Epic
DEVELOPMENT IMPACTS
| PROJECT | PTL | User Story / Epic | Requirement | ||||||||||||||||||||
| A&AI | |||||||||||||||||||||||
| AAF | Epic #4 Secure PnP | Epic #4:
| |||||||||||||||||||||
| APPC | |||||||||||||||||||||||
| CLAMP | |||||||||||||||||||||||
| CC-SDK | Epic#1: Controller to PNF exchange (Epic) STEP 37 | Epic #1:
| |||||||||||||||||||||
| DCAE | Epic #4 Secure PnP Epic #5: Refactor Tests for DCAE-SDK DMaaP-Client | Epic #4:
Epic #5: Refactor Tests for DCAE-SDK DMaaP-Client f xXXXX ff | |||||||||||||||||||||
| DMaaP | |||||||||||||||||||||||
| External API | |||||||||||||||||||||||
| MODELING | Epic #2: Geolocation parameters | Epic #2:
| |||||||||||||||||||||
Multi-VIM / Cloud | |||||||||||||||||||||||
| OOF | Shankaranarayanan Puzhavakath Narayanan | ||||||||||||||||||||||
| POLICY | |||||||||||||||||||||||
| PORTAL | |||||||||||||||||||||||
| SDN-C | |||||||||||||||||||||||
| SDC | |||||||||||||||||||||||
| SO | Epic #3: SO Building Blocks. | Refactor PBMN workflow. Clean up. Migrate existing workflows to existing building blocks. Need to sync on the VID implementation of 5G VID Instantiation/orchestration. VCPE also wants to use these building blocks.
| |||||||||||||||||||||
| VID | Epic #3: SO Building Blocks | Need to sync on the VID implementation of 5G VID Instantiation/orchestration. VCPE also wants to use these building blocks. | |||||||||||||||||||||
| VNFRQTS | |||||||||||||||||||||||
| VNF-SDK | |||||||||||||||||||||||
| CDS | Yuriy Malakov |
List of PTLs:Approved Projects
...
PnP DUBLIN WORK ITEM | DESCRIPTION | ||||||||
| SO1: Building Blocks | Refactor PBMN workflow. Clean up work previously done in R4. Migrate existing workflows to existing building blocks. Need to sync on the VID implementation of 5G VID Instantiation/orchestration. VCPE also wants to use these building blocks. | ||||||||
| SO2: Service & NF Instance Association | Associating a xNF to a Service. Seen in the VID UI, after instantiation waiting for registration see only a Service instance, and beyond that a PNF resource instance associated with it. DEVELOPMENT STATUS: | ||||||||
SO3: SO support for already existing PNF A&AI entries | [SO] Support of SO for an already existing PNF (active) A&AI Entry (use case with a deleted & recreated service or instantiating 2nd service using the same PNF) DEVELOPMENT STATUS: In ONAP/Casablanca this was updated, and irrespective of AAI entry existence for a PNF instance, the workflow execution always waits to receive a PNF registration event.
This is not planned to be changed in ONAP/Dublin release. | ||||||||
SO-future: Controller to NF Association | [SDC/SO] The PNF controller caused quite a stir in Casablanca, the tension between Design/Platform Model vs Run-Time/Deployment Model. As a result the SO controller design was sub-optimal and should be addressed in Dublin. |
VID IMPACTS
| R6 ITEM | DESCRIPTION |
|---|---|
| VID1 Migration of Sub-worksflows | Migration of existing PNF PnP sub-workflows to a new BB approach (probably we will be creating 4-5 new BBs). VID Impact: Within “old” VID macro orchestration pages, a special field to provide a pnf-id parameter (shall be actually called “correlationID” or “PNF correlationID”) has been displayed under the following conditions:
When we migrate to BB approach, we`d keep the possibility to provide this parameter to the SO API call as input. How this will change with SO/BB approach, and with new VID GUI targeted at macro (GR) flows – we`d see exactly, after we execute some tests with VID. We`d have to check, what capabilities and conditions could be applied to display and process this “PNF Correlation ID parameter”. Can the same BBs could be re-used in “standard” vCPE use-case. We`re looking at a generic solution, and we`d probably display this additional field, when we figure out, that there is a PNF resource used in a Service Model. |
CONTROLLER IMPACTS
PnP R6 WORK ITEM | DESCRIPTION |
CTL1: Controller PNF Interaction | [CONTROLLER] Controller definition (SDN-C) came so late in Casablanca, we had defined some additional optional parameter for the step37 Service Configuration but likely more evolution needs to be done. SDN-C was not the theoretical proper controller and people objected as this is conceptually the L0-L3 controller. [STEP 35-37] - The SO to SDN-C and Controller to PNF exchange (Ansible or NetConf) was a carry-over item from R3. This requires that an API between SO to SDN-C is in place to support this. It requires that SDN-C support the appropriate Ansible Playbook and Directed Graph. Generic API. CDS has its own API to SO. The work being done with the CDS work is re-used for PnP U/C, so no new development needs to be done. ASSOCIATED DEVELOPMENT: (Jira) Controller Design Studio (Design Time) - to customize configuration. This might be used to set the values of parameters that might be send down to a PNF. NetConf - see the NetConf 5G U/C Wiki: 5G - Configuration with NETCONF |
...