Hi Oliver and all,
My answer to " I wouldn’t even know how that worked in practice. E.g. will
those VNFs be available to competing vendors so they can test/develop ONAP
code?"
We have already finished VoLTE testing in Open-O project with vIMS and vEPC
comes from Huawei, ZTE and Ericsson. There was no problem using this
proprietary vNFs for testing in Open-O. We also commit in ONAP community ZTE
will provide our vNF packages with limited license for testing purpose.
Deploying and managing vendor vNFs brings practical value to ONAP community.
Anyway, target of ONAP project should be deploying and managing more commercial
vNFs. I believe vNFs from companies other than ZTE and Huawei are also
welcome for the VoLTE usecase.
Best Regards,
Yuan Yue
袁越 yuanyue
资深战略规划师 Senior Strategy Planner
技术规划部/技术规划部/系统产品 Technology Planning Dept./Technology Planning Dept./System
Product
南京市雨花区软件大道50号中兴通讯3号楼1/F,Building 3, ZTE Nanjing R&D Center II, No.50, Software
Avenue,YuHua District,Nanjing,P.R.China 210012
T: +025 88013478
M: +86 13851446442
E: yuan....@zte.com.cn
www.zte.com.cn
原始邮件
发件人： ＜spat...@research.att.com＞
收件人： ＜onap-tsc@lists.onap.org＞
日 期 ：2017年05月17日 03:47
主 题 ：[onap-tsc] Thoughts on next steps.
I just went through the proposals and noticed that quite a few of them have not
clearly defined boundaries between them which makes me wonder if they overlap
(see table below). From experience overlapping project definitions rarely lead
to good outcomes (duplicate work gets done and people are very upset at the
end…) so I think we should resolve this before approving the projects.
When I built this table I focused on what’s written in the proposals. Now from
discussions I think some of the perceived overlaps might just be a matter of
cleaning up the writing. Others might actually be real. In either case I think
we need to be clear and precise in the project description and can’t rely on
various email exchanges for this. I also don’t claim that my table is
complete. If you want I can put the table on the Wiki so people can add there
perceived or real overlaps.
I don’t know how you usually resolve those issues but I would think that the
project leads for all projects which might have an overlap define a common
statement which defines there relationship with each other in some level of
detail. Thoughts?
I also looked at the use cases. Lingli and her team did a great job cleaning up
the VoLTE use case:
https://wiki.onap.org/pages/viewpage.action?pageId=3246140
The flow charts are a great start but we do need to get into more details and
actually show the real API calls as well. I am also not sure I understand how
exactly the legacy Open-O and legacy ECOMP components integrate. I think the
next step here is to walk through this in detail. I don’t think that’s
something that can be done efficiently via email. I would suggest a call on the
topic. That might actually be better then a F2F in June as it allows more
developers to dial in.
One concern on this particular use case is that only Huawei and ZTE have any
VNFs in it. Personally I don’t think it’s a good start for an open project to
start with proprietary VNFs from mainly one manufacturer with some contribution
from a second. I wouldn’t even know how that worked in practice. E.g. will
those VNFs be available to competing vendors so they can test/develop ONAP code?
This brings me to overall use case scope and reality.
Using Gilda’s release plan (all his fault after all :)) we have to work all of
this out by 6/29 (sounds a lot of time but really isn’t). Development is only 3
months till RC0. We have 32 projects. That’s 21 projects more then the seed
code of 8+3. If I ignore the toy use case we have two use cases proposed with
the VoLTE one having more details then the other. Coordinating interfaces one
on one for the 32 projects requires 512 meetings. …. I think if we are trying
to achieve all of this in release 1 we are setting ourselves up for failure.
If it was up to me I would probably just focus the use cases on instantiation
and one simple control loop. This might seem like very little but considering
the work we need to start the projects, set up the labs, get developers
familiar with the environment, get them lab access etc… which all takes time.
I think that would be realistic for a first release and then we can adjust the
second release accordingly.
In terms of projects I would be very careful which projects have deliverables
in release 1.0. . I don’t think having deliverable in release 1.0 is a gating
function of getting a project approved. So the TSC can approve projects that
make sense but as said I would discourage some of them to have a contribution
to the 1.0 release.
Probably just stating the obvious … .
Oliver
ProjectPotential Scope OverlappAAI
APPCCommon Controller… , VF-CAuthentication…
CLAMPModelingCommon Controller …VF-C, App-C, SDN-C, ONAP Operations Manager,
Microservice Bus, DCAE, DMAAP, MultiVIM, Service OrchestrationDCAEHolmes,
Common Controller…, DMAAPDMAAPCommon Controller… , DCAE (mentions data
processing)DocumentationONAP UniversityExternal API FrameworkModeling, External
System Register, ONAP ExtensibilityExternal System RegisterExternal API
Framework, ONAP ExtensibilityHolmesDCAEICEVNF-SDKIntegrationONAP Operations
ManagerMicroservice BusCommon Controller …, ONAP Operations
ManagerModelingCLAMPMiulti VimCommon Controller…Network Function Change..ONAP
CLI
ONAP ExtensibilityONAP Operations Manager, External API Framework, External
System RegisterONAP UniversityDocumentationONAP Operations ManagerCommon
Controller… , Integration, Onap ExtensibilityONAP Usecase UI Project
Policy Driven VNF OrchestartionPolicy Framework, SNIROPolicy Framework…Policy
Driven VNF OrchestrationPortal Platform …
SDN-CCommon Controller…Service Design & CreationModeling Service
OrchestrationCommon Controller…SNIROPolicy Driven VNF OrchestrationVF-CCommon
Controller… , App-CVID
VNF-SDKICE
_______________________________________________
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc
