Phil, Team I am absolutely hoping we can close on those use cases and have the TSC vote on a prioritized list to take forward.
As we document the use cases, I want to remind the team that of my previous communication 1. ONAP is delivering a platform. The use cases are general frameworks to vet the platform and should not be considered as certified services. 2. The use cases need to help drive the merged code which is the goal of R1. This is very important. The use cases should not promote divisions between open source ECOMP and Open_O. Although I do agree with Lingli that we can not force the community, but the TSC votes on the projects based on the basis to ensure a successful merged code, including to support APP-C and VF-C 3. Use case framework should be separated into simple work flows and aspiration goals. R1 is successful whether or not we meet an aspiration goal as long as we meet the simple work flows (e.g.,, instantiation and simple closed loop) 4. I encourage VNF vendors to provide support for open-source and commercial VNFs per guidelines I shared last week. This is a great opportunity for vendors to demonstrate their leadership in this space and alignment with ONAP Thanks Mazin Get Outlook for iOS<https://aka.ms/o0ukef> _____________________________ From: Lingli Deng <[email protected]<mailto:[email protected]>> Sent: Tuesday, June 6, 2017 10:27 AM Subject: Re: [onap-tsc] Making progress on firming up use-cases for ONAP R1 To: 'Phil Robb' <[email protected]<mailto:[email protected]>>, GOLDNER, ALLA <[email protected]<mailto:[email protected]>>, FREEMAN, BRIAN D <[email protected]<mailto:[email protected]>>, 'wangchengli' <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>>, SPATSCHECK, OLIVER (OLIVER) <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>>, BEGWANI, VIMAL <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>>, KLUGER, YOAV <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>>, '??' <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>> Cc: 'onap-tsc' <[email protected]<mailto:[email protected]>> 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 [ Phil Robb [mailto:[email protected]] Sent: 2017年6月6日 7:04 To: Alla Goldner < Alla Goldner <[email protected]<mailto:[email protected]>>; Brian Freeman <[email protected]<mailto:[email protected]>>; wangchengli <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Lingli Deng <[email protected]<mailto:[email protected]>>; SPATSCHECK, OLIVER <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; ?? <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: Casey Cain <[email protected]<mailto:[email protected]>>; Kenny Paul <[email protected]<mailto:[email protected]>>; onap-tsc <[email protected]<mailto:[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<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_Release-2B1-2BUse-2BCases&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=IKSC5mg8GeOiSar1dax3GQ&m=pEcRMDdkquuv8pPzg4ID1-m8hsQ2bxGc76mzLXPWFdI&s=rC5rXgEbRbj7n78wQwow0HzRba9FunMPhl0dxwHIpQU&e=> The vCPE Use Case: https://wiki.onap.org/display/DW/Use+Case%3A+Residential+Broadband+vCPE<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_Use-2BCase-253A-2BResidential-2BBroadband-2BvCPE&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=IKSC5mg8GeOiSar1dax3GQ&m=pEcRMDdkquuv8pPzg4ID1-m8hsQ2bxGc76mzLXPWFdI&s=h5Vq7XDjtcIrPNGzeGLNDTjyMQgFC-1wkFWhm1W9DFY&e=> The VoLTE Use Case: https://wiki.onap.org/pages/viewpage.action?pageId=3246140<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_pages_viewpage.action-3FpageId-3D3246140&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=IKSC5mg8GeOiSar1dax3GQ&m=pEcRMDdkquuv8pPzg4ID1-m8hsQ2bxGc76mzLXPWFdI&s=OLJeuqlwp1iUEbaj_xGco5ZI0_pRsVHfmqR251LrI3o&e=> 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
