Re: [onap-tsc] [onap-discuss] Nomination Open for Open Lab Subcommittee

[zhang.maopeng1]

+1



















Original Mail



Sender:  
To:   
Date: 2017/06/27 12:24
Subject: [onap-tsc] [onap-discuss] Nomination Open for Open Lab Subcommittee






Dear Open Lab subcommitters:

 

According to the discussion on the last ONAP TSC meeting, The Open Lab 
Subcommittee has been formally approved. I would like to solicit 
self-nominations for the coordinator/chairperson of Open Lab Subcommittee.

Any member of the Open Lab Subcommittee may run for this position.  Please 
note, to indicate that you are a member of the Open Lab Subcommittee you *MUST* 
put your name and email address on the Open Lab Subcommittee Wiki page located 
here: https://wiki.onap.org/display/DW/Open+Lab+Subcommittee



The nomination period will end  4:00 AM UTC, Thursday, June 29.

 

To nominate, please respond to this email with your intention to run.

After the nomination period is closed, a voting poll will be set up for vote 
collection.



Thanks and Regards,

Chengli___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

[onap-tsc] 答复: Seed code for Service Orchestrator

[zhang.maopeng1]

hi eric




 Sorry, I don't preemail to the project contact person. I see in the wiki 
now the contact person is DeWayne Filppi (dewa...@gigaspaces.com),  right?




 We are an open community combined from openo and openecomp and other 
companies.

The SO seed code link from the both side can be provided. however in the 
wiki, the link is empty.  we should have a start point to contribute the 
infomation.   

 See the mutlvim project also provide the openo and ecomp seed code link, 
and other project wiki.

 So I provide the possible seed code link from the openo,  and just want to 
provide more infomation to project and have a good start to discuss the code. 

  The link from the ecomp mso also should be provided ASAP.

  Hope we are open and have an good discussion for the developers in the 
projects.



Best Regards

Maopeng



原始邮件



发件人： ＜eric.deb...@orange.com＞
收件人： ＜onap-tsc@lists.onap.org＞
日 期 ：2017年05月12日 03:48
主 题 ：[onap-tsc]  Seed code for Service Orchestrator







Hello


 


I am surprised to discover that open-o/gso is considered as the seed code for 
the Service Orchestrator.


 


As far as I know, we never decided such choice during the discussions last week 
and it should be a TSC decision.


 


Regards


 


Eric


_
  Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites 
ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez 
le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les 
messages electroniques etant susceptibles d'alteration, Orange decline toute 
responsabilite si ce message a ete altere, deforme ou falsifie. Merci.  This 
message and its attachments may contain confidential or privileged information 
that may be protected by law they should not be distributed, used or copied 
without authorisation. If you have received this email in error, please notify 
the sender and delete this message and its attachments. As emails may be 
altered, Orange is not liable for messages that have been modified, changed or 
falsified. Thank you.___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

[onap-tsc] 答复: Service Orchestrator project proposal

[zhang.maopeng1]

Hi DeWayne,


 


I am interested in and already committed to contributing to this project.


I am afraid that I am confused since there are two alternatives on the proposal 
page, but it said in release 1 the project will only demonstrate option 1( Only 
depend on App-C project)


Since we are interested in contributing option 2, I doubt it is still open for 
discussion? Or shall we document it in a separate project proposal instead?


 


Best Regards


Maopeng





原始邮件



发件人： ＜dewa...@gigaspaces.com＞
收件人： ＜onap-tsc@lists.onap.org＞
日 期 ：2017年05月15日 01:32
主 题 ：[onap-tsc] Service Orchestrator project proposal






ONAP TSC,  We would like to formally propose the SO (Service Orchestrator) 
project for ONAP. The proposal wiki page, which includes details of the project 
description, project scopes, and proposed repo names, can be found at:  
https://wiki.onap.org/display/DW/Service+Orchestrator.   The SO team consists 
of representatives from Cloudify, AT, Huawei, China Mobile, Ericsson, Orange, 
Amdocs, Nokia, and ZTE.
Thanks,

