SO Weekly Meeting 2019-12-4

Topic: SO weekly meeting


M2/M3 Functional requirements:

The goal of the Functionality Freeze is to mark the end of adding functionality in the Release.
After Functionality Freeze, no new visible functionality may be added to the release.
The API definition development activities are over and a stable document describing the API is available to the community.
At Functionality Freeze, the following activities have been achieved:All committed functionalities have been coded.
All Functional Test Cases covering the scope of the release are defined (Project Team).
All Functional Test Cases acceptance criteria are defined (Project Team).
All source code includes unit tests (Project Team).
The team is using the complete Linux Foundation environment (build, Jenkins, Gerrit, FOSS, Automated Unit Test, Nexus).
A final list of externally consumable APIs is available.
All vendor equipment has been delivered (Integration team)

Four S3P Requirements :
Document current upgrade component strategy
SECCOM Perform Software Composition Analysis - Vulnerability tables
SECCOM Password removal from OOM HELM charts
SECCOM HTTPS communication vs. HTTP

AAF integration

OJSI open issues

Java 8 to 11 upgrade


Frankfurt Release Review
Project Status in Frankfurt ReleaseProject Status in Frankfurt Release
Project Status M1 planningFrankfurt Deliverables by Milestone#M1
Frankfurt Release Planning 
Frankfurt RequirementsFrankfurt Release Requirements
SO Frankfurt Release Planning

SO Frankfurt Release Planning Template

SO Use Cases
Third Party Operational Domain Manager

REQ-17 - Third Party Operational Domain Manager IN PROGRESS

RANK #0

GREEN

YESThird-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

REQ-13 - Service Resolving feature DONE

rene.robert@orange.comRANK #4

DESCOPED

NOService Resolver

SDC (C), SO (C), AAI (TO)No SO decisionMISSING INFOMISSING INFOOrange

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

REQ-37 - Multi Domain Optical Service IN PROGRESS

RANK #3

GREEN

CCSDK PTL has confirmed he can deliver it

YES


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 (Unlicensed)

AT&T

Orange

Fujitsu

Working with CCVPN team to align towards common modelling for OTN
SO Requirements
PNF / PNF Software Upgrade using direct Netconf/Yang interface with PNF

REQ-84 - PNF Software Upgrade using direct Netconf/Yang interface with PNF IN PROGRESS

RANK #2

GREEN

SO impact clarified and agreed in SO weekly meeting.

YESPNF 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 / Enhancement on PNF Software Upgrade with EM with Ansible

REQ-53 - Enhancement on PNF S/W Upgrade with EM with Ansible IN PROGRESS


RANK #2

GREEN

SO impact clarified and agreed in SO weekly meeting.

YESPNF 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




PNF / PNF Software Upgrade with EM with Netconf

REQ-96 - PNF S/W Upgrade with Netconf/yang with EM IN PROGRESS

wangyaoguang

RANK #2

GREEN

SO impact clarified and agreed in SO weekly meeting.

YESPNF 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 / Bulk PM / PM Control

REQ-129 - PM Control Support IN PROGRESS

RANK #2

GREEN

SO impact clarified and agreed in SO weekly meeting.

YES5G Bulk PM in Frankfurt/R6CLAMP/Policy/CDS (REQ-33)XL

SO: C

DCAE: C

Integration: C

SO: C

DCAE: C

Integration: C

SO, DCAE and Integration committed by Ericsson


Former user (Deleted)       EricssonDCAE: Committed based on Ericsson support
5G / 5G NRM Network Resource Model (Configuration Mgmt)

REQ-49 - 5G NRM Configuration Management with RESTFul protocol IN PROGRESS

wangyaoguangRANK #3

GREEN

No commitment from SO lack of design, resource, etc

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

YES5G 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


wangyaoguangHuawei

PNF / Plug and Play

REQ-134 - Plug and Play Enhancements Epic for R6 Frankfurt Release IN PROGRESS


Benjamin Cheung

RANK #2

GREEN

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

YES


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

REQ-76 - NETCONF/TLS Certificate Management IN PROGRESS

RANK #3

GREEN

YESConfiguration with NETCONF in Frankfurt/R6AAF (REQ-140)M

SDNC: C

SO: TO

Integration: C


SDNC: C

SO: C

Integration: C

SDNC, SO and Integration committed by Ericsson


Mariusz SobuckiEricsson

Scaling Extensions

REQ-42 - Scaling (Frankfurt) IN PROGRESS

RANK #2

GREEN


YESScaling 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



ETSI Alignment Support

REQ-101 - ETSI Alignment Support IN PROGRESS

RANK #2

GREEN

SDC No more required

YESETSI 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



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)..

REQ-158 - E2E Network Slice orchestration in R6 Frankfurt IN PROGRESS



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 

GREEN

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


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

DCAE: Review pending; cannot be committed for Frankfurt as of 10/23. DCAE is not part of Frankfurt scope


Remove Python2 dependencies

REQ-174 - Remove dependencies on Python2 IN PROGRESS

David McBrideRANK #1

GREEN

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

Logging not committed for R6.




MALL projects using Python





Multicloud K8s Support (Continuation from R4) 

REQ-178 - MultiCloud K8s features IN PROGRESS

RANK #2

GREEN

YESK8S based Cloud region support (Continue from R4)

Multi-Cloud : C

Code Multi-Cloud : Intel


Testing of SO, Multicloud, SDC: Intel





Intel

Aarna

Tech Mahindra



K8s CDS Support

REQ-182 - K8s CDS Support IN PROGRESS

RANK #3

GREEN

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 





K8s HPA Support

REQ-183 - Add HPA Support for Multicloud-K8s IN PROGRESS

RANK #3

GREEN

YES

Extending HPA for K8S

Multicloud K8s

REQ-162 - This epic covers the work to upgrade ONAP components from legacy Policy API to new Lifecycle API IN PROGRESS

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



































































































































































































Epics & User Stories