When introducing significant changes to the VNF Requirements project or changes that may require discussion.  It recommended that a Proposal be created.  The wiki page will be the place to collaborate and track changes as the proposal is reviewed, revised, and ultimately accepted or rejected.

Please follow these steps when creating a proposal.

  1. Copy the Proposal Template and create a page under the Proposals section of the VNF Requirements Wiki.
  2. Update the content of your proposal and set the status to Draft
  3. Create a JIRA ticket in the VNF Requirements project announcing the ticket, and put a reference to the ticket on the Proposals page
    1. Project: VNF Requirements
    2. Issue Type: Task
    3. Summary: Proposal Review:Title of Proposal
    4. Description: Link to proposal
  • No labels

16 Comments

  1. Murali Mohan Murthy Potham

    I have a suggestion.
    Each VNF requirement document should focus on the specific end user or based on priority.(or create sections based on these)
    Otherwise each specific user has to scan entire document and separate his needs and classify them according to the priority.

    For example, VNF SDK or VNF validation team do not want to know about VNF internal design or good to have specifications.It only needs mandatory specifications.

    Ex: Based on end user.

    1) VNF Designer.2) VNF Validator(tester) 3) VNF Developer


    Based on priority.
    Ex:1) Mandatory rules 2) Good to have specification 3) Design Guidelines

    1. Herb Patten

      These "Ex:1) Mandatory rules 2) Good to have specification 3) Design Guidelines" could be tags associated with the requirements that than could be used by the various teams to filter the requirements of interest

  2. yuanxing feng

    I'm not very clear about "Service Design" in ONAP Management Requirements(chapter 4).

    What does service mean here? Note there is "VNF Design" in VNF Development Requirements(chapter 2), service here means network service? Is it the same concept as NS in IFA?

    1. Steven Wright

      yes... similar to "network service" term from ETSI, but in ONAP platform service design is responsibility of SDC, and ETSI Framework model does not really address service design phase. 

  3. Steven Wright

    From the VDE call today we seemed to converge on:

    • Current ONAP platform (R1) may have some redundant/overlapping management interfaces towards VNFs
    • Requiring support for redundant/ overlapping interfaces burdens the VNF developers and risks fracturing the market.
    • ONAP architecture may not resolve this in R1, but should address it over future releases
    • [VNFRQTS] VNF Requirements components  need for some branching structure to allow for various options in the mgmt material.

     

    In considering  how to structure the branching within the requirements, it is important to note:

    • that we are tasked with developing an integrated set of requirements (ie. open-o vs ecomp distinctions should be removed as much as possible)
    • we need to support the Release 1 E2E use cases.

     

    I would propose we structure the mgmt. section around the generic operations that all VNFs are required to perform for the Release 1 Use cases. Looking at the R1 Use cases, I came up with the following table.

    TSC Use Case

    VNFs identified in TSC Use case

    VNF operations in R1 Use cases

    Use Case: Residential Broadband vCPE (Approved)

    vBNG, vG_MUX, vG,  vAAA, vDHCP, vDNS

    VNF Onboarding

    VNF Instantiation

    VNF Activation

    VNF Configuration (initial)

    Use Case: vFW/vDNS (Approved)

    vFW, vPacketGenerator, vDataSink, vDNS, vLoadBalancer,

    all VPP based.

    VNF Onboarding

    VNF Instantiation

    VNF Configuration (initial)

    VNF Auto Healing (Auto Reboot)

    Use Case: VoLTE(approved)

    vSBC, vPCSCF, vSPGW, vPCRF, VI/SCSCF, vTAS, VHSS, vMME

    VNF Onboarding

    VNF Instantiation

    VNF Autoscaling

    VNF Termination

     

    So I would suggest we start with Management  subsections around  each of these operations:

    • VNF Onboarding
    • VNF Instantiation
    • VNF Activation
    • VNF Configuration (initial)
    • VNF Auto Healing (Auto Reboot)
    • VNF Autoscaling
    • VNF Termination

     

    And then do any further branching below that. 

  4. Steven Wright

    VDE Presentation by Yuanxing Feng

  5. Herb Patten

    There was a suggestion to use the following:

    4. ONAP Management Requirements

      1. VNF Onboarding
      2. VNF Instantiation
      3. VNF Activation
      4. VNF Configuration (initial)
      5. VNF Auto Healing (Auto Reboot)
      6. VNF Autoscaling
      7. VNF Termination

    1. Herb Patten

      This has been revised see next comment on the proposed ToC for the VNF Requirements Document,

  6. Herb Patten

    Revised TOC for the VNF Requirements document 

    1. Purpose
    2. Scope
      1. (scope to R1 Use cases)
    3. Introduction
      1. Overview of the document, use of the requirements)
    4. VNF Development Requirements
      1. VNF Design
      2. VNF Resiliency
      3. VNF Security
      4. VNF Modularity
      5. Devops
    5. VNF Onboarding Requirements
      1. VNF Package Requirements
        1. TOSCA
          1. OpenStack Heat Guidelines
        2. Infrastructure Requirements
      2. Onboarding Process
    6. VNF Operational Requirements
      1. Introduction
        1. Platform options (VFC, APPC)
      2. Configuration Management
      3. Monitoring & Management
      4. Operational Commands
        1. Healthcheck
    7. Appendix
      1. Data Record Formats

  7. Andrei Kojukhov

    Hi Herb,

    I made two main changes in the TOC:

    1. Moved the VNF onboarding and packaging to the VNF management/operational requirements 
    2. Separated VNF modeling (TOSCA/HEAT) from the infrastructure, They are not connected and even more - we will have a multi-VIM component.

    For example we can have multiple cases working with TOSCA CSAR VNF package:

    • TOSCA model, Openstack infra
    • HEAT model, Openstack infra
    • Both TOSCA and HEAT models, Openstack infra
    • TOSCA model, Azure infra
    • etc.

    Andrei


  8. Andrei Kojukhov

    Please merge them with your last ToC version.

  9. shitao li

    Hi Andrei

     

    In general, your new ToC proposal is fine, I just want to clarify several things.

    1, on section 5, it distinguish the modeling requirements into TOSCA and heat, I think we need to be careful that this section only talks about modeling requirements not data modeling. Another thing is that some of the requirements can be considered as genereal requirements for both TOSCA and heat, so in section 5, I think we need another sub section on the top to descibe those general requirements.

     

    2, on section 6, I suggest discussing with Milti-VIM project, to make sure that we cover all their requirements. The information I got from them is that

    In R1, Multi VIM/Cloud team targets to deliver below backends:

    VIMs/Clouds:

    FOSS: OpenStack Ocata (vanila OpenStack)

    Commercial: OpenStack Mitaka (Wind River Titanium Cloud, VMware VIO), Azure

     

     

    shitao

  10. Andrei Kojukhov

    Agreed,

    Tks,

    Andrei

  11. Andrei Kojukhov

    I understand that the Document outline table is split into two: VNF Requirements and VNF Guidelines so why the 3 rows (I colored in red) relevant to VNF Guidelines are still missing in VNF Requirement outline?

  12. Herb Patten

    I edited the page to provide a .rst example for the VNF Requirements

  13. Herb Patten

    I edited the page to update the .rst example to make it easier to perform the editing that will need to be done. This format takes them out of table format which can be difficult to edit.