Purpose

This template is to be used for the “Parallel Deep Dive Sessions to Align with architecture / Use cases” at the may ONAP developers event

Instructions.

The purpose of each section is to translate the use cases and functional architecture into specific identified needs for the components, and to identify potential projects to be proposed.  There are three parts to this exercise:

  1. Identify needs based on the use case and architecture on this module, and potential dependencies on other modules or external artifacts.
  2. Group these into projects.  Consider that coding, documentation, and testing is required.   Include an initial scope for the project.
  3. If time, mapping the needs into the projects.

The need identification table has the following columns

-          Identified need: <slogan for the identified need>

-          Brief need description: <a few sentences describing the need>

-          Driver:<Related use case or architecture change, if any>

-          Dependencies:<identify dependencies on other modules or artifacts (e.g. other onap module, models, …)

-          Project: <If time, after the projects are identified, suggest in which project the need would best fit>

Time keeping suggestion:  The exercise time is 45 minutes.  A good practice would be to split into 20 minutes on need identification and 20 minutes on project proposals.

Exercise output.

ONAP Meeting Session name: <insert onap module name>

Need Identification:

Identified Need

Description

Driver

Dependencies

Project fit
(if time)

improve the efficiency of directed graph (caching)     
Support for underlay and overlayEnhance the support for overlay and underlay , L2, L3 and WAN   
Connect the SDN-C up into the rest of the system (interface)     
 Enhance sdn-c to support multi-vim environment.    
enhance app-c/SDN-C to support service chaining  Get the policy rules from policy (A&AI,) the service chaining modeling, SD&C 
 Support for geo distribution, scalability and federation    
Support for distributed transactions Support for transaction, and handling.    
configuration of IMS, PC functions Including required validation, LCM, .... configuration, ....   
Support for 3rd party controllers     
Data consistency via controller framework     


Project proposals.

[repeat for each project.  Note: This is not a complete project proposal skeleton, only sufficient enough for this discussion]

Project 1: network controllers

Project Name:

-          Provide a brief project name.

Project Description

-          Evolution of SDN-agent and transport controller

Scope:

-         SDN-agent

  • transport controller
  •  Quickly identify scope, consider: documentation, APIs, models, testing, integration, functionality.

-          testing.

-          non functoina, functional evolution

Other:

-          Identify baseline code (if any)

Project 2: Controller framework

Project Name:

-          A controller framework that is the platform infrastructure for the controllers.

Project Description

-          evolution of the controller framework.

Scope:

-          controller framework.

  • functionalional evolution
  • non functional
  • testing

-          Note of any particular deliverables to highlight.

-          If anything is out of scope, not it down

Other:

-          Identify baseline code (if any)

Project 3:

Project Name application controller:

-          Application controller functionality.

Project Description

-          Evolution of the application controller functionality.

Scope:

-          Quickly identify scope, consider: documentation, APIs, models, testing, integration, functionality.

-          Note of any particular deliverables to highlight.

-          If anything is out of scope, not it down

Other:

-          Identify baseline code (if any)

Project 3:

Project Name Integration test:

-          Integration test (scope???).

Project Description

-          intergration testing.

Scope:

-          testing,

Question: how to relate to CI/CD

Other:

-          Identify baseline code (if any)

  • No labels

1 Comment

  1. SDNC SFC is dependent on the underlay/overlay model in the cloud and MPLS VPN in the WAN.  Consider ODL SFC as starting point when its an owner operated cloud. 3rd party clouds (rackspace, aws, azure) would need to use the simple L3 chainging.


    SDNC would not normally have to participate in a mediation layer to clouds but any adaptor built for APPC can be installed and deployed in SDNC. They are the same code base at the adaptor level.


    Caching of directed graphs has been done but should not be the default behavoir becuase it can lead to a need to restart ODL to pick up a new revision to the DG. We have reserved caching for high performance applications like BGP re-writes not for typical configuration. VNF Management API's from DMaaP might be a candidate for DG caching if it made sense. Its about 5 lines of code to do simple caching but probably needs more lines of to do it right.