Agenda:
Antitrust Policy Statement: Meetings of the ONAP Project involve participation by industry competitors, and it is the intention of the Project to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of and not
participate in any activities that are prohibited under applicable U.S. state, federal or foreign antitrust and competition laws. Examples of types of actions that are prohibited at ONAP Project meetings and in connection with ONAP Project activities are described in the The Linux Foundation Antitrust Policy. If you have questions about these matters, please contact your company counsel or Andrew Updegrove, of the firm of Gesmer Updegrove LLP, which provides legal counsel to The Linux Foundation.
Linux Foundation Antitrust Policy: https://www.linuxfoundation.org/antitrust-policy
- Assemble/Welcome (5 min)
# | Objective | How Achieved | Participant Preparation required | Action items out |
---|---|---|---|---|
2 | Review JIRA Backlog. Participants should be comfortable that they understand the backlog of tasks for our project ( 15 min) | Walk through the JIRA backlog to check for completeness on VNF RQTs https://jira.onap.org/browse/VNFRQTS-134 I am not sure to understand how this is impacting Amsterdam Release? | review: | |
3 | Develop Beijing Release project plan for VNFRQTS . Participants should be comfortable with an achievable development scope ( 30 min) | VNF Use cases ? VNF Test Case Descriptions? | propose a minimal "getting started" sprint scope. ensure that suitable JIRA tasks are already in place to support this scope. review: | Create / edit |
4. Any other Business? (5 min)
2 Comments
wenyao guan
Please discussing the modified content of the Guidelines document:
Part I : Purpose and Scope modification
Purpose
• This document focuses on setting and evolving VNF standards that will facilitate industry discussion, participation, alignment and evolution towards comprehensive and actionable VNF best practices and standard interface.
• The goal is to accelerate adoption of VNF best practices which will increase innovation, minimize customization needed to onboard VNFs as well as reduce implementation complexity, time and cost for all impacted stakeholders.
• The intent is do drive harmonization of VNFs across VNF providers, Network Cloud Service providers (NCSPs) and the overall Network Function Virtualization (NFV) ecosystem by providing both long term vision as well as short term focus and clarity.
Scope
• The audience for this document are VNF providers, NCSPs and other interested 3rd parties who need to know the design, build and lifecycle management requirements for VNFs to be compliant with ONAP.
• These guidelines describe VNF environment and provide an overview of what the VNF developer needs to know to operate and be compliant with ONAP.
• These guidelines are applicable to the Amsterdam release of ONAP.• Scope of the ONAP versions/release and future functionality• Conformance requirements are in the requirements document.
Part II
VNFs updates and upgrades within ONAP
ONAP will orchestrate updates and upgrades of VNFs. The One
targetmethod for updates and upgrades is to onboard and validate the new
version, then build a new instance with the new version of software,
transfer traffic to that instance and kill the old instance. There
should be no need for the VNF or its components to provide an
update/upgrade mechanism.
Part III
Guest Operating Systems
VNFs should use the NCSP’s standard set of OS images to enable compliance with security, audit, regulatory and other needs.
Modification option 1:
NCSPs could require that VNFs
shoulduse the NCSP’s standard set of OS images to enable compliance with security, audit, regulatory and other needs.Modification option 2:
It could be desirable for VNFs to be able to run on the GuestOS recommended by NCSPs to enable the compliance with security, audit, regulatory and other needs.
Steven Wright
All components in ONAP should be virtualized, preferably with support for both virtual machines and containers. All components should be software-based with no requirement on a specific hardware platform.
To enable the compliance with security, audit, regulatory and other needs, NCSPs may operate a limited set of guest OS and CPU architectures and families, virtual machines, etc.
VNFCs should be agnostic to the details of the Network Cloud (such as hardware, host OS, Hypervisor or container technology) and must run on the Network Cloud with acknowledgement to the paradigm that the Network Cloud will continue to rapidly evolve and the underlying components of the platform will change regularly.