DeWayne Filppi
Director Solution Architecture
Gigaspaces/Cloudify
dewa...@gigaspaces.com
714.512.1706___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

[onap-tsc] 答复: Re: [Onap-arc] External controller support in BeijingRelease

[zhang.maopeng1]

hi Alla






 There are projects impact in the wiki. Could we refer it? thanks.






https://wiki.onap.org/pages/viewpage.action?pageId=11929755

Interface appearance:


Project Impact: 











BR


Maopeng



原始邮件



发件人： ;
收件人： ; ;
抄送人： ; ;
日 期 ：2017年10月10日 13:10
主 题 ：Re: [onap-tsc] [Onap-arc] External controller support in BeijingRelease








Thanks, Pam,


 


Here is the updated list with also one typo corrected.


 

AAI, incl. ESR

SDC, VNF SDK, Modelling

SO

VID

External API

 DCAE, HOLMES, Policy, CLAMP


 


 


Best regards,


 


Alla Goldner


 


Open Network Division


Amdocs Technology


 


 






 



From: DRAGOSH, PAMELA L (PAM) [mailto:pdrag...@research.att.com] 
 Sent: Monday, October 09, 2017 7:05 PM
 To: Alla Goldner ; onap-tsc@lists.onap.org P 

 Cc: onap-...@lists.onap.org; onap-usecase...@lists.onap.org
 Subject: Re: [Onap-arc] External controller support in Beijing Release




 


Alla,


 


If you intend to use the External Controller for any control loop use cases 
then you will need Policy.


 


With that being said, the request from the Policy team is a single common 
Controller SDK to be implemented by all controllers for performing any type of 
action on a VM/VNF. And as simplistic an API as possible. The current API 
implementations  for SO/APPC/VFC are overly complicated and require too much 
interaction with A


 


Thanks,


 


Pam


 



From:  on behalf of Alla Goldner 

 Date: Monday, October 9, 2017 at 11:50 AM
 To: "onap-tsc@lists.onap.org P" 
 Cc: "onap-...@lists.onap.org" , 
"onap-usecase...@lists.onap.org" 
 Subject: [Onap-arc] External controller support in Beijing Release



 


Hi all,


 


We (Usecase subcommittee) would like to initiate a discussion with a different 
involved projects on potential implementation of External controller in Beijing 
Release.


Next week, we need to present and get a view from the following affected 
projects:


 


1.   AAI, ESI


2.   SDC, VNF SDK


3.   Modelling


4.   SO


5.   VID


6.   External API


7.DCAE, HOLMES


8.   CLAMP


And, of course, from the architecture and modelling subcommittees.


 


(Ramesh, please add any potentially affected projects I may have forgotten).


 


One way is to schedule a new meeting. The alternative way is to ask Chris for 
Architecture subcommittee meeting’s time and discuss it there J


 


What do you think? Chris, is there any possibility to host this discussion next 
week?


 


Best regards, 


 


Alla Goldner


 


Open Network Division 


Amdocs Technology


 


 





 


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
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

[onap-tsc] 答复: Re: [onap-discuss] Official ONAP Architecture Slide

[zhang.maopeng1]

Hi  Susana,






  VFC project in R1 includes NFVO and VNFM components, mainly 
focused on the NS LCM and VNFLCM.


 NSLCM  NBI and GVNFM NBI  please refer to 
https://wiki.onap.org/display/DW/VF-C+R1+Deliverables  NSLCM API Specification 
v0.1.  and GVNFM API Specification v0.1.


 As the project started, NSLCM and GVNFM mainly refer to IFA 
document and refer to the SOL Draft, because the SOL does not provide engough 
APIs and is not published at that time.


 Now SOL003 is published and SOL005 is still in the draft(almost 
stable), I compare the API of the SOL, the main flow is same and most of LCM 
interfaces be aligned.


 In the following release, VFC team will plan to align the SOL as 
