EditThe page is intended to summarize all the requirements for Frankfurt Release.

These requirements have been prioritized by the TSC to realistically fit within the Frankfurt Release Timeline.

The Release Scope should be finalized during the M1 Release Planning milestone on November 7th, 2019

TSC Prioritization (Ranking)

Requirements Milestones Summary

See also Documenting Release Requirements in JIRA

Use Cases 

Release 6 (Frankfurt) proposed use cases and functional requirements

M1 Scorecard:

M2/M3 Scorecard:

Architecture:




(star) T-Shirt Size: Ballpark estimation for assessing the development/testing activities performed by the project team; not the integration team

Use Case

JIRA link (REQ)

One issue per requirement.

Instructions

Owner(s)TSC Ranking

M1

Scorecard

TSC M1 Approval Recommendation

M2/M3

Scorecard

 

 TSC M2/M3

Approval

Link(s) to HLD/LLD if anyDependency (from/to) another project(s)

T-Shirt Size (star)

Project's Impact: Test Only (TO), Code (C)

Committed (C)/ Partially Committed (P) or not (N) per impacted project


If Partially or not Committed, what are gaps/ project (people/FTEs; HLD/LLD; etc)Integration Lead

Company

Engagement

Notes
Third Party Operational Domain Manager

RANK #0

YES


Third-party Operational Domain Manager
S

SDC (C)

SO (TO)

AAI (TO)

Changes being done in local setup

SDC: Committed based on Telstra contribution

[TSC]: What does it mean? No SDC contribution to the ONAP Community.

[Atif]:Changes were temporarily done locally, when the ElAlto branch wasn't cut and we couldn't commit to master

Will commit after review discussion with SDC PTL


[TSC]:What's the status? PTL OK?

[Atif] PTL is OK. Code commit started.

TelstraComplete company commitment for delivery of Frankfurt Scope for this use case
Service Resolver Features

rene.robert@orange.comRANK #4

NO

Service Resolver

SDC (C), SO (C), AAI (TO)No SO decisionMISSING INFOMISSING INFOOrange
CMPv2 CA Plugin for AAF

RANK #3

Confirmed by AAF PTL


YES

Note:

Risk for contribution delay due to limited support from AAF on the following tickets  

These are required to be solved for fulfilling the release requirements and currently the community heavily lacks involvement in AAF. It is hard to do troubleshooting.

Low risk also for not sufficient amount of approved commiters inside AAF that can approve the contribution.


1/21- Extraordinary committers have been approved by TSC on 1/16. Are we still RED?

XL -

AAF (C)

Integration (C)

AAF: (C)

Integration:(C)

See notes

AT&T

Ericsson

Nokia


Note: Nokia and Ericsson volunteered to work this. As PTL, I approved the path forward (create Client, build plugin, etc) but was unable to create actual REQ. Please consider this working item until them.

(update : created, at the moment we do not expect multiple release impacts but it has to be further checked)

ALSO... This MAY be a multi-release effort, which will not affect normal Operations in anyway, if CMPv2 isn't completed within Frankfurt.

CCVPN:

E-LINE Service over OTN NNI

LIN MENG

RANK #2


YES

Note:

Functional impacts and API changes in the related modules have been  reported and documented.

To be more specific :

API changes in A&AI and SDN-C are committed and merged.

OOF: Swagger API document  is provided; coding has be started by last week.

U-UI has no API change, resource are in the coding phase now;



E-LINE over OTN Inter-Domain Links - Proposal

XL 

(Multiple releases)

TO: SO;

C: U-UI, A&AI, OOF, SDN-C

U-UI committed by ChinaMobile;

A&AI committed by Huawei;

OOF committed by Huawei;

SDN-C committed by Huawei


China Mobile, Huawei

End to End Layer 1 Service Management. Modeling the Optical Service

RANK #3

CCSDK PTL has confirmed he can deliver it

YES


Functional requirements & corresponding APIs have been documented across:

A&AI, SDNC, CCSDK - merge in progress

SO - coding phase

UUI - coding phase


Multi-domain Optical Network ServicesCCVPN use-case alignmentXL (Multiple releases)

TO: SDC, ExtAPI

C: UUI, SO, A&AI, SDN-C, CCSDK

SO - C

A&AI - C

SDN-C - C

UUI - C

CCSDK-C

SDC - TO

ExtAPI - TO

Code will be committed by Fujitsu


Have gained PTL agreement & JIRA epics have been created under UUI, SO, SDNC, A&AI, CCSDKXin Miao

AT&T

Orange

Fujitsu

Working with CCVPN team to align towards common modelling for OTN

Deploying Distributed External functions


RANK #0



YES



Depends on development progress of Multi-Cloud K8S work.

(K8S based Cloud region support (Continue from R4))

XL 

(Multiple releases)

TO: Multi-Cloud

Intel will contribute to this.

There is no code development and it is for testing the work being done in MC project.


Intel, Aarna, TM






Requirements

M1 Scorecard:


Architecture:



Requirement

JIRA link (REQ)

One issue per requirement.

Instructions

OwnerTSC RankingM1 Scorecard

TSC M1 Approval

Recommendations

M2/M3 Scorecard M2/M3 TSC ApprovalLink(s) to HLD/LLD if anyDependency (from/to) another project(s)T-Shirt Size (XS, S, M, L, XL) (star)Project's Impact: Test Only (TO), Code (C), Documentation Only (DO)Committed (C)/Partially Committed (P) or not (N) per Impacted projectsIf Partially or not Committed, what are gaps/ project (people/FTEs; HLD/LLD; etc)Integration LeadCompany EngagementNotes

All Control Loop Policy Models should be TOSCA Compliant

Operational, Guard Policies

RANK #2

YES


TOSCA Compliant Policy TypesSDCM

CLAMP - C

POLICY - C

CLAMP - C

POLICY - C

committed by AT&T & Ericsson


AT&T

Ericsson


Policy Update Notifications

RANK #2

YES


Policy Update Notifications
S

DCAE - C

POLICY - C

DCAE - C

POLICY - C

committed by AT&T


AT&T

Wipro

DCAE: Commitment based on Wipro
CLAMP Deployment of Policies to PDP Groups

RANK #3

YES


CLAMP Deployment of Policies to PDP Groups
M

CLAMP - C

POLICY- C

CLAMP - C

POLICY - C

committed by AT&T


Project Pairwise Testing

Gervais-Martial Ngueko

Pamela Dragosh


AT&T

Ericsson


Integration of CDS as Actor in Control Loops

RANK #3

YES


CDS actor support in Policy

L

CLAMP - C

POLICY - C

CDS - C

Integration - C

CLAMP - C

POLICY - C

CDS - C

Integration - C

Partial commitment from Bell Canada to support Policy+CDS integration.


Partial commitment from Huawei to support 
CDS+CLAMP integration.


undefined undefined

Bruno Sakoto

Adil Mir

Vidyashree Rama

Gaurav Agrawal

AT&T

Bell Canada

Ericsson 

Huawei

Orange


Control Loop Tutorial Documentation


RANK #3

YES




CLAMP, DCAE, POLICYM

Documentation  - DO

Integration - TO

DOC - C (Orange)

POLICY - C (AT&T)

DCAE - C (AT&T)

CLAMP - C (AT&T)


Morgan Richomme

Bell Canada,

AT&T,

Orange


Component Upgrades to new Policy Lifecycle API

RANK #2



YES




M

SDNC - C

OOF - C

POLICY - C

POLICY - C (AT&T & Intel)

OOF - C (Intel)

SDNC - C (AT&T)




AT&T, IntelSO removed as impacted as they are removing Policy support from workflow.
Modeling: Enhanced Nested and Shared Service Information Model - 5G / E2E Network Slicing modeling

Swaminathan Seetharaman

Shankaranarayanan Puzhavakath Narayanan

TSC: Replaced by new E2E Network Slicing Scope

No commitment to cover ExtAPI





NETWORK SLICING PoC in R6 Frankfurt (Obsolete)

 SDC

