API for M3:

Flexible Designer / Orchestrator:

VID-SO Workflow Specifications AID:



VID-SO Instance Management AID:


Traffic Migration:

Traffic Distribution

R4 API Document

Change Management Schedule Optimizer:

New CMSO APIs in Dublin

5G RAN Software Upgrade:



Use Stories / JIRA

Flexible Designer / Orchestrator:

SO-1518 - Getting issue details... STATUS

SO-1542 - Getting issue details... STATUS

SO-1545 - Getting issue details... STATUS

SO-1543 - Getting issue details... STATUS

SO-1544 - Getting issue details... STATUS

SO-1546 - Getting issue details... STATUS

SO-1547 - Getting issue details... STATUS

SO-1548 - Getting issue details... STATUS

SO-1549 - Getting issue details... STATUS


Traffic Migration:

APPC-1442 - Getting issue details... STATUS

OPTFRA-424 - Getting issue details... STATUS

SO-1548 - Getting issue details... STATUS

 

Change Management Schedule Optimizer:

OPTFRA-426 - Getting issue details... STATUS

OPTFRA-390 - Getting issue details... STATUS

OPTFRA-391 - Getting issue details... STATUS

OPTFRA-428 - Getting issue details... STATUS

OPTFRA-430 - Getting issue details... STATUS

OPTFRA-432 - Getting issue details... STATUS

OPTFRA-433 - Getting issue details... STATUS

OPTFRA-434 - Getting issue details... STATUS

OPTFRA-435 - Getting issue details... STATUS

OPTFRA-436 - Getting issue details... STATUS

OPTFRA-437 - Getting issue details... STATUS

 

 5G RAN Software Upgrade:
SDNC-664 - Getting issue details... STATUS


  1. E2E Workflow Designer/Orchestrator (Includes all existing Activities/BBs)
    1. Dependencies: SDC, SO, VID
    2. Contributors: Amdocs, AT&T
  2. Schedule Optimization with Automated Conflict Avoidance
    1. Dependencies: OOF, Policy, A&AI, SO
    2. CM Scheduling Dublin
    3. CM Execution based on conflict-free schedule Dublin
    4. Contributors: AT&T
  3. Traffic Migration Workflow
    1. Dependencies: OOF, SO, A&AI (Model Change deffered), APPC/SDNC, Policy (Stretch), SDC (Deffered)
    2. Contributors: Orange, AT&T
    3. How do we manage state (e.g., traffic distribution weights) as the TM operation is going on
    4. Other use case benefiting: Scale in/Scale out
    5. Functionality:  Traffic Distribution Workflow Dublin Requirements.pptx (mainly slides 15, 16, 17 and 26)
  4. 5G PNF Software Upgrade
    1. Dependencies: SO, A&AI, SDNC, VID
    2. Contributors: Huawei, China Mobile, AT&T
    3. Functionality: 5G - PNF Software Update
    4. 5G - PNF SW Upgrade (Casablanca carry-over items)

 



  • No labels

13 Comments

  1. Ajay Mahimkar

    1. Create category for the above list.
    2. Upgrade/downgrade during the roll-out
    3. Synergies with other applications e.g., Scale out/in

  2. Rebecca Lantz

    A few points...

    • PNFs should be in scope for activities and done the same as VNFs
    • For NF model changes, it would be good to include application specific model changes.   These may be included in Vn+1 xNF package as artifacts, or they may be dynamically retrieved from xNFs directly (NETCONF supports get-schema which could be issued post upgrade).  
    • Examples of application specific model changes include
      • new/modified application configuration data model (YANG)
      • new/modified counters/PM measurements
      • new/modified alarms/FM events

    1. Lukasz Rajewski

      Rebecca Lantz considering point 2 and 3 please have in mind that since Casablanca it should be possible to build dedicated Change/Upgrade workflow for each VNF/VNS. Such workflow can include then execution of different LCM operations like Start/Stop/DistributeTraffic/Configure/ConfigureModify etc. (https://onap.readthedocs.io/en/beijing/submodules/appc.git/docs/APPC%20LCM%20API%20Guide/APPC%20LCM%20API%20Guide.html#api-scope) in any order. Configure a'like operation can query AA&I for additional information what can be helpful to achieve what you write about. I suppose. Does it make sense for you or I misunderstand you somewhere?

      1. Rebecca Lantz

        Thanks Lukasz, I'm not sure you have my point.  Assume xNF is running software version Vn, and was instantiated from an xNF package that contained various model artifacts (YANG for configuration, PM file for counters, FM file for alarms, etc).  It is likely that software version Vn+1 for the xNF will have modified/updated model artifacts.   So when a software upgrade of the xNF from Vn to Vn+1 is performed, it is good to consider that there may be different xNF specific Vn+1 model artifact updates which the ONAP Controller and various microservices will need to apply.   New managed object, alarms, counters, etc may have been introduced with Vn+1.   These are the xNF model changes I am referring to.   Maybe a different term (schema?) would be better. 

  3. Margaret Chiosi

    are you having calls on this that I can join?

    1. Lukasz Rajewski

      [usecase] Change Management

      There is a plan to reschedule this meeting to 9 am Eastern Wednesday.

  4. Margaret Chiosi

    sorry I couldn't attend - conflicts with modeling call.

    I have a basic question - if I want to just use the traffic migration component and not have it tied to software upgrade as well as maybe scheduling when this migration needs to happen, can I do this?

    I got the impression the goal was to have building block components so that folks can build their own 'scenarios'.

    1. Lukasz Rajewski

      Margaret Chiosi,  this mechanisms independent from change management and software upgrade and can be/will be used in other scenarios, like for instance ScaleIn use case. So far it is just ew LCM API in APP-C and SDN-C - later on dedicated workflow to be included as a sub-workflow in other scenrarios like Software Upgrade, ScaleIn etc.

  5. Margaret Chiosi

    Also am interested in traffic migration for PNFs not just VNFs

    1. Lukasz Rajewski

      We start the meeting in 10 minutes. TM for PNF would be another use case.

  6. Margaret Chiosi

    i meant  I am going to the modeling meeting at 9AM EST


  7. Rebecca Lantz

    Will the workflow building blocks apply to both PNFs and VNFs?  Or are two separate sets of building blocks needed?

  8. Fei Zhang

    Hi, Lukasz Rajewski , for VNF software upgrade, based on your response to Rebecca with (APPC LCM API Guide), could you help to answer few questions

    1. What is VNF SW upgrade workflow? Does only controller like APPC support it? Or maybe SDNC can supprot it? Or MultiVIM?

      1. If SDNC or MultiVIM supprot it, same API(of APPC) is used?

    2. In APPC LCM API VNF software upgrade, the 'existing-software-version' and 'new-software-version' is required in API.  where are ''existing-software-version' and 'new-software-version' from?  Are they from VNFD in SDC on-boarding package or from SDC GUI or somelse?

    3. BTW, as Rebecca mentioned, how aobut for PNF SW upgrade supporting status? is same flow or different flow as VNF?

    BestRegards

    Fei