needed and also consider the usecase requirements.



 In the R1, VFC has more work on the integration with other ONAP 
componenst. The document is not well formatted, we will try to do it in the 
next release.


 If interested about VFC projects, welcome to join, thanks.





BR


Maopeng



原始邮件




发件人： ;
收件人： ; ; 
; ; 
; ;
日 期 ：2017年11月14日 22:25
主 题 ：Re: [onap-discuss] [onap-tsc] Official ONAP Architecture Slide








Hi,


 


Is it so that VF-C interfaces are not aligned with ETSI NFV ones? In the 
documentation of VF-C it appeared like aligned, but I observed  the reference 
is made to IFA007 and IFA008 and not to the published APIs, as opposed to 
referencing SOL005 for NS LCM.


In any case, it is difficult to find now the documentation of the VF-C; 
wouldn’t it be good to add relevant links to the modules, their  documentation, 
user guides, etc in the Amsterdam arch page?


 


Regards


/Susana


 

 

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of jamil.cha...@orange.com
 Sent: Tuesday, November 14, 2017 10:41 AM
 To: Kenny Paul ; onap-discuss 
; onap-tsc ; Arpit 
Joshipura (ajoship...@linuxfoundation.org) ; 
Lisa Caywood 
 Subject: Re: [onap-tsc] Official ONAP Architecture Slide




 


Hello Kenny


I have a question on the ETSI aligned of VFC module, to my knowledge the VFC 
interfaces are not aligned with ETSI NFV. 


I think we need to remove this term from VFC and to add that ONAP architecture 
is Functionally aligned with ETSI NFV..


Regards


Jamil


 



De : onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
De la part de Kenny Paul
 Envoyé : mardi 14 novembre 2017 01:04
 À : onap-discuss; onap-tsc
 Cc : Lisa Caywood
 Objet : [onap-tsc] Official ONAP Architecture Slide




 


As was pointed out in Paris there are too many variations of the Amsterdam 
architecture which is bad to say the least. 


The officially approved image for the Amsterdam Architecture and be found here:



https://wiki.onap.org/download/attachments/1015842/ONAP%20Amsterdam%20arch.png?api=v2



 


 


 


In preparation for the release announcement here is what we are asking in order 
of priority:



 



-If an archecture image is referecned in your official readthedocs 
documentation, please use this image 




 


-If an archecture image is referenced in your wiki pages,  please add the URL 
above to reference the the image.




 


-If an archecture image is referecned in a presentation slide deck, please 
ensure you use this image.




 


I am intentionally NOT distributing it because that is how we ended up with so 
many versions in the first place. :-)


 


Thanks!



 


 


 


Best Regards, 
 -kenny
 
 Kenny Paul,  Technical Program Manager
 kp...@linuxfoundation.org
 510.766.5945






 



_
   Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites 
ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez 
le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les 
messages electroniques etant susceptibles d'alteration, Orange decline toute 
responsabilite si ce message a ete altere, deforme ou falsifie. Merci.   This 
message and its attachments may contain confidential or privileged information 
that may be protected by law; they should not be distributed, used or copied 
without authorisation. If you have received this email in error, please notify 
the sender and delete this message and its attachments. As emails may be 
altered, Orange is not liable for messages that have been modified, changed or 
falsified. Thank 

[onap-tsc] 答复: RE: RE: Re: [onap-discuss] Official ONAP ArchitectureSlide

[zhang.maopeng1]

Hi Jamil


   


From the VFC project coming into ONAP, VFC focus on ETSI NFV implimention, 
which is well-known in the community.


In R1 arch, VFC marked with ETSI NFV is no problem, which can make the 
reader more clear about the main-contribution project.


Because VFC as one project in ONAP, so say ONAP implement ETSI NFV, it is 
OK as well.  But the mapping pre-shared really confuses the reader.


As I know ONAP scope is more the ETSI NFV, also SDN domain and service 
domain.





BR


Maopeng



原始邮件




