Re: [onap-tsc] Casablanca Architecture presentation question

[Yuan Yue]

Hi Chris,


SOL-003 is the interface and data-model of or-vnmf reference point which means 
between NFVO and VNFM. If SO provides SO-003 in southbound, does this imply SO 
is providing NFVO function in Casablanca no matter for POC purpose or as an 
stable delivery?  It is clear VFC has provided the NFVO functionality then what 
is the relationship of the NFVO in SO and the NFVO in VFC?  If these two NFVOs 
in ONAP are same functionality and different implementation? 


I am not objecting the idea that we have two NFVOs in ONAP. I just want to make 
it clear. I am neutral on having different approaches for one same component in 
open source practice. If this is accepted as a principle of ONAP, I am OK with 
that.  



















Yuan Yue

Senior Strategy Planner



Technology Planning Dept./Technology Planning Dept./System Product


 


ZTE Corporation


No.50, Software Ave, Nanjing, 210012, P. R. China


T: +86 25 88013621  M: +86 13851446442


E: yuan@zte.com.cn


www.zte.com.cn








原始邮件



发件人：ChristopherDonley 
收件人：John Quilty Zengjianguo (OSS Design) 
张茂鹏10030173;
抄送人：ONAP-TSC@lists.onap.org Stephen Terrill 
anatoly.andria...@nokia.com 
gil.bull...@att.com 
日 期 ：2018年07月24日 05:10
主 题 ：Re: [onap-tsc] Casablanca Architecture presentation question


My understanding is that SO will include a Proof of Concept to support SOL-003 
in the Casablanca release.  This does not change any support for VNFMs in VF-C. 
It only demonstrates support for SVNFMs in operator environments that are not 
using VFC, supporting  the Casablanca theme of "Deployability".

 
Because the SOL-003 support was described as a POC for Casablanca, and the team 
wanted to make sure it didn't affect S3P before merging it with the main 
branch, SOL-003 was listed as a recommendation on slide 8, but not included in 
the SO section on pages  10-11 so as not to confuse external audiences 
regarding the availability of the interface.  

 
Let's discuss on tomorrow's call to make sure the deck is accurate and clear.

 
Chris





 
 
From: John Quilty 
 Date: Monday, July 23, 2018 at 2:27 AM
 To: "Zengjianguo (OSS Design)" , maopeng 

 Cc: "ONAP-TSC@lists.onap.org" , Chris Donley 
,  Stephen Terrill 
, "anatoly.andria...@nokia.com" 
,  "gil.bull...@att.com" 
 Subject: RE: [onap-tsc] Casablanca Architecture presentation question
 

 
 



Hi Zeng


 


