Hi Phil,
Thanks for bringing this forward.
Those are two key issues as you identified below, but not necessarily
interrelated together IMHO.
- Identify the use cases, and the VNFs needed to support them
- Including what organization/vendor will be supporting each VNF
This is what is documented in our release plan and would be a pre-requirement
for us to fully understand the work ahead of us for Release 1.
We have done with VoLTE usecase (vIMS+vEPC) with 7 member companies, and would
appreciate community review and approval so that we can move on and keep pace
with the release plan.
- Identify VNF requirements regarding ONAP interaction.
- Clearly define and document the Modeling, call-flow, and architectural
requirements for integrating VNFs into ONAP.
This is what the ONAP community would be providing as the official
documentation (via Architecture sub-committee, various implementation projects,
including the proposed VNF SDK, modeling, VNF Requirements and Certification
Projects) after or as part of Release 1.
- Do we want to stipulate VNFs must run on both VF-C and APPC or is it OK to
run on one and not the other? If they need to run on both, what flow/modeling
variations are preferable/acceptable? If not, then do we, or how do we allow
and/or manage Services that need to rely on a collection of hybrid VF-C/APPC
based VNFs?.. obviously with the constant goal of not making the system more
complex and prone to errors than we have to.
As an open source community, we should welcome what people is willing to
contribute, while avoid dictating what they must do in order to participate.
Hence my suggestion would be NOT making it a MUST, otherwise it would
effectively closing the door for people who want to contribute, which is
violating the open source culture.
Lingli
From: Phil Robb [mailto:[email protected]]
Sent: 2017年6月6日 7:04
To: Alla Goldner <[email protected]>; Brian Freeman <[email protected]>;
wangchengli <[email protected]>; [email protected];
[email protected]; [email protected]; Lingli Deng
<[email protected]>; SPATSCHECK, OLIVER <[email protected]>;
[email protected]; [email protected]; [email protected];
[email protected]; [email protected]; ?? <[email protected]>;
[email protected]
Cc: Casey Cain <[email protected]>; Kenny Paul
<[email protected]>; onap-tsc <[email protected]>
Subject: Making progress on firming up use-cases for ONAP R1
Hello ONAP Use Case Subcommittee Members:
Now that this group is formed, we have some work ahead of us. We are looking
to firm up the Use Cases, and exactly what VNFs will be used for testing
Release-1 and we have several critical action items that need resolution. I
suggest we discuss this in detail while at the Face to Face meeting this
Thursday and Friday. Some of the key questions and activities include:
- Identify the use cases, and the VNFs needed to support them
- Including what organization/vendor will be supporting each VNF
- Some VNFs have clearly identified people/organizations supporting them.
Others do not.
- Identify VNF requirements regarding ONAP interaction.
- Clearly define and document the Modeling, call-flow, and architectural
requirements for integrating VNFs into ONAP.
- Do we want to stipulate VNFs must run on both VF-C and APPC or is it OK
to run on one and not the other? If they need to run on both, what
flow/modeling variations are preferable/acceptable? If not, then do we, or how
do we allow and/or manage Services that need to rely on a collection of hybrid
VF-C/APPC based VNFs?.. obviously with the constant goal of not making the
system more complex and prone to errors than we have to.
Key Resources for this work are:
The Release-1 Use Case Wiki Page:
https://wiki.onap.org/display/DW/Release+1+Use+Cases
The vCPE Use Case:
https://wiki.onap.org/display/DW/Use+Case%3A+Residential+Broadband+vCPE
The VoLTE Use Case: https://wiki.onap.org/pages/viewpage.action?pageId=3246140
Realizing that the Use Case Subcommittee, the Modeling Group, and the
Architecture Subcommittee are all groups meant to inform the TSC, gathering
representatives from these three groups early on at the face to face may be
helpful to build an informed recommendation to the TSC on how best to proceed
with regard to Release-1 Use Cases implementations and the VNFs to be used to
accomplish them.
For those on this thread that represent VNF vendors, or groups that may be
willing to support Open Source based VNFs for during the testing phases of ONAP
Release-1, please fee free to reach out to Kenny Paul (cc-ed) or myself. We
are collecting contact information for candidate VNFs for release one (and
beyond) so that we can keep all VNF Stakeholders up to date regarding
expectations and future plans for VNF support from the ONAP platform.
Thanks in advance to all for your help with this work. Coming to closure on
these issues is a significant milestone for us to reaching our Release-1 goals.
Best,
Phil.
--
Phil Robb
Executive Director, OpenDaylight Project
VP Operations - Networking & Orchestration, The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb
_______________________________________________
ONAP-TSC mailing list
[email protected]
https://lists.onap.org/mailman/listinfo/onap-tsc