Possibly dependent on 

 L

SDC-C

AAI-C

External API

Company commitment per component

SDC - C (Amdocs)

AAI - C (Amdocs)


*Note: Not sure integration lead is needed for modeling

Borislav Glozman

Swaminathan Seetharaman

LIN MENG

CMCC

Amdocs

AT&T

Wiprc

Huawei


5G / OOF SON Enhancement

RANK #3



CCSDK is not required

YES


OOF (SON) in R5 El Alto, OOF (SON) in R6 Frankfurt

Runtime DB

Possibly dependent on 

L

POLICY - C

OOF - C

DCAE - C

SDN-C - C

Integration (Demo VNFs) - C

Runtime DB - C (see Remarks)

POLICY - C

OOF - C

DCAE - C

SDN-C - C

Runtime DB - C (see Remark(

Integration (Demo VNFs) - C

Policy, DCAE, Integration - Wipro commits

OOF, Policy - AT&T commits

SDN-C, Runtime DB - IBM commits


AT&T

Wipro

IBM

RAN-Simulator will be submitted as part of Demo VNFs repository


Runtime DB may not be an official ONAP component in Frankfurt, however, the functionality required for our use case will be realized.

5G / Run-time Data Persistency (RunTime Config DB) and VES Model relations, VES CM model (CM Notify).

RANK #3

PTL has confirmed he can deliver  CCSDK, SDN-C

YES


5G CONFIGURATION (RunTime DB)CM Notify VES Event (defined by Harmonized U/C) this U/C will actually use the CMNotify VES event and DCAE development to use the Event.L

A&AI - TO

SDC - TO

Controller - C

RunTime DB (new component) - C

DCAE - C

A&AI - C

SDC - C

Controller - C

RunTime DB (new component) - C

DCAE - C

Controller, RunTimeDB,  - IBM commits

SDC (TO) - AmDocs will commit

DCAE -  Nokia commits

A&AI Testing - IBM will do testing.


Sandeep Shah

Nokia

AT&T

Will be a new component, presented at Architecture S/C.
Modeling: GeoLocation Model (and standards harmonization)Modeling work onlyRANK #0

YES
Can you please provide a status update? thanksPNF PLUG and PLAY in R6 FrankfurtAAIMN/AN/A
N/A

Ericsson

Nokia


PNF / PNF Software Upgrade using direct Netconf/Yang interface with PNF

RANK #2

SO impact clarified and agreed in SO weekly meeting.

YES


PNF software upgrade in R6 Frankfurt
XL

SDC: C

SO: C

CDS: C

VID: C

Integration: C/DO

VNFRQTS: DO

SDC: (C)

SO: (C)

CDS: (C)

VID: (C)

Integration: (C)

Integration, SDC, SO, VID, CDS, and VNFRQTS are committed by Ericsson. SO is committed by Huawei


Eric Moore

Ericsson

Huawei


PNF / Enable Schema Update once PNF software is updated

RANK #2

Clarification: No impact on SO or VNF-SDK in R6.

YES


PNF software upgrade in R6 Frankfurt
M

SDC: C

Integration: C

VNFRQTS: DO

SDC: C

Integration: C

SDC, Integration and VNFRQTS are committed by Ericsson


Ericsson
LCM API Evolution

TSC: Please merge with REQ-84

Oskar: Done, REQ-84 contains the R6 user stories related to this requirement.





https://wiki.onap.org/download/attachments/50202249/2019-07-02%20ONAP_R6_Controller_Evolution_LCM_APIs.pptx?api=v2
N/A

Development in R6 will be part of REQ-84

N/A
N/AEricsson

Main goals:

  • Support use of CDS for LCM actions
  • Improved PNF LCM support
PNF / Enhancement on PNF Software Upgrade with EM with Ansible


RANK #2

SO impact clarified and agreed in SO weekly meeting.

YES


PNF software upgrade in R6 FrankfurtLCM API EvolutionM

SO: C

CCSDK: C

Integration:C

SO: C

CCSDK: C

Integration:C

Huawei commitment to SO,CCSDK,Integration


Enbo Wang


Huawei


PNF / PNF Software Upgrade with EM with Netconf

yaoguang wang

RANK #2

SO impact clarified and agreed in SO weekly meeting.

YES


PNF software upgrade in R6 FrankfurtPNF Software Upgrade using direct Netconf/Yang interface with PNFM

SO: C

CDS: C

Integration:C

SO: C

CDS: C

Integration:C

Huawei commitment to SO, CDS, Integration


Enbo WangHuawei
5G / ORAN & 3GPP Standards Harmonization

Modeling Only for Frankfurt

RANK #0


YES

green for A1 part (code merged)

O1 enhancements moved to G release


MOBILITY STANDARDS HARMONIZATION WITH ONAP
M

SDNC: C

DCAE: C

SDN-C: C

DCAE: C

SDN-C (A1 adaptor) committed by Ericsson & IBM

DCAE committed by Nokia


Sandeep Shah (A1, O1)

AT&T

Nokia

Ericsson

DCAE: Impact for adopting new VES domain; Committed based on Nokia support.
5G / License Management

RANK #0


ANSWER: There is no S/W development in R6. Company Commitment is commitment to work on Modeling & Architecture work for R6. Most of this U/C will be modeling development.


YES

No API, No S/W


LICENSING MANAGEMENTSDCM

Modeling: DO

VNFRQTS, after UCs agreed: DO


SDC(*)

( *) No code or test impact expected in R6 as an outcome of the proposed UCs

Nokia and Ericsson commit to:
Modeling: C
VNFRQTS: C


N/A

AT&T

Nokia

Ericsson

Orange

No development.

Activity driven by Nokia and Ericsson is Use Case development.

The UCs and modeling are done in synch.

5G / Bulk PM / PM Control

RANK #2

SO impact clarified and agreed in SO weekly meeting.

YES

SO impact changed from C to TO. Instead added dependency to REQ-134 for SO PNF workflow enhancements. Also added REQ-25 as new dependency.

Added AAI, CLAMP, Policy, SDNC and CCSDK as TO.


5G Bulk PM in Frankfurt/R6

REQ-25

REQ-33

REQ-134

XL

DCAE: C

Integration: C

SO: TO

AAI: TO

CLAMP: TO

Policy: TO

SDNC: TO

CCSDK: TO

All code and test committed by Ericsson for the listed projects.
user-3784d        EricssonDCAE: Committed based on Ericsson support
5G / Bulk PM / Secure Communication between xNFs and ONAP

Pawel BaniewskiRANK #2

YES

Currently marked red due to dependency to REQ-140.

1/21- Extraordinary committers have been approved by TSC on 1/16. Are we still RED?5G Bulk PM in Frankfurt/R6AAF (REQ-140)S

DCAE: C

DCAE: C

Nokia Commits to DCAE: C Development


NokiaDCAE: Committed based on Nokia support
5G / PM dictionary

RANK #2

YES

VES spec updated, reviewed and approved.  

Reconfiguration of SDC is in progress (JSON file change)



FM META DATA & PM DICTIONARY in R6 Frankfurt
S

SDC: Update GAB Config File (no S/W update)

DCAE: DOC

DCAE: VES Event Reg Spec

SDC - C

DCAE - C

Nokia Commits to SDC, DCAE - C


Damian Nowak

AT&T

Ericsson

Nokia

DCAE: No code impact on VES reg yaml updates
5G / 5G NRM Network Resource Model (Configuration Mgmt)

yaoguang wangRANK #3

No commitment from SO lack of design, resource, etc

Confirmation from yaoguang wang that the feature can be delivered even without SO.

YES

SO: requirements reviewed and approved. No additional API impacts.

CDS: requirements approved. Parts of executor codes merged.


5G Network Resource Model (NRM) Configuration in R6 Frankfurt
M

SO: C

CDS: C

Modeling: DOC

Integration: C

SO: C

CDS: C

Modeling: P

Integration: C

Huawei commitment to SO, CDS, Integration


yaoguang wangHuawei
5G / 5G Service Modeling: Modeling (exploratory) work for creating a 5G ServiceModeling Work Only (No REQ)

RANK #0


ANSWER: It is just modeling in R6. AT&T and Nokia commits to working with Modeling S/C work.


YES


5G RAN SERVICE MODELING & DEFINITION in R6 Frankfurt
N/AModeling: CModeling: C
N/A (No integration or testing impact)

Nokia

AT&T

Modeling work only
PNF / Plug and Play


Benjamin Cheung

RANK #2

Committed by SO PTL during the TSC call on 11/21

YES


External certificate part marked as due to dependency to REQ-140.

Can you explain the dependency to REQ-140?PNF PLUG and PLAY in R6 FrankfurtAAF (REQ-140)M

DCAE: C

SO: C

VID: C

DCAE: C

SO: C

VID: C

NOKIA Committed to DCAE, SO and VID Development


NokiaDCAE: SDK Dmaap lib refactor; committed based on Nokia support
PNF / Configuration with NETCONF/ Secure Communication between xNFs and ONAP

RANK #3

YES

Currently marked red due to dependency to REQ-140.

1/21- Extraordinary committers have been approved by TSC on 1/16. Are we still RED?Configuration with NETCONF in Frankfurt/R6

Dependency on AAF (REQ-140)
 


M

SDNC: C

SO: TO

Integration: C


SDNC: C

SO: C

Integration: C

SDNC, SO and Integration committed by Ericsson


Mariusz SobuckiEricsson


PNF / PNF pre-onboarding onboarding

RANK #2


YES


PNF/VNF PREONBOARDING / ONBOARDING in R6 Frankfurt
S

VNFSDK: C

Integration: TO

VNFSDK: C

Integration: C

Nokia Commits to VNFSDK and Integration - C


Nokia

Ericsson

Integration will only be for VNF-SDK work, there is not full E2E POB/OB integration in R6.
Modeling: Runtime instance model based on A&AI reverse engineering

Modeling Work Only

RANK #0


YES


Reverse-engineering AAI data model to Papyrus information modelAAIS

AAI: No code changes, updating missing fields in schema

Modeling only. No new implementation requirements

AT&T commits to the bug fix
N/A, producing a model file only, not a use case

AT&T

Ericsson

Huawei

Orange



















Modeling: documentation of policy and allotted resource modelModeling Work OnlyKevin ScaggsRANK #0


YES

Policy resource model No-GO for Frankfurt R6.

Allotted resoruce model still under review.

Need further info - are we on track or RED?

Policy

SDC

MModeling only. No new implementation requirements


AT&T
Scaling Extensions

RANK #2


YES


Scaling Use Case (Frankfurt)

APPC

CCSDK/CDS

SO

 S-M

APPC - C

CCSDK - TO

SO - C

APPC - C

CCSDK - C

SO -C (Actor selection of CDS and APPC)

APPC - Nokia Shanghai

CCSDK - Tech Mahindra

SO - Tech Mahindra



Marco Platania

AT&T

Nokia/Shanghai

Nokia/Poland

Tech Mahindra

Orange


APPC Ansible automation with VNF-C LCM support / CHM

RANK #2

YES


Change Management Frankfurt Extensions

APPC

Integration

S

APPC: C

Integration: C

APPC and Integration Commited by Orange
@Lukasz Rajewski

Orange

AT&T


vFW Traffic Distribution with Software Upgrade / CHM

RANK #2

YES


Change Management Frankfurt ExtensionsIntegrationXSIntegration: CIntegration Commited by Orange
@Lukasz Rajewski

Orange

AT&T


Portal Security Enhancements

Manoop TalasilaRANK #1

Confirmation from

Manoop Talasila

that the feature can be delivered even without Policy.

YES



MUSICL

Policy: C

VID: C

SDC: C

Portal partially committed by AT&T, IBM

SDC: C

Partially committed by Samsung (to support OJSI tickets)

Dominik Mizyn (for OJSI tickets)

AT&T

Samsung

IBM


Portal Technology Stack Upgrade and New reporting features

Manoop TalasilaRANK #3

Confirmation from

Manoop Talasila

that the feature can be delivered even without Policy.

YES




XL

Policy: C

VID: C


Portal committed by AT&T, IBM


Partially committed by Samsung (to support Springboot upgrade on "portal" repo)

Partially committed by IBM for test automation

GAPS: No resources to support portal/sdk repo for Springboot upgrade.

Sireesh Chintamani (Overall Integration Lead)

Sunder Tattavarada  (for Angular upgrade)

Dominik Mizyn (for Springboot upgrade on "portal" repo)

Leimeng Shi (for reporting feature)

AT&T

Samsung

IBM


ETSI Alignment Support

RANK #2

SDC No more required

YES<Missing Scorecard>
ETSI Alignment Support
XL

SO: C

SOL003 Adapter: C

SOL005 Adapter: C

ETSI Catalog Mgr: C

SOL002 Adapter: C

SO (C): committed by Ericsson and others with scale back scope

ETSI Catalog Mgr (C): committed by CMCC

SOL003 Adapter (C): committed by Ericsson with scale back scope 

SOL005 Adapter (C): committed by Verizon with scale back scope

SOL002 Adapter (C): committed by Samsung with scale back scope






Andrew Fenner

Ericsson

Verizon

CMCC

Samsung

Intel


Architecture - Modelling Alignment

Stephen TerrillTSC: Remove from the Frankfurt tracking. Ongoing discussions





L

SDC

Modelling






Vertical Industry Oriented On-demand 5G Slice Service (this is merged with Network Slicing use case, and has become E2E Network Slicing)

LIN MENG

TSC: This requirement is now merged with Network Slicing. No more individual tracking








Modeling, U-UI, SO, DCAENA

China Mobile,

Tencent,

Huawei

Merged with E2E Network Slicing use case

E2E Network Slicing

There are two parts:

  •  CSMF, NSMF in ONAP with external (core) NSSMF with a plug-in to SO is ArchCom approved.
    That is SO and External API impacts.
  • External CSMF with NSMF in ONAP with SO plug-in for core NSSM is Arch com approved
  • Arch clarification:
  • no NSSMF (potentially PoC only) in ONAP
  • There are impacts to OOF; It will be based on the HAS functionality, but modifying the constrints
  • AAI -> new schema (no code change).
  • SDC -> test only
  • Policy -> test only.
  • UUI has the CSMF portal and NSMF portal.
  • SO has new workflows to reprent the CSMF and NSMF and "NSSMF adapter"
  • External API exposes the NSMF NB APIs and shares the API definition with UUI.
  • For a example E2E slice. There is a NSI (E2E) - (1:1) - NSSI (E2E) – (NSSI (core) + NSSI (RAN).; howver for frankfurt, we assume that the NSSMF is outside ONAP, hence the "core NSSI handling" is "e2e".

The above is a clarification consistent with previous archcom decisions, but detailing it more and is considered architecturally consistent given the scope (NSSMF outside ONAP).

The following is not approved:

  • How the NSSMF is in ONAP
  • Slice across two domains (i.e. core and ran)..



RANK #3

TSC:

  • For the network slicing.  The following is a Go from architecture
    • SO plug-in to an External NSSMF (for core).
    • CSMF and NSMF representation in ONAP, and also allowing CSMF external.
    • What is not approved is NSSMF in ONAP; nor connecting two subslices together as that requires the NSSMF and that still needs quite some more discussion.

This should limit the impacts to SO and External API for Frankfurt 

Based on revisited scope i.e. SO and ExtAPI, OOF and UUI




----------------


Lin Meng's comment  (21st Nov):


a) 15th &18th Nov: LinMeng's Mail sent to TSC explaining the "exception".

b) 19th Nov: Steve's clarification of Arc decision in the first column.

c) 20th Nov: Swami's Mail sent to TSC requesting OOF and UUI inclusion in scope (resource commitments and PTL agreements available)

d) 21st Nov: LinMeng updated the columns for impacted modules, commitments based on the request sent to TSC ,  for TSC reference when in discussion


Please help change the status to Green

YES considering

#1 SO, ExtAPI  UUI scope only

#2 NSSMF is outside ONAP

#3 OOF is exceptionally added and will be reviewed at M2

--------------------


Lin Meng (21st Nov)

Confirmation:

1)Yes, we can deliver this feature for Frankfurt even without ExtAPI.

2) The impact in EXT-API for Frankfurt is only minimal impact, the resource has been identified and will be commited.


Please help change the status to YES


(See Notes)


E2E Network Slicing Use Case in R6 FrankfurtSDCXL

SO : C

EXT-API : C 

POLICY : TO

SDC : TO

A&AI : TO

U-UI : C

OOF : C

LinMeng updated on 21st Nov based on the request sent to TSC for including U-UI and OOF into scope, for TSC reference when in discussion

EXT-API : C (Huawei, Wipro)


SO : C (Wipro, China Mobile, Huawei)

POLICY : C (Wipro)

SDC: C (China Mobile, Amdocs)

A&AI : C (Huawei, Amdocs)


U-UI : C (China Mobile)

OOF : C (AT&T, Wipro)


LinMeng updated on 21st Nov:

Reply to TSC Concern:

1)Yes, we can deliver this feature for Frankfurt even without ExtAPI.

2) The impact in EXT-API for Frankfurt is only minimal impact, the resource has been identified and will be committed.



Wipro, 

Amdocs,

China Mobile, Huawei, Tencent,

AT&T,

Verizon

Jan 15, 2020: SO, EXT-API, UUI and OOF are on track for the agreed scope, with respect to all aspects - APIs, functionality implementation, as well as resource commitments.

Remove Python2 dependencies

David McBrideRANK #1

See feedbeck from PTL on the wiki except Stretch goals for SDC, VNFSDK to complete all in R6.

Logging not committed for R6.


Gathering Status from PTL




MALL projects using Python




Multicloud K8s Support (Continuation from R4) 

RANK #2

YES<Missing Status>
K8S based Cloud region support (Continue from R4)

Multi-Cloud : C

Code Multi-Cloud : Intel


Testing of SO, Multicloud, SDC: Intel



vFirewall:  

EdgeXFoundry

Akraino ICN Distributed Analytics




Intel

Aarna

Tech Mahindra


K8s CDS Support

RANK #3

MultiCloud commitment confirmed



YES


Integration with CDS

Change Management Frankfurt Extensions


S-M

MULTICLOUD: C

CDS: C

Integration: C

SO: TO

SDC: TO

CDS commited by Orange and Samsung

MULTICLOUD commited by Samsung, Orange and Intel

Integration commited by Samsung, Orange and Intel 


Orange

Samsung

Intel


K8s HPA Support

RANK #3

YES


Extending HPA for K8S

Multicloud K8s

S

MULTICLOUD: C

OOF:TO

Policy:TO

AAI/ESR:TO

SO: TO

SDC: TO

Intel commits to coding in Multicloud and testing in OOF, Policy, AAI, SO, SDC
Marcus Williams

Intel


 K8s Security and traffic  controller

 

RANK #3

commitment from MultiCloud confirmed

YES



 Multicloud K8sS - MMULTICLOUD: C

Intel commits to coding/testing in Multicloud




 Intel
VSP Compliance and Validation Check within SDC  - Phase 2


RANK #2

YES


VSP Compliance and Validation Check within SDC

SDC: C

([Prabhu]: SDC PTL reviewed the design and Vodafone  already committed the code in SDC and code review is in progress)


Prabhu BalanVodafone
OVP Testing and Certification Support Within SDC

RANK #3

YES

the feature cannot be delivered in Frankfurt because of lack of resources in 2020 to complete integration testing

Move to POC or to Giulin?OVP Testing and Certification Support Within SDC (Frankfurt)

SDC - C

VTP - C

SDC-iconectiv

VTP-iconectiv



iconectiv


SECCOM Code coverage

RANK #3

See feedbeck from PTL on the wiki

YES

Waiting for a feedback from PTLs - Jira tickets were opened to all projects. Preliminary feedback is on track.





All projects




SECCOM Containers configured per secure recommendation

RANK #3

YES

Waiting for a feedback from PTLs - Jira tickets were opened to all projects. 





All projects using containers




SECCOM Java 11 migration from v8

RANK #3

See feedbeck from PTL on the wiki.

YES

Waiting for a feedback from PTLs - Jira tickets were opened to all projects. 





All projects using java




SECCOM CII badging – meet targeted Silver and Gold requirements

RANK #3

YES

There has been no movement by the projects on the CII requirements for Frankfurt.





All projects




SECCOM Complete the OJSI backlog

RANK #3

excluding Logging

Logging has open OJSI tickets but has been descoped from the release.

Some of the tickets may not be closed easily but most of the most severe tickets is being worked on.

YES

Not all of the tickets can be easily resolved due to AAF integration issues (i.e. in SO) but apart from that most of severe ticketes should be resolved till end of the release





All relevant projects having an entry in OJSI




SECCOM HTTPS communication vs. HTTP

RANK #1

except for Music (partial) and Holmes/Logging - no part of the release.

See feedbeck from PTL on the wiki.

YES

Some projects tends to have issues with AAF integration to provide certificate but seems to be doable if issues in AAF are resolved





All relevant projects still using http communication instead of https




SECCOM Password removal from OOM HELM charts

RANK #1



YES

The amount of work is increasing as we discovered encrypted passwords and other cases where change in the components is required and we don't have the competency to make all of them (java script). We ask for help in some of the projects (only on the code part, OOM changes can be done on time)





All relevant projects




SECCOM Communication Matrix

RANK #3

DCAE will be the 'prototype' project/pilot with this release. Lesson Learnt will be shared to other projects.

YES - DCAE only

AS agreed first focus on external communication.





All relevant projects




SECCOM Containers and Kubernetes secure configuration recommendation

RANK #3

YES

Waiting for feedback from the Integration team





All projects




SECCOM Coverity integration by end of Frankfurt

RANK #3

YES

Waiting for an update from fd.io on their experience as Artem is not available  for this task.


to be followed-up via TAC. Pawel to write to Jason 




All projects using containers




SECCOM Ingress controller

RANK #3


YES

Ingress is already configured for most of the components. Not all may be working properli (UI) but they all will be available through ingress





All projects




SECCOM Secure communication for 5G – AAF contribution – CMPv2 protocol trial usage 

Hampus Tjäder

RANK #3

Please remove this requirement, it is a duplicate of

Need to understand why it is yellow




AAF + TBC




SECCOM Perform Software Composition Analysis - Vulnerability tables

RANK #1

except for Holmes/CLI and Logging - not part of R6 release

See feedbeck from PTL on the wiki.

YES

Waiting for a feedback from PTLs.

Script to automatically generate tickets is working.





All projects




Document current upgrade component strategy
David McBrideRANK #1

except for Holmes/ Logging - not part of R6 release

See feedbeck from PTL on the wiki.

YES<Gathering status from PTL>












(star) T-Shirt Size: Ballpark estimation for assessing the development/testing activities performed by the project team; not the integration team




POC / Experimentation

POC definition



SECCOM ISTIO POC – limited ONAP deployment scope​

TypeRequirementOwnerLink(s) to HLD/LLD if anyDependency (from/to) another project(s)T-Shirt Size (XS, S, M, L, XL) (star)Project's Impact: Test Only (TO), Code (C)Company EngagementNotesM4 Status




POC

SECCOM ISTIO POC – limited ONAP deployment scope












POCAcumos - DCAE Integration

MDCAE - C

AT&T

Orange (Integration/UC support)

Met withEric Debeau/Orange team on 10/25 and they commited to support.







POCSelf Service Control Loops


XL

CLAMP - C

DCAE - C

Policy - C

AT&T

















(star)T-Shirt Size: Ballpark estimation for assessing the development/testing activities performed by the project team; not the integration team