发件人： ;
收件人：张茂鹏10030173; ;
抄送人： ; ; 
; ; 
;
日 期 ：2017年11月15日 23:47
主 题 ：RE: RE: Re: [onap-discuss] [onap-tsc] Official ONAP ArchitectureSlide







Hi Maopeng


I understand that it is not easy to map ETSI to ONAP architecture. But I don’t 
think by putting VFC aligned with ETSI NFV make any sense.


As we are in one project my preference is to mention that ONAP is a way to 
implement ETSI NFV functionalities.


Regards


jamil


 


 


De : zhang.maope...@zte.com.cn [mailto:zhang.maope...@zte.com.cn] 
 Envoyé : mercredi 15 novembre 2017 08:54
 À : CHAWKI Jamil IMT/OLN; christopher.don...@huawei.com
 Cc : kp...@linuxfoundation.org; onap-disc...@lists.onap.org
 Objet : 答复: RE: Re: [onap-discuss] [onap-tsc] Official ONAP Architecture Slide


 

Hi Jamil

 

As the reader, It will confus me about the mapping method.  It does not 
make sense.

About the interfaces, I have explained in the another email. 

VFC mainly focus on the NSLCM and VNFLCM, which mainly is align to the ETSI 
NFV LCM related interfaces. 

VFC also provides the driver to adaptor more vendor VNFM to do the 
integration. 

 

BR

Maopeng


原始邮件



发件人： ;



收件人：张茂鹏10030173;



抄送人： ; ;



日 期 ：2017年11月14日  19:54



主 题 ：RE: Re: [onap-discuss] [onap-tsc] Official ONAP Architecture Slide




 


Hi Maopeng

In slide 9 you have a  first mapping of ONAP architecture to ETSI NFV one.  

For APPC stream NFVO is distributed between SO and DCAE. The VNFM is also 
distributed in SO, APPC and DCAE.

Regards

Jamil


 


De : zhang.maope...@zte.com.cn [mailto:zhang.maope...@zte.com.cn] 
 Envoyé : mardi 14 novembre 2017 11:44
 À : CHAWKI Jamil IMT/OLN
 Cc : kp...@linuxfoundation.org; onap-disc...@lists.onap.org
 Objet : 答复: Re: [onap-discuss] [onap-tsc] Official ONAP Architecture Slide


 

Hi jamil

  

   One quick question:

   How is the ONAP architecture Functionally aligned with ETSI NFV?  Which 
components are NFVO and VNFM in the ONAP aligned   with ETSI NFV?

   Thanks

 

BR

Maopeng


原始邮件



发件人： ;



收件人： ; ;   
; ;  
;



日 期 ：2017年11月14日  17:43



主 题 ：Re: [onap-discuss] [onap-tsc] Official ONAP Architecture Slide




 



Hello Kenny


I have a question on the ETSI aligned of VFC module, to my knowledge the VFC 
interfaces   are not aligned with ETSI NFV.


I think we need to remove this term from VFC and to add that ONAP architecture 
is Functionally   aligned with ETSI NFV.


Regards


Jamil


 



De : onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
De la part de Kenny Paul
 Envoyé : mardi 14 novembre 2017 01:04
 À : onap-discuss; onap-tsc
 Cc : Lisa Caywood
 Objet : [onap-tsc] Official ONAP Architecture Slide




 


As was pointed out in Paris there are too many variations of the Amsterdam 
architecture which is bad to say the least. 


The officially approved image for the Amsterdam Architecture and be found here:



https://wiki.onap.org/download/attachments/1015842/ONAP%20Amsterdam%20arch.png?api=v2



 


 


 


In preparation for the release announcement here is what we are asking in order 
of priority:



 



-If an archecture image is referecned in your official readthedocs 
documentation, please use this image 




 


-If an archecture image is referenced in your wiki pages,  please add the URL 
above to reference the the image.




 


-If an archecture image is referecned in a presentation slide deck, please 
ensure you use this image.




 


I am intentionally NOT distributing it because that is how we ended up with so 
many versions in the first place. :-)


 


Thanks!



 


 


 


Best Regards, 
 -kenny
 
 Kenny Paul,  Technical Program Manager
 kp...@linuxfoundation.org
 510.766.5945






 




_
  Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites 
ou copies sans autorisation. Si vous 

[onap-tsc] 答复: [Onap-arc] 答复: [arch] Corrections for the architecture document.

[zhang.maopeng1]

+1


The original P7 version seems better.






BR


Maopeng







原始邮件




发件人： ;
收件人： ;
抄送人： ; ;
日 期 ：2017年11月24日 09:19
主 题 ：[Onap-arc] 答复: [onap-tsc]  [arch] Corrections for the architecture 
document.






___
Onap-arc mailing list
onap-...@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-arc

  

Hello


 Agree to the update of P9,P10,P11. And also agree to remove D2 term.


 But I don’t think the update to P7 is more suitable, the original 
version seems better.


 


Best regards


 



发件人: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
代表 eric.deb...@orange.com
 发送时间: 2017年11月24日  4:04
 收件人: onap-tsc@lists.onap.org; onap-...@lists.onap.org
 主题: [onap-tsc] [arch] Corrections for the architecture document.




 


Hello


 


Please find some corrections for the Architecture document


https://www.onap.org/wp-content/uploads/sites/20/2017/11/ONAP_CaseSolution_Architecture_FNL.pdf


 


As noticed by Nermin, the D2 term should be removed from Figure 1


 


P7. Controllers


I think the VF-C definition is not exact according to existing R1 code.


“Also, the Virtual Function Controller (VF-C) provides an ETSI NFV compliant 
NFV-O function, and is responsible for lifecycle  management of virtual 
services and the associated physical COTS server infrastructure. VF-C provides 
a generic VNFM capability but also integrates with external VNFMS and VIMs as 
part of a NFV MANO stack.”


 


We propose to replace by “The Virtual Function Controller (VF-C) is responsible 
for managing the lifecycle of VNF  when this cannot be achieved by other 
components  of the ONAP architecture and for managing the lifecycle of network 
services that comprise at least one of such VNF. It can also processes fault 
and performance management events to trigger the ONAP closed loops.“


 


P9 vCPE use-case


“Similarly, ONAP uses the APP -C component to manage the virtualization 
infrastructure.”


ð  “Similarly, ONAP uses the APP -C component to manage the VNF lifecycle“


 


P10&11 References/Links to the  use case white papers are missing


“Read the Residential vCPE Use Case with ONAP whitepaper to learn more.”


“Read the VoLTE Use Case with ONAP whitepaper to learn more.”


 


Best Regards


 


Eric

_
   Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites 
ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez 
le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les 
messages electroniques etant susceptibles d'alteration, Orange decline toute 
responsabilite si ce message a ete altere, deforme ou falsifie. Merci.   This 
message and its attachments may contain confidential or privileged information 
that may be protected by law; they should not be distributed, used or copied 
without authorisation. If you have received this email in error, please notify 
the sender and delete this message and its attachments. As emails may be 
altered, Orange is not liable for messages that have been modified, changed or 
falsified. Thank you.___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

[onap-tsc] 答复: Re: [Onap-arc] ONAP Architecture presentation

[zhang.maopeng1]

Hi Chris


   


 The work is done. The project proposel can be gotten in the following wiki 
pages:


  https://wiki.onap.org/display/DW/Run-Time+Catalog


  https://wiki.onap.org/display/DW/November+21


  https://wiki.onap.org/display/DW/Contributions










BR


Maopeng



原始邮件




发件人： ;
收件人： ; ; 
; ; 
; ;
日 期 ：2017年11月22日 04:14
主 题 ：Re: [onap-tsc] [Onap-arc] ONAP Architecture presentation








It’s available under the Architecture Subcommittee page on the wiki (with 
recording):


https://wiki.onap.org/display/DW/November+21


 


Some of the slides have already been uploaded, but I received two last-minute 
requests for slots and I haven’t seen those slides yet.  LiZi and Maopeng, 
would you please upload them to the Contributions page? 
https://wiki.onap.org/display/DW/Contributions


 


 


Chris


 



From: onap-arc-boun...@lists.onap.org [mailto:onap-arc-boun...@lists.onap.org] 
On Behalf Of jamil.cha...@orange.com
 Sent: Tuesday, November 21, 2017 9:40 AM
 To: Alla Goldner ; Pasi Vaananen 
; Stephen Terrill ; 
onap-...@lists.onap.org; onap-tsc@lists.onap.org
 Subject: Re: [Onap-arc] ONAP Architecture presentation




 


+1


And also a short summary of the meeting 


Best 


Jamil


 



De : onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
De la part de Alla Goldner
 Envoyé : mardi 21 novembre 2017 18:32
 À : Pasi Vaananen; Stephen Terrill; onap-...@lists.onap.org; 
onap-tsc@lists.onap.org
 Objet : Re: [onap-tsc] [Onap-arc] ONAP Architecture presentation




 


+1 and including TSC list for a broader discussion of this issue.


 


One of the problems we face is that there are multiple locations where 
presentations are uploaded (f uploaded), e.g. under Usecase or Architecture 
subcommittee, in a dedicated project area etc. 


 


In my view, the best way to support visibility of all submitted documents is to 
have a single placeholder as done by a different SDO e.g. 3GPP, ETSI NFV – and 
then it may be further distinguished there by subject,  submitter, targeted 
subcommittee/project etc.


 


Best regards, 


 


Alla Goldner


 


Open Network Division 


Amdocs Technology


 


 






 



From: onap-arc-boun...@lists.onap.org [mailto:onap-arc-boun...@lists.onap.org] 
On Behalf Of Pasi Vaananen
 Sent: Tuesday, November 21, 2017 7:06 PM
 To: Stephen Terrill ; onap-...@lists.onap.org
 Subject: Re: [Onap-arc] ONAP Architecture presentation




 

+1 

... but this should not be limited only to architecture team presentations.

Pasi


 


On 11/21/2017 12:00 PM, Stephen Terrill wrote:



Hi Chris,


 


Can I make a suggestion regarding the presentations in the ONAP Architecture 
team. Sometimes the presentation cannot be found afterwards.  I think it’s a 
common practice in a few  foras that the documentation has to be uploaded 
before being presented, can we assume the same practice here ?


 


BR,


 


Steve


 


 



 
 
 


STEPHEN TERRILL 
 Technology Specialist 
 DUIC, Systems and Technology 
 Development Unit IP & Cloud


Business Unit, IT & Cloud Products



 Ericsson
 Ericsson R Center, via de los Poblados 13
 28033, Madrid, Spain
 Phone +34 339 3005
 Mobile +34 609 168 515
 stephen.terr...@ericsson.com
 www.ericsson.com 



 
 


 


Legal entity: Ericsson España S.A, compay registration number ESA288568603. 
This Communication is Confidential. We only send and receive email on the basis 
of the  terms set out at www.ericsson.com/email_disclaimer 


 



 
 
 

___ Onap-arc mailing list 
onap-...@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-arc 
 


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



_
   Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites 
ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez 
le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les 
messages electroniques etant susceptibles d'alteration, Orange decline toute 
responsabilite si ce message a ete altere, deforme ou falsifie. Merci.   This 
message and its attachments may contain confidential or privileged information 
that may be protected by law; they should not be distributed, used or copied 
without authorisation. If you have received this email in error, please notify 
the sender and delete this message 

[onap-tsc] [Onap-tsc][Onap-arc] About RT-Catalog agenda item

[zhang.maopeng1]

Dear Kenny and Mazin









   


 I see today's TSC agenda item, "RT Catalog project proposal Vote".


As RTC project contactor, the following green lines are my three concerns, 
which are still not gotten consensus in the ARC meeting.


My opinion is that RTC should be a project stand alone.  I suggest we 
cancel RTC vote as subproject.   Thanks


 


   The following are my concerns, which are copied from previous mail  in the 
