Hi Alla
I agreed to Yuan’s point, it’s too hard to make decision without clear
requirements/description for UseCase.
My understanding for the clear UseCase requirement is, assume ONAP as a black
box, then need to define: the input/output and outside components, and what
action/function for ONAP in beijing release.
The more members, the more difficult to reach any decision, so it will be
helpful, if UseCase subcommittee can define a more clear description for the
UseCase.
It’s too challenge for TSC or project to make plan based on a wish-list that
may cross more than 1 releases.
Best regards
发件人: [email protected] [mailto:[email protected]]
代表 Alla Goldner
发送时间: 2017年11月9日 20:47
收件人: [email protected]
抄送: [email protected]; [email protected]; [email protected];
[email protected]; [email protected]
主题: Re: [onap-tsc] Usecase subcommittee meeting Nov 6 - themeeting'ssummary
Hi Yuan,
We can definitely consider this, though I believe that the specific information
you require below belongs to the next level of details. Perhaps even more
points will be raised when we present it.
And, as I said, this is “endorsement” not “approval”, and definitely needs
future work/refining by a different projects. The question I was asked about is
whether one or another requirement is indeed considered for Beijing, and this
is why it is important to start bringing those requirements for the TSC.
Best regards,
Alla Goldner
Open Network Division
Amdocs Technology
[cid:[email protected]]
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]]
Sent: Thursday, November 09, 2017 12:09 PM
To: Alla Goldner <[email protected]<mailto:[email protected]>>
Cc: [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]>
Subject: 答复: RE: Re: [onap-tsc] Usecase subcommittee meeting Nov 6 -
themeeting'ssummary
Hi Alla,
Thank for your reply, it's clear to me. I does not object we bring the
requirements to TSC for approval but from my view, the requirements need next
level of detials before it goes to component design. The requirements looks too
generic for different project teams reaching consensus on what they should
design. My proposal is use case subcommittee should add some examples into
usecase which would help developers understand related requirement. Like we add
which PNF we should model and manage, what kind of API the PNF support for
management, CLI, SNMP or restful? It does not mean the PNF requirement is
specific to this PNF, it works to help people understand what problem they are
facing.
Maybe we can let TSC make the decision where the refining work would be took
place.
Regards,
Yuan Yue
袁越 yuanyue
资深战略规划师 Senior Strategy Planner
技术规划部/技术规划部/系统产品 Technology Planning Dept./Technology Planning Dept./System
Product
[cid:[email protected]]
[cid:[email protected]]
南京市雨花区软件大道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]<mailto:[email protected]>
www.zte.com.cn<http://www.zte.com.cn/>
原始邮件
发件人： <[email protected]<mailto:[email protected]>>;
收件人：袁越10008526;
抄送人： <[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]>>;
日 期 ：2017年11月08日 16:24
主 题 ：RE: Re: [onap-tsc] Usecase subcommittee meeting Nov 6 - themeeting'ssummary
Hi Yuan,
Thanks a lot for your questions. I provide my answers below embedded into your
text. Please let me know if you have any follow-up questions.
Best regards,
Alla Goldner
Open Network Division
Amdocs Technology
[cid:[email protected]]
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]]
Sent: Wednesday, November 08, 2017 4:59 AM
To: Alla Goldner <[email protected]<mailto:[email protected]>>
Cc: [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]>
Subject: RE: Re: [onap-tsc] Usecase subcommittee meeting Nov 6 - the
meeting'ssummary
Hi Alla and all,
Two points for clarification:
1. Please correct me if I misunderstand your conclusion on 5G requirements
part. The text on this item looks like all 5G requirerments except Conflict
resolution will be part of Beijing release. But during the discussion I heard
many times the requirements are long term not fixed to Beijing release. My
understanding is we do have these requirements like 5G network slicing include
vNFs and PNFs, but it is really hard to decide how far each project can go in
Beijing Release based on the description of the requirements this days. May I
propose that usecase subcommittee accept these requirement as phased output.
The implementaion plan for different requirements in future releases, Beijing
or some others, would be decided after comprehensive discussing with PTLs.
Personally I think developing teams would ask for more detail info about the
requirement items. AG> Usecase subcommittee doesn’t decide on including
specific requirements into one or another Release, fully agree with you. Use
case subcommittee receives the use cases, and responsible to extract functional
and non-functional requirements, mostly on “what” and not “how”, while “how”
would be defined by the projects themselves. For all the requirements, we
define whether they are defined with sufficient level of details for bringing
to TSC discussion. In some cases, some additional discussions with
architecture/modelling subcommittees are required. In case we find requirement
as ready to be presented to tSC for endorsement we do so. Then, if TSC endorses
the requirement, it will be up to each one of the projects to define the next
level of details.
2. I humbly ask what kind of endorsement usecase subcommittee is expecting
from TSC? I remember Mazin has mentioned that Beijing release would not be
driven by use cases in previous TSC weekly meeting. Beijing release will focus
on carrer-grade enhancement with existing use cases and new use cases could be
tested in if integration team could accept. I don't know if use case
subcommittee has talked with Integration team on testing of the use case and
related requirement? AG> yes, Beijing Release focus is on carrier grade, this
is one of the major reasons we decided to move forward with a separate
requirements, strengthening the platform and improving its quality, not with
the full new use cases implementation. Eventually, once requirements are
approved by the TSC, Usecase subcommittee along with the Integration team will
see if there is possibility to showcase new use cases composed from those
newly introduced requirements, but we are not there yet.
Best Regards,
Yuan Yue
袁越 yuanyue
资深战略规划师 Senior Strategy Planner
技术规划部/技术规划部/系统产品 Technology Planning Dept./Technology Planning Dept./System
Product
[cid:[email protected]]
[cid:[email protected]]
南京市雨花区软件大道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]<mailto:[email protected]>
www.zte.com.cn<http://www.zte.com.cn/>
原始邮件
发件人： <[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]>>;
日 期 ：2017年11月07日 22:42
主 题 ：Re: [onap-tsc] Usecase subcommittee meeting Nov 6 - the meeting'ssummary
Hi all,
Thanks to all meeting’s participants! Please find the meeting summary below and
vVoLTE use cases status attached to this email.
1. R1 use cases status
a. Please see the attachment about vVoLTE status (Yang’s report)
b. Regarding R-vCPE (Kang’s report)
i. The team
has been testing and fixing various kinds of bugs over the weekend
ii. As of Mon
1pm EST, we almost passed the custom workflow test. One last bug to fix but the
solution is known. The plan is to fully retest the flows on Tue afternoon. We
did use manual set up and hacks in multiple places. Hopefully we will finishing
all test items later this week.
2. R2 requirements proposals
a. VNF scaling use case/requirements presentation took place. Some follow
up questions were asked. Steve Wright and his team will work on extending
functional requirements and bringing them to the next Usecase subcommittee
meeting. Alla will make sure team gets all related information on how those
requirements should be written and presented
b. Recent additional inputs on requirements extracted from 5G use cases.
Lots of work was recently done to extend requirements description and add
commitment section. It was agreed during the discussion that Conflict
resolution requirement will be delayed (will not be a part of Beijing Release),
while the rest of the requirements will be added to the TSC endorsement request
this week. Team will prepare several slides covering those requirements
c. E-vCPE ONAP Atomic Capability Management was presented by Luman.
Follow-up questions were asked and was decided it requires more discussions.
Luman will bring extended E-vCPE requirements for the next meeting and also
discuss this specific new requirement by emails/bring it for more discussions
next time.
d. Vodafone has requested time during the next meeting to present
Centralized parsers distribution related requirements
Best regards,
Alla Goldner
Open Network Division
Amdocs Technology
[cid:[email protected]]
This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer
This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer
This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer
_______________________________________________
ONAP-TSC mailing list
[email protected]
https://lists.onap.org/mailman/listinfo/onap-tsc