Yes we agree that the VFC has a role to play in the ETSI-ONAP alignment, 
however the following was also presented  in the architecture F2F 
(https://wiki.onap.org/download/attachments/8225716/Proposed%20ETSI%20ONAP%20Alignment%20Regarding%20Scaling%20-%20Vancouver%20v6.pptx?api=v2),
  and various steps had being presented before to the architecture team.


 To my understanding this was agreed and rolled up into the architecture 
requirements.  The wording of the architectural requirements 
(https://wiki.onap.org/display/DW/Casablanca+Release+Requirements).   Please 
note, that as this was approved under architectural alignment, it doesn’t need 
an approved use case.


 


Chris, Anatoly, Gil, does this align with your understanding?


 


Regards


John


 


 



From: Zengjianguo (OSS Design)  
 Sent: 21 July 2018 10:03
 To: maopeng ; John Quilty 
 Cc: ONAP-TSC@lists.onap.org; Christopher Donley (Chris) 

 Subject: 答复: [onap-tsc] Casablanca Architecture presentation question




 


Hi


+1 on maopeng’s  comments.


We already do a lot in ONAP R1 & R2, and plan continue work on ETSI NFV 
alignment in VFC during  ONAP R3. So why and in which usecase to try to do it 
in another way?


I agree ONAP as platform , should be flexible and there may be more than one 
choice to one  same/similar feature, but may I suggest to try PoC in R3, and 
show what the difference/advantage firstly, then do the following steps..


 


Zeng JianGuo


 


 


发件人:ONAP-TSC@lists.onap.org  [mailto:ONAP-TSC@lists.onap.org] 代表 maopeng
 发送时间:  2018年7月20日  9:41
 收件人:john.qui...@ericsson.com
 抄送:ONAP-TSC@lists.onap.org;  Christopher Donley (Chris) 

 主题:答复:  [onap-tsc] Casablanca Architecture presentation question


 

Hi John

   

Very interested in the ETSI SOL related discussion:

 

 Some backgrounds from my experiences in VFC project and SO project:

 In ONAP R1, There is SOL005 interface between the SO and VFC, and 
SOL003 between the VFC and VNFM(vendor or GVNFM).

 In ONAP R2,  VFC has started the work to align the latest SOL 
interface. please see the JIRA: https://jira.onap.org/browse/VFC-635 and  
commit some codes. In ONAP R3, VFC will continue to do the work.

 In the VFC there already extists the vendor VNFM driver and do the 
implication enhancement.

 

 If interested the ETSI SOL interfaces and avoid creating a new wheels, 
suggest working together in the VFC team and collaborating with each other.

 Does it make sense?  thanks

 

BR

Maopeng


原始邮件



发件人：JohnQ 



收件人：ONAP-TSC@lists.onap.org  
christopher.don...@huawei.com 




日 期 

Re: [onap-tsc] Casablanca Architecture presentation question

[Christopher Donley]

My understanding is that SO will include a Proof of Concept to support SOL-003 
in the Casablanca release.  This does not change any support for VNFMs in VF-C. 
It only demonstrates support for SVNFMs in operator environments that are not 
using VFC, supporting the Casablanca theme of "Deployability".

Because the SOL-003 support was described as a POC for Casablanca, and the team 
wanted to make sure it didn't affect S3P before merging it with the main 
branch, SOL-003 was listed as a recommendation on slide 8, but not included in 
the SO section on pages 10-11 so as not to confuse external audiences regarding 
the availability of the interface.

Let's discuss on tomorrow's call to make sure the deck is accurate and clear.

Chris

From: John Quilty mailto:john.qui...@ericsson.com>>
Date: Monday, July 23, 2018 at 2:27 AM
To: "Zengjianguo (OSS Design)" 
mailto:zengjian...@huawei.com>>, maopeng 
mailto:zhang.maope...@zte.com.cn>>
Cc: "ONAP-TSC@lists.onap.org" 
mailto:ONAP-TSC@lists.onap.org>>, Chris Donley 
mailto:christopher.don...@huawei.com>>, Stephen 
Terrill mailto:stephen.terr...@ericsson.com>>, 
"anatoly.andria...@nokia.com" 
mailto:anatoly.andria...@nokia.com>>, 
"gil.bull...@att.com" 
mailto:gil.bull...@att.com>>
Subject: RE: [onap-tsc] Casablanca Architecture presentation question

Hi Zeng

Yes we agree that the VFC has a role to play in the ETSI-ONAP alignment, 
however the following was also presented  in the architecture F2F 
(https://wiki.onap.org/download/attachments/8225716/Proposed%20ETSI%20ONAP%20Alignment%20Regarding%20Scaling%20-%20Vancouver%20v6.pptx?api=v2),
 and various steps had being presented before to the architecture team.
 To my understanding this was agreed and rolled up into the architecture 
requirements.  The wording of the architectural requirements 
(https://wiki.onap.org/display/DW/Casablanca+Release+Requirements).  Please 
note, that as this was approved under architectural alignment, it doesn’t need 
an approved use case.

Chris, Anatoly, Gil, does this align with your understanding?

Regards
John


From: Zengjianguo (OSS Design) 
mailto:zengjian...@huawei.com>>
Sent: 21 July 2018 10:03
To: maopeng mailto:zhang.maope...@zte.com.cn>>; John 
Quilty mailto:john.qui...@ericsson.com>>
Cc: ONAP-TSC@lists.onap.org; Christopher Donley 
(Chris) mailto:christopher.don...@huawei.com>>
Subject: 答复: [onap-tsc] Casablanca Architecture presentation question

Hi
+1 on maopeng’s  comments.
We already do a lot in ONAP R1 & R2, and plan continue work on ETSI NFV 
alignment in VFC during ONAP R3. So why and in which usecase to try to do it in 
another way?
I agree ONAP as platform , should be flexible and there may be more than one 
choice to one same/similar feature, but may I suggest to try PoC in R3, and 
show what the difference/advantage firstly, then do the following steps..

Zeng JianGuo


发件人:ONAP-TSC@lists.onap.org 
[mailto:ONAP-TSC@lists.onap.org] 代表 maopeng
发送时间: 2018年7月20日 9:41
收件人:john.qui...@ericsson.com
抄送:ONAP-TSC@lists.onap.org; Christopher Donley 
(Chris) mailto:christopher.don...@huawei.com>>
主题:答复: [onap-tsc] Casablanca Architecture presentation question


Hi John



Very interested in the ETSI SOL related discussion:



 Some backgrounds from my experiences in VFC project and SO project:

 In ONAP R1, There is SOL005 interface between the SO and VFC, and 
SOL003 between the VFC and VNFM(vendor or GVNFM).

 In ONAP R2,  VFC has started the work to align the latest SOL 
interface. please see the JIRA: https://jira.onap.org/browse/VFC-635 and commit 
some codes. In ONAP R3, VFC will continue to do the work.

 In the VFC there already extists the vendor VNFM driver and do the 
implication enhancement.



 If interested the ETSI SOL interfaces and avoid creating a new wheels, 
suggest working together in the VFC team and collaborating with each other.

 Does it make sense?  thanks



BR

Maopeng
原始邮件
发件人：JohnQ mailto:john.qui...@ericsson.com>>
收件人：ONAP-TSC@lists.onap.org 
mailto:ONAP-TSC@lists.onap.org>>christopher.don...@huawei.com
 mailto:christopher.don...@huawei.com>>
日 期 ：2018年07月19日22:02
主 题 ：[onap-tsc] Casablanca Architecture presentation question

Hi Chris

Thanks for pulling this together.  Two quick observation/questions

 The work on the standards alignment could be clearer on where it is impacting 
on Casablanca. On Slide 8 it is easy to miss the targeted SOL003 VNFM plugin 
for SO.



I just have a quick question should the slide from 9 onwards reflect the 
proposed changes in Casablanca? If so the VNFM plug-in to SO could be better 
reflected in 10 and 11. I would suggest reflecting that the VNF LCM interface 
that  SO consumes 

Re: [onap-tsc] CALL FOR NOMINATIONS: ONAP TSC ELECTION

[Christopher Donley]

Dear TSC,

I would like to self-nominate for a seat on the TSC.  Over the past year, I 
have made 166 commits, created 79 wiki pages, and created 262 Jira tickets: 
https://onap.biterg.io/goto/e5ac923846d3f306d72a7ae70429a3bb

In ONAP, I have been active chairing the Architecture Subcommittee and leading 
the VNFSDK project.  I also chair the LFN Compliance & Verification Committee, 
and previously chaired the OPEN-O TSC.  I have also worked on network standards 
and specifications since 2006, including through IETF, MEF, ETSI, and 
CableLabs.  Having participated in ONAP (and similar communities) through 
multiple roles, I bring knowledge and experience to help the TSC deliver our 
releases on time by focusing on building our community and supporting our 
developers through improvements to our tools and development processes.

I hold an MBA in Technology Management from the University of Colorado and a BA 
in Engineering from Dartmouth.

Chris

[X]

From: mailto:ONAP-TSC@lists.onap.org>> on behalf of 
Kenny Paul mailto:kp...@linuxfoundation.org>>
Date: Tuesday, July 17, 2018 at 5:02 PM
To: onap-tsc mailto:ONAP-TSC@lists.onap.org>>
Subject: [onap-tsc] CALL FOR NOMINATIONS: ONAP TSC ELECTION

Nominations for seats on the ONAP TSC officially open @ 17:00 Pacific Time, 
Tuesday, July 17, 2018
If you are interested in running for a seat on the TSC, please read all of this 
information carefully


Who is eligible to Run:  Any Active Community Members as of 17:00 Pacific Time, 
Tuesday, July 17, 2018- There is NO limit to the number of candidates from any 
single company that can run for a seat.

4.1.1.1 TSC Membership 
Definitions
  Active Community Member: Anyone from the ONAP community with twenty (20) or 
more measurable contributions during the previous 12-month period, inclusive of 
code merged, code reviews performed, wiki page edits, or JIRA activities



Self-Nomination Phase


Individuals interested in running for a TSC position MUST REPLY-ALL TO THIS 
ORIGINAL EMAIL with your intention to run before 17:00 Pacific time, July 31st.

NOTE: Replying to another candidate's self-nomination email announcing your own 
self-nomination is considered a blatant disregard for open source community 
norms. If you do that, you should probably re-assess both your qualifications 
and motivations for leading a collaborative community such as this.

Your self-nomination email must include a link to your stats in Bitergia 
(instructions on how to do 
this).
It is strongly recommended that candidates also include a small head-shot, a 
short biography and statement of intent on why you would be a good person to 
hold a seat on the TSC.


As a courtesy, it is also requested that you fill in the  2018 TSC Election 
Candidates wiki 
pagewith that same information. Filling out the wiki page is NOT in lieu of 
sending the email as required, but it will greatly help facilitate the process 
of the elections.



Special Provision for the original 9 ONAP Operators:  There are 9 seats 
reserved for the nine original ONAP Platinum Service Provider members. Each of 
these Operators is REQUIRED to have at least one person nominate themselves for 
their seat on the TSC. If and only if an Operator does not have any eligible 
Active Community Members at the time of nomination process, they may appoint a 
nominee to run in the election.  In such cases, the nominee must indicate that 
they are exercising a provisional nomination in their email. (Refer to 4.2.3.2 
TSC Member 
Candidates)
·
· The nomination phase begins 17:00 Pacific Time, Tuesday, July 17, 2018
· The nomination phase ends 17:00 Pacific Time, Tuesday, July 31, 2018
·

Election Phase



Who is eligible to Vote: Any Active Community Members as of 17:00 Pacific Time, 
Tuesday, July 17, 2018

A Condorcet election will be held using the CIVS voting 
system.  Active 
Community Members will receive an invitation to vote from CIVS.
· The election phase will begin with the distribution of the CIVS poll 
via email from the application
· The election phase will end two (2) weeks later in the same time zone 
the poll was initiated from

Election Results
·

  *   The election of TSC Members shall consist of a single stack ranked vote 
of all candidates
  *   Only the top ranked candidates from any single company will be elected; 
if the top 10 vote getters are all from the same company, only the person with 
the highest number of votes out of all 10 will be elected from that company.
  *   The top ranked candidate from 

[onap-tsc] meeting on 23/7/2018 - the summary

[Alla Goldner]

Hi,

During today's meeting, we reviewed integration test cases and status for:


1.   CCVPN

2.   Scaling

We also briefly discussed the same for 5G and Change management requirements.

During the next meeting, we will  complete these categories and also review:


1.   OSAM

2.   HPA

3.   Cloud regions

4.   Edge automation

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D422CE.8D950CF0]

From: Alla Goldner
Sent: Friday, July 20, 2018 3:40 PM
To: 'onap-usecase...@lists.onap.org' 
Cc: onap-tsc ; onap-disc...@lists.onap.org
Subject: Agenda for 23/7/2018

Hi all,

As discussed last meeting, we will dedicate the upcoming meeting to use 
cases/functional teams discussions with the Integration team representatives on 
the test cases and flows' readiness and Open questions.

Use case/functional requirements leaders - please let me know, if possible in 
advance, if you would like to cover your topic during the upcoming meeting.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D422CE.8D950CF0]

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 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#3490): https://lists.onap.org/g/ONAP-TSC/message/3490
Mute This Topic: https://lists.onap.org/mt/23795909/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/ONAP-TSC/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[onap-tsc] PNF PnP Onboarding (Onap Beijing)

[Danut Gita via Lists.Onap.Org]

Hello,

Do you know if is possible to make a PNF PnP onboarding in Onap Beijing 
release? I don't need to use a VNF.
I have a CPE and I want to connect to ONAP but I don't know if the PNF function 
works.

Thanks.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#3489): https://lists.onap.org/g/ONAP-TSC/message/3489
Mute This Topic: https://lists.onap.org/mt/23795201/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/ONAP-TSC/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-tsc] #modeling Mapping between Modeling and Casablanca R3 requirements

[denghui (L)]

Hi Gildas

I had added a column here and fill in the PTL's feedback on the limited 
requirements.
https://wiki.onap.org/display/DW/ONAP+R3+Modeling+High+Level+Requirements

thanks for your help

DENG Hui

From: Gildas Lanilis
Sent: Thursday, July 19, 2018 11:45 PM
To: denghui (L) 
Cc: ONAP-TSC@lists.onap.org; onap-disc...@lists.onap.org; GILBERT, MAZIN E 
(MAZIN E) 
Subject: #modeling Mapping between Modeling and Casablanca R3 requirements

Hi Deng,

This is to follow up on the need to understand "what else" is required from a 
Modelling perspective for Casablanca Release.
Could you help into performing the mapping between the list in "ONAP R3 
Modeling Level 
Requirements"
 and the "Casablanca Release 
Requirements"?
So far what has been approved for the Scope of Casablanca is documented 
here.

I would recommend to add a column in the "ONAP R3 Modeling Level 
Requirements"
 indicating which Casablanca Release Requirement it refers to.
The plan is to review and discuss this with PTLs during Monday PTL meeting at 6 
am PDT.

Let me know if I can help.

Thanks,
Gildas

[HuaweiLogowithName]
Gildas Lanilis
ONAP Release Manager
Santa Clara CA, USA
gildas.lani...@huawei.com
Mobile: 1 415 238 6287


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#3488): https://lists.onap.org/g/ONAP-TSC/message/3488
Mute This Topic: https://lists.onap.org/mt/23745408/21656
Mute #modeling: https://lists.onap.org/mk?hashtag=modeling=2743226
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/ONAP-TSC/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-tsc] Casablanca Architecture presentation question

[John Q]

Hi Zeng

Yes we agree that the VFC has a role to play in the ETSI-ONAP alignment, 
however the following was also presented  in the architecture F2F 
(https://wiki.onap.org/download/attachments/8225716/Proposed%20ETSI%20ONAP%20Alignment%20Regarding%20Scaling%20-%20Vancouver%20v6.pptx?api=v2),
 and various steps had being presented before to the architecture team.
 To my understanding this was agreed and rolled up into the architecture 
requirements.  The wording of the architectural requirements 
(https://wiki.onap.org/display/DW/Casablanca+Release+Requirements).  Please 
note, that as this was approved under architectural alignment, it doesn’t need 
an approved use case.

Chris, Anatoly, Gil, does this align with your understanding?

Regards
John


From: Zengjianguo (OSS Design) 
Sent: 21 July 2018 10:03
To: maopeng ; John Quilty 
Cc: ONAP-TSC@lists.onap.org; Christopher Donley (Chris) 

Subject: 答复: [onap-tsc] Casablanca Architecture presentation question

Hi
+1 on maopeng’s  comments.
We already do a lot in ONAP R1 & R2, and plan continue work on ETSI NFV 
alignment in VFC during ONAP R3. So why and in which usecase to try to do it in 
another way?
I agree ONAP as platform , should be flexible and there may be more than one 
choice to one same/similar feature, but may I suggest to try PoC in R3, and 
show what the difference/advantage firstly, then do the following steps..

Zeng JianGuo


发件人: ONAP-TSC@lists.onap.org 
[mailto:ONAP-TSC@lists.onap.org] 代表 maopeng
发送时间: 2018年7月20日 9:41
收件人: john.qui...@ericsson.com
抄送: ONAP-TSC@lists.onap.org; Christopher Donley 
(Chris) mailto:christopher.don...@huawei.com>>
主题: 答复: [onap-tsc] Casablanca Architecture presentation question


Hi John



Very interested in the ETSI SOL related discussion:



 Some backgrounds from my experiences in VFC project and SO project:

 In ONAP R1, There is SOL005 interface between the SO and VFC, and 
SOL003 between the VFC and VNFM(vendor or GVNFM).

 In ONAP R2,  VFC has started the work to align the latest SOL 
interface. please see the JIRA: https://jira.onap.org/browse/VFC-635 and commit 
some codes. In ONAP R3, VFC will continue to do the work.

 In the VFC there already extists the vendor VNFM driver and do the 
implication enhancement.



 If interested the ETSI SOL interfaces and avoid creating a new wheels, 
suggest working together in the VFC team and collaborating with each other.

 Does it make sense?  thanks



BR

Maopeng
原始邮件
发件人：JohnQ mailto:john.qui...@ericsson.com>>
收件人：ONAP-TSC@lists.onap.org 
mailto:ONAP-TSC@lists.onap.org>>christopher.don...@huawei.com
 mailto:christopher.don...@huawei.com>>
日 期 ：2018年07月19日 22:02
主 题 ：[onap-tsc] Casablanca Architecture presentation question

Hi Chris

Thanks for pulling this together.  Two quick observation/questions

 The work on the standards alignment could be clearer on where it is impacting 
on Casablanca. On Slide 8 it is easy to miss the targeted SOL003 VNFM plugin 
for SO.



I just have a quick question should the slide from 9 onwards reflect the 
proposed changes in Casablanca? If so the VNFM plug-in to SO could be better 
reflected in 10 and 11. I would suggest reflecting that the VNF LCM interface 
that  SO consumes is SOL003 on slide 10 and 11.



Regards

 John





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#3487): https://lists.onap.org/g/ONAP-TSC/message/3487
Mute This Topic: https://lists.onap.org/mt/23791374/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/ONAP-TSC/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-tsc] [onap-discuss] [modeling] Minutes of SDC review of high level requirement

[denghui (L)]

Information model has been presented and approved by modeling subcommittee, but 
Data Model hasn’t,
please work with SDC to improve the DM design and come back to modeling 
subcommittee when you are ready.

Thanks a lot

DENG Hui

From: Lando,Michael [mailto:ml6...@intl.att.com]
Sent: Monday, July 23, 2018 12:57 AM
To: huang.zhuo...@zte.com.cn; yangxu (H)
Cc: denghui (L); onap-disc...@lists.onap.org; ONAP-TSC@lists.onap.org
Subject: RE: Re: [onap-tsc] [onap-discuss] [modeling] Minutes of SDC review of 
high level requirement

The issue is reusability you need to review all the definitions you are trying 
to create and I identify the component that are already available.

Based on my review I see duplications in the node type so my answer is this 
need to be reviewed again.

In addition I am still not clear if this was presented to the modeling 
subcommittee and did it get approved by them?








BR,

[Michael Lando]

AT Network Application Development · NetCom
Tel Aviv | Tampa | Atlanta | New Jersey |Chicago
···
Office: +972 (3) 5451487
Mobile: +972 (54) 7833603
e-mail: michael.la...@intl.att.com

From: huang.zhuo...@zte.com.cn 
Sent: Thursday, July 19, 2018 03:55
To: yang...@huawei.com; Lando,Michael 
Cc: denghu...@huawei.com; onap-disc...@lists.onap.org; ONAP-TSC@lists.onap.org
Subject: 答复: Re: [onap-tsc] [onap-discuss] [modeling] Minutes of SDC review of 
high level requirement




Hello all,



 Thanks Yang XU for clarifying about the state of Wan Connection.

 To Michael, if we leverage the relationship types and capability 
types which are already existed and remove the new ones which might be 
duplicate and just leave the node types and data type introduced in wiki page 
(https://wiki.onap.org/display/DW/Design-Time+Data+Model%3A+WAN+Service),
  is it good enough for SDC to support Wan Connection in release 3?



Best Regards!













黄卓垚huangzhuoyao



职位position
承载网管开发部/有线研究院/有线产品经营部Strategy & IT-IT Dept.


[cid:image002.gif@01D422A0.B7055A00]

[cid:image003.gif@01D422A0.B7055A00]
深圳市南山区科技南路55号中兴通讯研发大楼33楼
33/F, R Building, ZTE Corporation Hi-tech Road South,
Hi-tech Industrial Park Nanshan District, Shenzhen, P..R.China, 518057
T: +86 755    F: +86 755 
M: +86 xxx
E: huang.zhuo...@zte.com.cn
www.zte.com.cn


原始邮件
发件人：yangxu(H) mailto:yang...@huawei.com>>
收件人：denghui (L) 
mailto:denghu...@huawei.com>>onap-disc...@lists.onap.org
 
mailto:onap-disc...@lists.onap.org>>ONAP-TSC@lists.onap.org
 mailto:ONAP-TSC@lists.onap.org>>
日 期 ：2018年07月18日 23:52
主 题 ：Re: [onap-tsc] [onap-discuss] [modeling] Minutes of SDC review of high 
level requirement
Hi Hui and all,

Regarding the last bullet, AFAIK, the WAN connection has been agreed in release 
2 and moved from service IM clean page to resource IM clean page according to 
participants' suggestion that the WAN connection should be considered as 
resource.

Best regards,
Xu
发件人：denghui (L)
收件人：onap-disc...@lists.onap.org,ONAP-TSC@lists.onap.org,
时间：2018-07-18 22:33:37
主 题：[onap-discuss] [modeling] Minutes of SDC review of high level requirement

Hello all

Please find the recorded meeting session here:
https://wiki.onap.org/display/DW/2018+2H+Modeling+sub-committee+meeting+agenda+and+minutes


the meeting minutes are list below:

1) 20180719 9am, the last review from SDC before TSC meeting, will try to 
invite PTLs from SDC/SO/A, the meeting bridge will be sent out tomorrow.

2) Service descriptor/resource composite/PNF/PNF instance/network 
Service/SD-WAN/Element group/Multicloud need to be reviewed tomorrow

3)  the committee will ask the approval for Implementation and documentation 
part, not for low priority and experiemental

4) WAN connection need modeling subcommittee review and approval

Thanks a lot

DENG Hui




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.