ARC list in order to be easily read:


  "


I have read the meeting notes of ARC January 
30(https://wiki.onap.org/display/DW/January+30) . The following is three 
concerns from me. If something is wrong, please correct me. 


First: in last week TSC meeting, RTC is clear a stand alone project. TSC 
give job to ARC to discuss the project software impact to other projects.


Before the ARC meeting, I arrange  couple of meetings with Alex, 
Jason, Michael, Ting and Sanjay, and also get the feedbacks and concerns from 
them.  



As I present the slide in the ARC, it well explained the software 
impacts and the comminity concerns. If more concerns or new comments comes, we 
can continue to discuss.






   Second: in the ARC meeting, the subproject is talked again.  Based on the R2 
releasing, some people suggest RTC as subproject in R2, and in R3 make it as 
separate project. 


 But now, RTC has not been approved, and will not be published 
in the R2.  So we just target on R3,  and suggest RTC as a seperate project.






  Third:  I got some feedback from other companies, there are some other 
technical choice on implementation. I think we need more work on details of the 
technology selection to achieve the RT-Catalog. To encourage more contribution 
and diversity of  ONAP project,  we suggest RT Catalog as a seperate project, 
not a subproject.


  "






BR


Maopeng







发件人：张茂鹏10030173
收件人： ;
抄送人： ; ;
日 期 ：2018年01月31日 23:20
主 题 ： [Onap-arc] About RT-Catalog meeting notes




Hi Chris






 Add the topic name of email. 


 Thanks all for joining the RTC discussion.






BR


Maopeng










发件人：张茂鹏10030173
收件人： ;
抄送人： ;
日 期 ：2018年01月31日 17:24
主 题 ：[Onap-arc] (no subject)


___
Onap-arc mailing list
onap-...@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-arc


Hi Chris




I have read the meeting notes of ARC January 
30(https://wiki.onap.org/display/DW/January+30) . The following is three 
concerns from me. If something is wrong, please correct me. 

First: in last week TSC meeting, RTC is clear a stand alone project. TSC 
give job to ARC to discuss the project software impact to other projects.

Before the ARC meeting, I arrange  couple of meetings with Alex, 
Jason, Michael, Ting and Sanjay, and also get the feedbacks and concerns from 
them.  


As I present the slide in the ARC, it well explained the software 
impacts and the comminity concerns. If more concerns or new comments comes, we 
can continue to discuss.




   Second: in the ARC meeting, the subproject is talked again.  Based on the R2 
releasing, some people suggest RTC as subproject in R2, and in R3 make it as 
separate project. 

 But now, RTC has not been approved, and will not be published 
in the R2.  So we just target on R3,  and suggest RTC as a seperate project.




  Third:  I got some feedback from other companies, there are some other 
technical choice on implementation. I think we need more work on details of the 
technology selection to achieve the RT-Catalog. To encourage more contribution 
and diversity of  ONAP project,  we suggest RT Catalog as a seperate project, 
not a subproject.




BR

Maopeng___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

[onap-tsc] 答复: RE: RT-Catalog project proposal

[zhang.maopeng1]

Dear Jamil






We have made the agreement on the ARCH meeting.  


https://wiki.onap.org/display/DW/January+16


RT Catalog

Received ARC endorsement to proceed with TSC proposal








Suggest to discuss the detail of integration with all projects after the 
project is aprroved and started.


Thanks for your concern.






BR


Maopeng



原始邮件



发件人： ;
收件人：张茂鹏10030173; ; ; 
;
抄送人： ; ; ; 
;
日 期 ：2018年01月17日 17:26
主 题 ：RE: [onap-tsc]  RT-Catalog project proposal




Daer Maopeng


We have agreed in the architecture Subcommittee to evaluate the impact of the 
RT Catalog on other technical modules (SO, APPC, VFC, SDNC …) .


My preference will be to wait the output of this evaluation before to present 
this project at the TSC level.


Regards


Jamil


·  


 


 


 


De : onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
De la part de zhang.maope...@zte.com.cn
 Envoyé : mercredi 17 janvier 2018 10:19
 À : kp...@linuxfoundation.org; ma...@research.att.com; onap-tsc@lists.onap.org
 Cc : tl2...@att.com; sa2...@att.com; atul.puroh...@vodafone.com
 Objet : [onap-tsc] RT-Catalog project proposal


 

Dear TSC,

 


We have presented the RT-Catalog project proposal during the Developer 
Conference in Santa Clara and there are some concerns about overlapping of the 
RT-Catalog with SDC project. Also the project needed endorsement  from 
architecture subcommittee. Now we have been reached a consensus with SDC team 
and endorsed by architecture committee. We updated our project proposal in wiki 
page based on the discussions of this days  


https://wiki.onap.org/display/DW/Run-Time+Catalog


 


Both SDC and the architecture committee  agree that the differentiation is 
clear now and recommend this project to be presented at the TSC this Thursday, 
Jan 18 2018. We also have the necessary 3+ companies in  the 
contributor/committer list. 


 


Please arrange a slot for RT-Catalog project proposal, I would like to present. 
Thanks!


 

BR

Maopeng





_
 Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites 
ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez 
le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les 
messages electroniques etant susceptibles d'alteration, Orange decline toute 
responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This 
message and its attachments may contain confidential or privileged information 
that may be protected by law; they should not be distributed, used or copied 
without authorisation. If you have received this email in error, please notify 
the sender and delete this message and its attachments. As emails may be 
altered, Orange is not liable for messages that have been modified, changed or 
falsified. Thank you.___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

[onap-tsc] 答复: Re: [modeling] ONAP R2 IM to DM design

[zhang.maopeng1]

Hello


   


   6. VNFD: https://jira.onap.org/browse/MODELING-72


According to the time limited, CMCC and ZTE as volunteers will corperate to 
take the classes for R2 needed.






BR


Maopeng



原始邮件



发件人：denghui(L) 
收件人：onap-disc...@lists.onap.org onap-tsc 

抄送人：Rittwik Jana 
日 期 ：2018年03月10日 09:51
主 题 ：Re: [onap-tsc] [modeling] ONAP R2 IM to DM design


___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

  

Hello all


 


Currently, only 1,2,3,5 have been take, many thanks to Ericsson/Intel/Huawei


we still missing contributor for 4,6,7, R2 DM spec aligned with IM need to be 
finalized before next Tuesday modeling call.


 


Please help to volunteer


 


Thanks a lot


 


DENG Hui


 



From: denghui (L) 
 Sent: Thursday, March 8, 2018 8:46 PM
 To: onap-disc...@lists.onap.org; 'onap-tsc' 
 Cc: Rittwik Jana ; 'Lingli Deng' 

 Subject: [modeling] ONAP R2 IM to DM design




 


Hello all


 


As agreed in modeling subcommittee meeting, we need to update the onap types of 
the data model to reflect the agreements reached in information model.


 


It’s huge work to achieve the goal, in order to accelerate, 7 separate tasks 
have been created based on the current IM. We encourage interested people to 
volunteer to take the lead  for particular task.


 


The tasks including:


1. VDU: https://jira.onap.org/browse/MODELING-67


2. HPA: https://jira.onap.org/browse/MODELING-68


3. CP: https://jira.onap.org/browse/MODELING-69


4. DeploymentFlavor: https://jira.onap.org/browse/MODELING-70


5. VL: https://jira.onap.org/browse/MODELING-71


6. VNFD: https://jira.onap.org/browse/MODELING-72


7. monitor: https://jira.onap.org/browse/MODELING-73


 


It’s expected that the lead would help provide tosca definitions on the 
contribution page 
(https://wiki.onap.org/display/DW/Data+Model+align+with+TOSCA+NFV+Profile) and


help implement related logic in SDC, APPC/VFC projects.


 


Thanks a lot


 


DENG Hui___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc