Open implementation issues
- Stavros Kanarakis
- David Perez Caparros
- damian.nowak
Summary:
Single service design
Nested services feature is not currently supported as expected in SO. There is a workaround involving allotted resources, but the easiest solution for us is to go with a design with a single service (CFS) and everything else as a resource underneath it (Access Connectivity, Internet Profile, CPE PNF...). This will not not impact our agreement with A&AI team for BBS. Everything that needs to be stored as metadata, can still be stored in the metadata section of the single CFS service instance. SDN-C will be creating every resource under one single service instance
PNF PnP flow in E2E services
PNF PnP flow part currently only works for normal service orchestration (services instantiated by VID). It is not implemented for E2E services orchestration (instantiated by an External API order request). As explained by @Seshu Kumar Mudiganti, ExternalAPI can only trigger the instantiation of E2E Services in SO.
We need to check with the SO team how to handle it. It is a priority for BBS since we have based all of our flows in the PnP flow and we make use of ExternalAPI for service ordering and instantiation.
PRH team to update PNF_READY internal event
PRH needs to send additional information (additionalFields) coming in the PNF registration event that is BBS use case specific in the PNF_READY event (attachmentPoint, accessID, CVLAN, SVLAN).
PNF_Ready is published after AAI is updated with PNF relevant information.
It is initially agreed, that PRH will copy in 1:1 fashion the contents of VES.pnfRegistration.additionalFields structure/array/Map into the PNF_READY event, along with the correlationID parameter sent there already in ONAP/Casablanca release.
This allows other applications in the flow (BBS uS, SO,...) to react based on domain specific information sent in the pnfRegistration.additionalFields in addition to the standard PNF related attributes.
Service-instance-related information
We need to provide further details for each piece of data we want to store under A&AI as part of a service instance, since SO handles service-related information.
Specifically
Where this information comes from? Ext-API when ordering a service? CL event? What is the API used?
Is the piece really needed to be in A&AI? (for example if only SDN-C uses it for resource controlling, then it could just come as input to its NBI and stored in MD-SAL)
Which component is going to use it from A&AI?
BBS Properties Per HSIA CFS Service Instance | Input Source | ONAP Components that must fetch the value from A&AI | Does it really need A&AI storage? | A&AI Metaname (for Metadata) |
|---|---|---|---|---|
RG MAC Address | Service Order via Ext API It also comes in the CPE Authentication Event | bbs-event-processor DCAE microservice (it fetches existing value from A&AI to compare it with the new value coming from PNF CPE authentication event in order to deduce if there is any mismatch) | Yes, as metadata of CFS service instance | rgw-mac-address |
Correlation ID (PNF-name) | Service Order via Ext API It also comes in the sourceName of the PNF registration event's commonEventHeader | Yes, as property of PNF object | ||
Service Type | Service Order via Ext API | SO / bbs-apex-policy (during Access Connectivity and Internet Profile VFCs creation & update) | Yes, as metadata of CFS service instance | service-type |
Access ID | PNF registration event | SDN-C or SO? / bbs-apex-policy (during Internet Profile VFC creation & update) | Yes, as metadata of CFS service instance | remote-id |
Upstream Speed | Service Order via Ext API | SDN-C or SO? / bbs-apex-policy (during Internet Profile VFC creation & update) | Yes, as metadata of CFS service instance | up-speed |
Downstream Speed | Service Order via Ext API | SDN-C or SO? / bbs-apex-policy (during Internet Profile VFC creation & update) | Yes, as metadata of CFS service instance | down-speed |
OLT Name | PNF registration event | |||
OLT PON port | PNF registration event | |||
OLT PON slot | PNF registration event | |||
CVLAN | PNF registration event Service Order via Ext API [optional - if not provided by Access SDN M&C] | SDN-C or SO? / bbs-apex-policy (during Internet Profile VFC creation & update) | Yes, as metadata of CFS service instance | cvlan |
SVLAN | PNF registration event Service Order via Ext API [optional - if not provided by Access SDN M&C] | SDN-C or SO? / bbs-apex-policy (during Internet Profile VFC creation & update) | Yes, as metadata of CFS service instance | svlan |
Expected ONT ID | Service Order via Ext API [optional] | SDN-C or SO? (for Access Connectivity VFC creation) | Yes, as metadata of CFS service instance | expected-ont-id |
CPE Manufacturer | PNF registration event | Yes, as property of PNF object | Not Applicable | |
CPE Model | PNF registration event | Yes, as property of PNF object | Not Applicable | |
CPE Equipment Type | PNF registration event | Yes, as property of PNF object | Not Applicable | |
CPE Serial Number | PNF registration event | Yes, as property of PNF object | Not Applicable | |
CPE SW Version | PNF registration event (also present in CPE Authentication Event) | Yes, as property of PNF object | Not Applicable | |
Attachment Point (Not a real BBS modeling property, since its constituent parts are captured in other model properties) | PNF registration event | bbs-event-processor DCAE microservice (it fetches existing value from A&AI to compare it with the new value coming from PNF re-registration event in order to deduce if it is a true relocation) | Yes, as value of link-name property of a logical-link bridged to the PNF object | Not Applicable |
ONT NNI Port | CPE PNF onboarding in SDC? | |||
OLT NNI Slot | Infrastructure bootstraping (manual script) ? | |||
OLT NNI Port | Infrastructure bootstraping (manual script) ? |