Yuan, let me separate things a bit.
The way I look at it is that there is a set of use cases which gate the success of the release. Those use cases have a set of VNFs. I completely agree with you that ONAP should support many commercial VNFs. In fact I would like all commercial VNFs to be supported by ONAP that’s the ultimate goal of AT&T, however, that does not mean that all of them have to be part of the set of VNFs used for the use case which gates the release. Now let’s focus on the VNFs which gate the release as the others can be worked using proprietary or bilateral agreements. As stated below I don’t know how to do that efficiently. That doesn’t mean there isn’t a solution. So if you can outline one that would be great. I see three main challenges: 1. Developer access to VNFs. From experience you can speed up development substantially if you give developers access to an integration environment. It’s nice to develop against specs but I have never seen a complex project (inside or outside of AT&T) which just worked based on developers working against specs. That’s where the whole agile idea comes from. Integration testing becomes an integral part of your development. So one way of fixing this is to give access to an IST level environment to the developers. That’s the approach we took with open sourcing ECOMP. Without that our demo use case would probably still not be working. So now if we use a commercial VNF how do we get developers these environments? E.g. AT&T has multiple development teams and we dynamically provided them what they needed on Rackspace to open source ECOMP. There are two solutions to this in my mind: a.) We have a shared lab where all developers perform all the IST testing. If we want to follow this approach we have to answer the following questions: Considering the substantially larger scale then Open-O do we have a lab that can support ALL developers by 6/29? Who would provide that? Does the shared lab really have enough instances to not slow development down? Does that lab have a license which would allow them to give first hand access to e.g. an Ericsson (sorry just picked somebody randomly for illustrative purposes) developer to a Huawei or ZTE VNF? Would e.g. Ericsson allow there developers to access that VNF or would they be afraid of IP entanglement if they did? Do we have to worry about any international export control or anti trust laws doing this? Again all those questions need to be answered by 6/29 to make this work for the first release and I have seen little discussion on this so far. b.) Each organization developing provides it’s own integrated testing environment to it’s developers. That would mean e.g. AT&T needs to run all those VNFs in it’s own internal lab. Of course AT&T wouldn’t pay for that after all we are providing free code to the community so we wouldn’t pay license fees to a vendor to do so. In this case are the VNF vendors willing to license there VNFs to ALL ONAP contributors for free in support of ONAP development? Are those license agreements reasonable enough (e.g. limited indemnification if software gets stolen) for the ONAP development teams to actually sign? Can all of this be completed by 6/29? 2. Another problem is around final acceptance testing of the release. I am a strong believer that if others can’t repeat something it doesn’t really exists. E.g. in physics a phenomena is only true if more then one DIVERSE team was able to observe it. I strongly believe software testing needs to follow the same objective. So how would we set up repeatable testing of commercial VNFs which can be performed by more then one diverse team? The possible approaches are similar then the once outlined above. 3. The last one is around demos. E.g. one things which I think has been fairly well received (based on the feedback I got) is the fact that you can try the ECOMP part of ONAP on Rackspace EASILY. I know we are still working on the generic open stack setup but the fact that so many people are asking for it is an indication that people want to “kick the tiers” of ONAP in there own environment. Again how would we address this need with proprietary VNFs? Without delivering VNFs with the use case ONAP is just a huge amount of code doing nothing …. . Or to put it differently. A wise man told me once: “ People don’t want platforms they want solutions!” if we can’t demo a solution as part of the release openly people will be very disappointed. Again I don’t see a practical way of addressing this in the time given (e.g. I know for example that even a free license agreement with AT&T generally requires negotiations in the risk and IP area). If you know one could you please outline it so the community can understand what the plan is in detail? Thx Oliver > On May 17, 2017, at 3:27 AM EDT, [email protected] wrote: > > 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 > > > > > <9ae3e214c17d49ed935d87c674ba3ee2.jpg> > <24242e5637af428891c4db731e7765ad.jpg> > 南京市雨花区软件大道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: [email protected] > www.zte.com.cn > 原始邮件 > 发件人： ＜[email protected]＞; > 收件人： ＜[email protected]＞; > 日 期 ：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 > > > > > > Project Potential Scope Overlapp > AAI > APPC Common Controller… , VF-C > Authentication… > CLAMP Modeling > Common Controller … VF-C, App-C, SDN-C, ONAP Operations Manager, > Microservice Bus, DCAE, DMAAP, MultiVIM, Service Orchestration > DCAE Holmes, Common Controller…, DMAAP > DMAAP Common Controller… , DCAE (mentions data processing) > Documentation ONAP University > External API Framework Modeling, External System Register, ONAP > Extensibility > External System Register External API Framework, ONAP Extensibility > Holmes DCAE > ICE VNF-SDK > Integration ONAP Operations Manager > Microservice Bus Common Controller …, ONAP Operations Manager > Modeling CLAMP > Miulti Vim Common Controller… > Network Function Change.. > ONAP CLI > ONAP Extensibility ONAP Operations Manager, External API Framework, > External System Register > ONAP University Documentation > ONAP Operations Manager Common Controller… , Integration, Onap > Extensibility > ONAP Usecase UI Project > Policy Driven VNF Orchestartion Policy Framework, SNIRO > Policy Framework… Policy Driven VNF Orchestration > Portal Platform … > SDN-C Common Controller… > Service Design & Creation Modeling > Service Orchestration Common Controller… > SNIRO Policy Driven VNF Orchestration > VF-C Common Controller… , App-C > VID > VNF-SDK ICE > > > > _______________________________________________ ONAP-TSC mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-tsc
