from:"huang.zhuoyao"

[onap-discuss] 答复: Fw:Re: [sdc][vfc] SDC questions from VF-C

2017-08-11 Thread huang.zhuoyao

Hi, David and Yangxu

I think ONAP has a different architecture from OPEN-O, it may be not 
suitable to use the TOSCA model directly from OPEN-O for ONAP. Besides, me and 
my ZTE colleague are working on a WAN descriptor based on ONAP architecture. I 
guess it would be pretty hard and unefficient to clarify all the detail of the 
WAN model in the ZOOM meeting. I suggest we'd better discuss this by email 
first. I believe the draft of ONAP based WAN model would be finished before 
next Monday, and we would send it on the email for further discussion as soon 
as possible.




Thank you and best regards! 



















黄卓垚huangzhuoyao






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









深圳市南山区科技南路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

 













发件人： 
收件人： ZhangMaoPeng10030173 
抄送人：  
日 期 ：2017/08/10 22:36
主 题 ：Re: [onap-discuss] [sdc][vfc] SDC questions from VF-C







Hi David,


 


Thanks for updating the table to include SDNC controller.


 


Regarding the WAN service, as I pointed to you before, in the TOSCA example 
from Open-O sent by Huabin a while ago, there is a folder in that zip file 
called underlayL3VPN_2017_03_24/Definitions/. You can see  a couple yaml files 
there for type definition.  Please let us know if that’s good enough for you to 
design WAN service in SDC.


 


We will have a meeting tomorrow (8/11) 10am EST, I’ll forward you the invite 
and hope you can help us solving the blocking issue.


 


Thanks,


-Yang


 



From: SHADMI, DAVID [mailto:ds2...@att.com] 
 Sent: Thursday, August 10, 2017 8:42 AM
 To: Yang Xu (Yang, Fixed Network) zhang.maope...@zte.com.cn LANDO, MICHAEL
 Cc: onap-discuss@lists.onap.org ROZIN, EDEN
 Subject: RE: [onap-discuss] [sdc][vfc] SDC questions from VF-C




 


Hi Yang,


 


I still haven’t seen the WAN service information and therefore can’t provide 
any comments about it.


 


Here is the updated table based. See enclosed email for additional information.


 


Service


Type


Category


Controller


Comment


VoLTE


Service


Service



No controller


vIMS


Service


NS


VFC


New imperative BPMN flow which uses VFC


vEPC


Service


NS


VFC


New imperative BPMN flow which uses VFC


vFW/vLB, vCPE, WAN


Service


Service


SDNC/HEAT


Retain the existing OpenECOMP BPMN flow


 


 


Thanks,


David


 


 



From: Yang Xu (Yang, Fixed Network) [mailto:yang@huawei.com] 
 Sent: Wednesday, August 09, 2017 11:44 PM
 To: SHADMI, DAVID  zhang.maope...@zte.com.cn LANDO, MICHAEL 

 Cc: onap-discuss@lists.onap.org ROZIN, EDEN 
 Subject: RE: [onap-discuss] [sdc][vfc] SDC questions from VF-C




 


Hi David,


 


I missed Wednesday’s meeting due to some other conflict. Has WAN service been 
defined in SDC? I don’t see SDNC (the controller for WAN service) listed in the 
table:


 


Service


Type


Category


Orchestrator/Controller 


VoLTE


Service


E2E Service


SO VFC


vIMS


Service


NS


VFC


vEPC


Service


NS


VFC


vFW/vLB demo


Service


Service


Heat


vCPE or other service designed by SDC using declarative flow.


Service


All other Service


Business as usual from SO perspective: SO is doing service and resource 
orchestration interfacing with SDNC/APPC/PO as needed  APPC


 


Could you finalize the WAN service details in SDC (i.e. how PNFs and WAN 
service defined in SDC)? Other modules are blocked by it.


 


Thanks,


-Yang  


 



From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of SHADMI, DAVID
 Sent: Thursday, August 10, 2017 12:04 AM
 To: zhang.maope...@zte.com.cn LANDO, MICHAEL
 Cc: onap-discuss@lists.onap.org ROZIN, EDEN
 Subject: Re: [onap-discuss] [sdc][vfc] SDC questions from VF-C




 


Hello,


 


#2 - SDC is planning to allow onboarding VNFSDK0-validated TOSCA VNF packages 
in R1. Also, SDC is planning to add Open-O TOSCA types.


#3 – @Michael – Could you please make sure we the node type definition file(s) 
for VF and Service exist in the wiki. @Maopeng  - could you please elaborate 
more on the node type you would like to add.


#5 – Please see enclosed email.


 


 


Thanks,


David


 


 


From: zhang.maope...@zte.com.cn [mailto:zhang.maope...@zte.com.cn] 
 Sent: Wednesday, August 09, 2017 9:15 PM
 To: LANDO, MICHAEL  SHADMI, DAVID 
 Cc: yangya...@chinamobile.com denglin...@chinamobile.com 
meng.zhaoxi...@zte.com.cn onap-discuss@lists.onap.org ROZIN, EDEN 

 Subject: 答复: RE: RE: [sdc][vfc] SDC questions from VF-C


 

hi micheal & david

[onap-discuss] 答复: Re: [onap-tsc][SDNC] [SO] Hi, Here is the remain questions// summary and proposed action for SPTN WAN Model and implementation

2017-08-11 Thread huang.zhuoyao

Hi all,

I'm working on the parameters now, and i will publish them by email later
for further discussion. I suggest we should discuss them on email first, make a
base line agreement on the draft before ZOOM meeting. Then we could raise the
call and complete the final agreement.

Thank you all!

黄卓垚huangzhuoyao

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

深圳市南山区科技南路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

原始邮件

发件人：袁越10008526
收件人：黄卓垚10112215
抄送人：

日 期 ：2017年08月11日 10:10
主 题 ：Re: [onap-tsc][SDNC] [SO] Hi, Here is the remain questions// summary and
proposed action for SPTN WAN Model and implementation

Hi all,

We have had a pretty good discussion on WAN connection of volte use case this
morning/last evening. Many thanks to all who help to clear the sequence,
interface among SO, SDNC, 3rd party controller also inside the SDNC. I believe
we can move forward now.

May I propose next step actions as:

1. ZhouYoa Huang submit the SDNC southband API payload for reference and
confirm northband GENERIC RESOURCE API payload with SDNC team.

2. ZTE prepare TOSCA WAN Descriptor and the content of the Descriptor should be
align with the payload of SDNC northband GENERIC RESOURCE API.

3. Discuss the WAN Descriptor with SDC/SO/SDNC teams in modeling subcommittee
to freeze the WAN Descriptor for 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 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

发件人：黄卓垚10112215
收件人：

抄送人：
日 期 ：2017年08月10日 21:12
主 题 ：[onap-tsc] Hi, Here is the remain questions

Hi,

First l'd like to confirm with SDNC team on several keypoints about the
release1 volte use case WAN orchestration procedure both in design stage and
runtime:

We should use Directed Graphs portal to design WAN(L3VPN in volte use case)
orchestration graghs for SDNC and keep the design align with the L3VPN model in
Domain controllers(here 3rd party SPTN or IPRAN controller in volte usecase ).
If the original model is not expressed with DG graphs, we have no tools to
import it automatically into the SDNC.

We should design WAN descriptor in TOSCA with SDC independently and keep align
with the model in SDNC. Since the data model in SDNC is not TOSCA file nor yang
file, SDC can not import WAN model like importing VNF Descriptor in VNF case.

When instantiate volte service, SO will decompose the E2E Service Descriptor to
vIMS Descriptor, WAN Descriptor, vEPC Descriptor and send vIMS and vEPC to VFC.
There should be a module handle the WAN Descriptor. Where we intent to put this
module? in SO or SDNC? If the seed code of this module is ready or not?

After the module parse the WAN Descriptor, the parameters of L3VPN and
corresponding DG name will be extracted from the TOSCA package and send to SDNC
to trigger the DG excution of the pre-designed dericted gragh.

The pre-designed dericted gragh will call corresponding adaptors then the
adaptor will construct request with the parameters deliveried from SDNC DG, and
send request to 3rd party controller.

If my understanding is not correct, please point it out.

In summary, we have three key questions:

What kind of information should WAN Descriptor contain? L3vpn info? DG name
of SDN-C? Something else?

Which project, SO or SDNC, parse the TOSCA template?

Who will be responsible on this part of code(parse tosca template then
mapping to existing SDNC northband API)?

Best regards!

黄卓垚huangzhuoyao

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

[onap-discuss] about disscuss in VoLTE [SO] / [SDNC] Interface discussion (8/11, 10:00 pm UTC8 / 10:00 am EST )

2017-08-10 Thread huang.zhuoyao

Hi, Dan


May I ask what's the topic gonna to be disscussed in VoLTE [SO] / [SDNC] 
Interface discussion (8/11, 10:00 pm UTC8 / 10:00 am EST )? 


Thank you!



















黄卓垚huangzhuoyao






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









深圳市南山区科技南路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___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] 答复: RE: Here is a question about SDN-C adapter,wouldyouplease help me about it? Thank you!

2017-08-04 Thread huang.zhuoyao

Dear all,


As Chengli said, we still need some inputs to instance the network 
connection service between DCs. The inputs may come from the network model or 
as the input parameters to the network instantiation action. These network 
model or input parameters have been defined yet? They should be defined by YANG 
or TOSCA? 




Thank you! 



















黄卓垚huangzhuoyao






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









深圳市南山区科技南路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

 



原始邮件



发件人： 
收件人： 
抄送人：黄卓垚10112215  
日 期 ：2017年07月27日 00:26
主 题 ：RE: [onap-discuss] Here is a question about SDN-C adapter,wouldyouplease 
help me about it? Thank you!







Yes. Exactly.


 


Brian


 


 



From: Chengli Wang [mailto:wangchen...@chinamobile.com] 
 Sent: Wednesday, July 26, 2017 12:23 PM
 To: FREEMAN, BRIAN D 
 Cc: huang.zhuo...@zte.com.cn onap-discuss@lists.onap.org TIMONEY, DAN 

 Subject: Re: [onap-discuss] Here is a question about SDN-C adapter,would 
youplease help me about it? Thank you!




 


Brian, 



 



From your point, I think vendors should raise their input requirements , then 
SDNC get the parameters from somewhere and transfer them to the specific 
adapter via DG config node, right?





 Chengli 




 On 26 Jul 2017, at 11:57 PM, FREEMAN, BRIAN D  wrote:



Chengli,


 


I was thinking it would be option 2 – the adapters can be vendor specific since 
we will know the equipment type based on VIM inventory data as part of the DG.


 


It would be nice to have common inputs but we have had to deal with that before 
on other adapters. Its two separate config nodes btw – a WAN-VendorA config 
node and DCGW-VendorB config node.


 


Brian


 


 



From: Chengli Wang [mailto:wangchen...@chinamobile.com] 
 Sent: Wednesday, July 26, 2017 11:16 AM
 To: FREEMAN, BRIAN D 
 Cc: huang.zhuo...@zte.com.cn onap-discuss@lists.onap.org TIMONEY, DAN 

 Subject: Re: [onap-discuss] Here is a question about SDN-C adapter,would you 
please help me about it? Thank you!




 


Hi Brian,



 


As my understanding, Maybe we have two options to integrate 3rd SDN controller 
with SDN-C, please correct me if I am wrong.



Option 1, SDN-C can define the common interfaces should be followed by vendors 
adaptor, then the vendors can provide their specific adaptors to translate the 
common interfaces to their own special ones exposed by their commercial SDN 
controllers.



I think that is why Zhuoyao ask for your help to provide some inputs to 
adaptors. Is that correct, Zhuoyao?



 






Option 2, vendors can exposed their SDN controller(local controller/WAN 
controller) special north bound APIs directly to SDN-C, the config node of DG 
inside SDN-C can invoke the APIs directly. then there is no need to do the 
translation  in the adaptor. 







 


Also I know that no matter which one will be chosen, we still need some inputs 
to instance the network connection service between DCs.



The inputs may come from the network model or as the input parameters to the 
network instantiation action. What’s your suggestion?



 


Regards,



Chengli



 


在 2017年7月26日，下午8:05，FREEMAN,  BRIAN D  写道：



 


+1 onap-discuss



 


It hasnt been defined because we were waiting for input from Chengli on what 
API was expected to be used. We were told it would be a REST API to the vendor 
controller.



 


Chengli,



 


Could you add an example to the VoLTE wiki page like you did for the Overlay 
API ?



 


Brian



 


 


 


 


From: huang.zhuo...@zte.com.cn [mailto:huang.zhuo...@zte.com.cn] 
 Sent: Tuesday, July 25, 2017 11:14 PM
 To: FREEMAN, BRIAN D 
 Cc: TIMONEY, DAN  bo.kai...@zte.com.cn zhang.suj...@zte.com.cn 
feng.j...@zte.com.cn
 Subject: Here is a question about SDN-C adapter, would you please help me 
about it? Thank you!



 


Hi, Brian


 


Here is a question about SDN-C adapter, would you please help me about it?


Has the input of adapter responsible for underlay L3VPN between PEs been 
defined yet? If yes, is it  based on E2E model? And how we can know more detail 
about it? 


 


Thank you!


 


 


 


 


 


黄卓垚huangzhuoyao


 


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


 







 深圳市南山区科技南路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

[onap-discuss] 答复: RE: Here is a question about SDN-C adapter,wouldyouplease help me about it? Thank you!

2017-07-28 Thread huang.zhuoyao

Hi Dan,


Is that necessary to raise a new Jira issue about it before Funtionality 
Frezze August 3rd ?


Thank you!



















黄卓垚huangzhuoyao






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









深圳市南山区科技南路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

 



原始邮件



发件人：黄卓垚10112215
收件人： 
抄送人：   

日 期 ：2017年07月28日 09:03
主 题 ：答复: RE: [onap-discuss] Here is a question about SDN-C 
adapter,wouldyouplease help me about it? Thank you!






Briand,

Is that means a new Jira issue about this should be raised before 
Funtionality Frezze August 3rd ?

Thank you!
















黄卓垚huangzhuoyao






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









深圳市南山区科技南路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

 












发件人： 
收件人： 
抄送人：黄卓垚10112215  
日 期 ：2017年07月27日 00:26
主 题 ：RE: [onap-discuss] Here is a question about SDN-C adapter,wouldyouplease 
help me about it? Thank you!







Yes. Exactly.


 


Brian


 


 



From: Chengli Wang [mailto:wangchen...@chinamobile.com] 
 Sent: Wednesday, July 26, 2017 12:23 PM
 To: FREEMAN, BRIAN D 
 Cc: huang.zhuo...@zte.com.cn onap-discuss@lists.onap.org TIMONEY, DAN 

 Subject: Re: [onap-discuss] Here is a question about SDN-C adapter,would 
youplease help me about it? Thank you!




 


Brian, 



 



From your point, I think vendors should raise their input requirements , then 
SDNC get the parameters from somewhere and transfer them to the specific 
adapter via DG config node, right?





 Chengli 




 On 26 Jul 2017, at 11:57 PM, FREEMAN, BRIAN D  wrote:



Chengli,


 


I was thinking it would be option 2 – the adapters can be vendor specific since 
we will know the equipment type based on VIM inventory data as part of the DG.


 


It would be nice to have common inputs but we have had to deal with that before 
on other adapters. Its two separate config nodes btw – a WAN-VendorA config 
node and DCGW-VendorB config node.


 


Brian


 


 



From: Chengli Wang [mailto:wangchen...@chinamobile.com] 
 Sent: Wednesday, July 26, 2017 11:16 AM
 To: FREEMAN, BRIAN D 
 Cc: huang.zhuo...@zte.com.cn onap-discuss@lists.onap.org TIMONEY, DAN 

 Subject: Re: [onap-discuss] Here is a question about SDN-C adapter,would you 
please help me about it? Thank you!




 


Hi Brian,



 


As my understanding, Maybe we have two options to integrate 3rd SDN controller 
with SDN-C, please correct me if I am wrong.



Option 1, SDN-C can define the common interfaces should be followed by vendors 
adaptor, then the vendors can provide their specific adaptors to translate the 
common interfaces to their own special ones exposed by their commercial SDN 
controllers.



I think that is why Zhuoyao ask for your help to provide some inputs to 
adaptors. Is that correct, Zhuoyao?



 






Option 2, vendors can exposed their SDN controller(local controller/WAN 
controller) special north bound APIs directly to SDN-C, the config node of DG 
inside SDN-C can invoke the APIs directly. then there is no need to do the 
translation  in the adaptor. 







 


Also I know that no matter which one will be chosen, we still need some inputs 
to instance the network connection service between DCs.



The inputs may come from the network model or as the input parameters to the 
network instantiation action. What’s your suggestion?



 


Regards,



Chengli



 


在 2017年7月26日，下午8:05，FREEMAN,  BRIAN D  写道：



 


+1 onap-discuss



 


It hasnt been defined because we were waiting for input from Chengli on what 
API was expected to be used. We were told it would be a REST API to the vendor 
controller.



 


Chengli,



 


Could you add an example to the VoLTE wiki page like you did for the Overlay 
API ?



 


Brian



 


 


 


 


From: huang.zhuo...@zte.com.cn [mailto:huang.zhuo...@zte.com.cn] 
 Sent: Tuesday, July 25, 2017 11:14 PM
 To: FREEMAN, BRIAN D 
 Cc: TIMONEY, DAN  bo.kai...@zte.com.cn zhang.suj...@zte.com.cn 
feng.j...@zte.com.cn
 Subject: Here is a question about SDN-C adapter, would you please help me 
about it? Thank you!



 


Hi, Brian


 


Here is a question about SDN-C adapter, would you please help me about it?


Has the input of adapter responsible for underlay L3VPN between PEs been 
defined

[onap-discuss] 答复: RE: Here is a question about SDN-C adapter,wouldyouplease help me about it? Thank you!

2017-07-28 Thread huang.zhuoyao

Briand,

Is that means a new Jira issue about this should be raised before 
Funtionality Frezze August 3rd ?

Thank you!
















黄卓垚huangzhuoyao






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









深圳市南山区科技南路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

 



原始邮件



发件人： 
收件人： 
抄送人：黄卓垚10112215  
日 期 ：2017年07月27日 00:26
主 题 ：RE: [onap-discuss] Here is a question about SDN-C adapter,wouldyouplease 
help me about it? Thank you!







Yes. Exactly.


 


Brian


 


 



From: Chengli Wang [mailto:wangchen...@chinamobile.com] 
 Sent: Wednesday, July 26, 2017 12:23 PM
 To: FREEMAN, BRIAN D 
 Cc: huang.zhuo...@zte.com.cn onap-discuss@lists.onap.org TIMONEY, DAN 

 Subject: Re: [onap-discuss] Here is a question about SDN-C adapter,would 
youplease help me about it? Thank you!




 


Brian, 



 



From your point, I think vendors should raise their input requirements , then 
SDNC get the parameters from somewhere and transfer them to the specific 
adapter via DG config node, right?





 Chengli 




 On 26 Jul 2017, at 11:57 PM, FREEMAN, BRIAN D  wrote:



Chengli,


 


I was thinking it would be option 2 – the adapters can be vendor specific since 
we will know the equipment type based on VIM inventory data as part of the DG.


 


It would be nice to have common inputs but we have had to deal with that before 
on other adapters. Its two separate config nodes btw – a WAN-VendorA config 
node and DCGW-VendorB config node.


 


Brian


 


 



From: Chengli Wang [mailto:wangchen...@chinamobile.com] 
 Sent: Wednesday, July 26, 2017 11:16 AM
 To: FREEMAN, BRIAN D 
 Cc: huang.zhuo...@zte.com.cn onap-discuss@lists.onap.org TIMONEY, DAN 

 Subject: Re: [onap-discuss] Here is a question about SDN-C adapter,would you 
please help me about it? Thank you!




 


Hi Brian,



 


As my understanding, Maybe we have two options to integrate 3rd SDN controller 
with SDN-C, please correct me if I am wrong.



Option 1, SDN-C can define the common interfaces should be followed by vendors 
adaptor, then the vendors can provide their specific adaptors to translate the 
common interfaces to their own special ones exposed by their commercial SDN 
controllers.



I think that is why Zhuoyao ask for your help to provide some inputs to 
adaptors. Is that correct, Zhuoyao?



 






Option 2, vendors can exposed their SDN controller(local controller/WAN 
controller) special north bound APIs directly to SDN-C, the config node of DG 
inside SDN-C can invoke the APIs directly. then there is no need to do the 
translation  in the adaptor. 







 


Also I know that no matter which one will be chosen, we still need some inputs 
to instance the network connection service between DCs.



The inputs may come from the network model or as the input parameters to the 
network instantiation action. What’s your suggestion?



 


Regards,



Chengli



 


在 2017年7月26日，下午8:05，FREEMAN,  BRIAN D  写道：



 


+1 onap-discuss



 


It hasnt been defined because we were waiting for input from Chengli on what 
API was expected to be used. We were told it would be a REST API to the vendor 
controller.



 


Chengli,



 


Could you add an example to the VoLTE wiki page like you did for the Overlay 
API ?



 


Brian



 


 


 


 


From: huang.zhuo...@zte.com.cn [mailto:huang.zhuo...@zte.com.cn] 
 Sent: Tuesday, July 25, 2017 11:14 PM
 To: FREEMAN, BRIAN D 
 Cc: TIMONEY, DAN  bo.kai...@zte.com.cn zhang.suj...@zte.com.cn 
feng.j...@zte.com.cn
 Subject: Here is a question about SDN-C adapter, would you please help me 
about it? Thank you!



 


Hi, Brian


 


Here is a question about SDN-C adapter, would you please help me about it?


Has the input of adapter responsible for underlay L3VPN between PEs been 
defined yet? If yes, is it  based on E2E model? And how we can know more detail 
about it? 


 


Thank you!


 


 


 


 


 


黄卓垚huangzhuoyao


 


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


 







 深圳市南山区科技南路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



 








___
 onap-discuss mailing list
 onap-discuss@lists.onap.org
 https://lists.onap.org/mailman/listinfo/onap-discuss___
onap-discuss mailing list
onap-discuss@lists.onap.org

[onap-discuss] 答复: RE: Re: [onap-tsc]答复: Re: ONAP VoLTE SDC call

2017-08-09 Thread huang.zhuoyao

Thank you, Briand! It is very helpful!




















黄卓垚huangzhuoyao






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









深圳市南山区科技南路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








原始邮件



发件人： 
收件人：黄卓垚10112215
抄送人：    
   

日 期 ：2017年08月08日 21:00
主 题 ：RE: Re: [onap-tsc]答复: Re:  ONAP VoLTE SDC call







If you look at the SLI-API tutorial for VoLTE on the wiki you can get a sense 
of how this is accomplished. Here a set node is used but all the value’s could 
references to context memory variables.


 


Device.* schema is defined by the adaptor (in this case the DC Gateway vendor’s 
API)


 























 


As an example (final parameter-name have not been selected) we might get this 
input


 

{ "parameter-name": "volte-wan-activate.dca_name",  
   "string-value": "dcA-east" }, { 
"parameter-name": "volte-wan-activate.dcb_name", "string-value": 
"dcB-west" }, 
 


 


The DG would lookup dcA-east and determine that the ip address of the 
controller was 10.0.1.0 and dcB-east was 10.0.2.0 (or FQDNs etc) and that the 
dcA router ID was:


'CBB702C3-6789-1234-A5AD-000A’


 


The DG would assign a WAN VNI from resource assignment, assign import and 
export route targets from resource assignment , calculate names from 
source/destination data like the device.description, etc.


 


Input variables from the call from SO would also be mapped.


 


Then the paramters to the adaptor could be


 























 


To be clear device.* comes from the adaptor and probably would be something 
more specific than device but the leaf names would likely match the parameters 
in the API  call to the 3rd party controller.


 


Dc_connection.* and service_data.* are from the northbound service model and 
network data model in context memory.


 


Using the SLI-API and an emulator we can build and test the adaptor and the DG 
in advance of having the rest of the assets available.


 


The actual parameter names need to be specified so that SO can provide the 
correct rpc into SDNC but that is not dependent on the actual names used in the 
adaptor node  – the DG maps from the service model parameters into those 
adaptor specific (device) parameters.


 


Brian


 


 



From: FREEMAN, BRIAN D 
 Sent: Tuesday, August 08, 2017 8:35 AM
 To: huang.zhuo...@zte.com.cn
 Cc: SHADMI, DAVID  TIMONEY, DAN  
seshu.kuma...@huawei.com KAPELUTO, ZAHI  
onap-discuss@lists.onap.org ROZIN, EDEN  
onap-...@lists.onap.org
 Subject: RE: Re: [onap-tsc]答复: Re: ONAP VoLTE SDC call




 


The adaptor should define its inputs as parameters in the adaptor node.


 


The schema for those paramters can be defined by the adaptor/vendor.


 


The directed graph will map from the WAN model into the vendor specific mode in 
the adaptor.


 


We are going to recomend using a model called the GENERIC-RESOURCE-API that has 
a name/value pair list of the parameters and we will pull the paramters of 
interface from that API to populate the inputs to the adaptor node.


 


Brian


 


 


From: huang.zhuo...@zte.com.cn [mailto:huang.zhuo...@zte.com.cn] 
 Sent: Tuesday, August 08, 2017 7:30 AM
 To: FREEMAN, BRIAN D 
 Cc: SHADMI, DAVID  TIMONEY, DAN  
seshu.kuma...@huawei.com KAPELUTO, ZAHI  
onap-discuss@lists.onap.org ROZIN, EDEN  
onap-...@lists.onap.org
 Subject: 答复: Re: [onap-tsc]答复: Re: ONAP VoLTE SDC call


 

Hi, Brian

Maybe here is the old question. Is there a common model for WAN description 
in SDN-C? If no, where should SDN-C get the input of adapter?

Thank you!

 

 

 

 


 


黄卓垚huangzhuoyao


 


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


 






 深圳市南山区科技南路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


 





原始邮件



发件人： 



收件人：黄卓垚10112215    



抄送人：     




日 期 ：2017年08月07日 23:09



主 题 ：Re: [onap-tsc]答复:  Re:  ONAP VoLTE SDC call




 


“be placed manually according to specific apdator”


 


The 3rd party adaptor needs the yang model as

[onap-discuss] 答复: Re: [onap-tsc]答复: Re: ONAP VoLTE SDC call

2017-08-08 Thread huang.zhuoyao

Hi, Brian

Maybe here is the old question. Is there a common model for WAN description 
in SDN-C? If no, where should SDN-C get the input of adapter?

Thank you!



















黄卓垚huangzhuoyao






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









深圳市南山区科技南路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

 



原始邮件



发件人： 
收件人：黄卓垚10112215   
抄送人：    

日 期 ：2017年08月07日 23:09
主 题 ：Re: [onap-tsc]答复: Re:  ONAP VoLTE SDC call







“be placed manually according to specific apdator”


 


The 3rd party adaptor needs the yang model as part of its development so it 
isnt needed from SDC its needed as part of the adaptor development.


 


 


I dont know if there is value in providing the yang model in the CSAR since its 
already going to be available on the controller as part of the adaptor that 
would be more Dan Timoney’s call and he probably has a better view of the 
overall  SDC to SDNC flow anyway.


 


Brian


 


 


From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of huang.zhuo...@zte.com.cn
 Sent: Monday, August 07, 2017 7:12 AM
 To: SHADMI, DAVID  TIMONEY, DAN  
seshu.kuma...@huawei.com
 Cc: onap-discuss@lists.onap.org KAPELUTO, ZAHI  ROZIN, 
EDEN  onap-...@lists.onap.org
 Subject: [onap-tsc] 答复: Re: ONAP VoLTE SDC call


 

Hi,  David, Dan and seshu

 

   Some questions about how WAN service descriptor works with SO and SDN-C:

How does SDN-C import the YANG file describing NBI of 3rd controller? By Json 
from SO? Or be placed manually according to specific apdator? Or by other ways?

What kind of infomation should be contained in the interface between SO and 
SDN-C? YANG describing NBI of 3rd controller? CSAR of WAN descriptor? 
Information sending to 3rd controller? Or something else?

SDN-C receive CSAR from SDC?

SO is responsible for abstracting YANG from CSAR which is discribing the NBI of 
3rd controller?

How to import the YANG describing NBI of 3rd controller into CSAR?

   

I suggest that we should discuss this topic outside the SDC call on Monday.  Do 
you have any good idea about suitable time for the discussion?

 

Thank you all!

 

 

 


 


黄卓垚huangzhuoyao


 


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


 






 深圳市南山区科技南路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


 





原始邮件



发件人：黄卓垚10112215



收件人：   



抄送人：袁越10008526    
 



日 期 ：2017年08月05日 16:45



主 题 ：答复: Re: [onap-tsc] ONAP VoLTE SDC call




 

There are some issues about how WAN service descriptor works with SO and SDN-C 
might need to be clarified. I suggest should we have a discussion on Monday 
8:00 PM UTC on these issues first? If this time is not suitable for everyone, 
please choose a better  time for discussion.

 

Thank you all!

 

 

 

 


 


黄卓垚huangzhuoyao


 


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


 






 深圳市南山区科技南路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


 




 



 



发件人： 



收件人：袁越10008526黄卓垚10112215



抄送人：     




日 期 ：2017年08月05日 01:27



主 题 ：Re: [onap-tsc] ONAP VoLTE SDC call




 


Can we use the SDC call on Monday 8am PDT to discuss the WAN service descriptor?


 


Thanks,


David


 


From: yuan@zte.com.cn [mailto:yuan@zte.com.cn] 
 Sent: Thursday, August 03, 2017 10:49 PM
 To: SHADMI, DAVID  huang.zhuo...@zte.com.cn
 Cc: denghu...@huawei.com onap-discuss@lists.onap.org onap-...@lists.onap.org 
KAPELUTO, ZAHI  ROZIN, EDEN 
 Subject: 答复: Re: [onap-tsc] ONAP VoLTE SDC call


 

Congratulations! Great progress for ONAP R1.

@David:  SO, SDNC, SDC team and WAN provider of Volte usecase(ZTE and CMCC) 
might have further work on defining of WAN service descriptor which is not as 
clear as NS descriptor.

@Zhuoyao Huang: please prepare and arrange

[onap-discuss] 答复: Re: [onap-tsc] ONAP VoLTE SDC call

2017-08-07 Thread huang.zhuoyao

There are some issues about how WAN service descriptor works with SO and SDN-C 
might need to be clarified. I suggest should we have a discussion on Monday 
8:00 PM UTC on these issues first? If this time is not suitable for everyone, 
please choose a better time for discussion.






 Sorry! I means Monday 8:00 PM UTC+8






Thank you all!



















黄卓垚huangzhuoyao






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









深圳市南山区科技南路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

 



原始邮件



发件人：黄卓垚10112215
收件人：   
抄送人：袁越10008526   
 
日 期 ：2017年08月05日 16:45
主 题 ：答复: Re: [onap-tsc] ONAP VoLTE SDC call






There are some issues about how WAN service descriptor works with SO and SDN-C 
might need to be clarified. I suggest should we have a discussion on Monday 
8:00 PM UTC on these issues first? If this time is not suitable for everyone, 
please choose a better time for discussion.




Thank you all!



















黄卓垚huangzhuoyao






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









深圳市南山区科技南路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

 












发件人： 
收件人：袁越10008526黄卓垚10112215
抄送人：    

日 期 ：2017年08月05日 01:27
主 题 ：Re: [onap-tsc] ONAP VoLTE SDC call







Can we use the SDC call on Monday 8am PDT to discuss the WAN service descriptor?


 


Thanks,


David


 


From: yuan@zte.com.cn [mailto:yuan@zte.com.cn] 
 Sent: Thursday, August 03, 2017 10:49 PM
 To: SHADMI, DAVID  huang.zhuo...@zte.com.cn
 Cc: denghu...@huawei.com onap-discuss@lists.onap.org onap-...@lists.onap.org 
KAPELUTO, ZAHI  ROZIN, EDEN 
 Subject: 答复: Re: [onap-tsc] ONAP VoLTE SDC call


 

Congratulations! Great progress for ONAP R1.

@David:  SO, SDNC, SDC team and WAN provider of Volte usecase(ZTE and CMCC) 
might have further work on defining of WAN service descriptor which is not as 
clear as NS descriptor.

@Zhuoyao Huang: please prepare and arrange discussion with related teams.

Thank you all!

 

Yuan Yue

 


 


袁越 yuanyue


资深战略规划师   Senior Strategy Planner


技术规划部/技术规划部/系统产品 Technology Planning Dept./Technology Planning Dept./System 
Product


 






 南京市雨花区软件大道50号中兴通讯3号楼
 1/F,Building 3, ZTE Nanjing R 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















原始邮件



发件人： 



收件人：    




抄送人：  



日 期 ：2017年08月04日 01:52



主 题 ：Re: [onap-tsc] ONAP VoLTE SDC call




 


All,



 


SDC can support SO suggestion for VoLTE service design presented in th call.



 


With that, I believe we concluded the discussion about the different options, 
and we are moving forward with Option A.



1.   SDC supports onboarding the vIMS and vEPC validated (VNF SDK) VNFs.


2.   vIMS, vEPC, and WAN services design in SDC.


3.   VoLTE service design in SDC.


4.   Distribution of the 4 services to SO, SDNC, VF-C, A


 


Regards,



David



 


-Original Appointment-
  From: LANDO, MICHAEL On Behalf Of denghui (L)
  Sent: Thursday, August 03, 2017 5:09 AM
  To: denghui (L) KAPELUTO, ZAHI SHADMI, DAVID ROZIN, EDEN 
onap-discuss@lists.onap.org onap-tsc Lando,Michael
  Subject: FW: ONAP VoLTE SDC call
  When: Thursday, August 03, 2017 9:00 PM-10:00 PM (UTC+08:00) Beijing, 
Chongqing, Hong Kong, Urumqi.
  Where: https://zoom.us/j/137904496






-Original Appointment-
  From: denghui (L) [mailto:denghu...@huawei.com] 
  Sent: Thursday, August 03, 2017 9:20 AM
  To: denghui (L) onap-discuss@lists.onap.org onap-tsc Lando,Michael
  Subject: ONAP VoLTE SDC call
  When: Thursday, August 03, 2017 9:00 PM-10:00 PM (UTC+08:00) Beijing, 
Chongqing, Hong Kong, Urumqi.
  Where: https://zoom.us/j/137904496



   


Hello all


 


This is for discussion ONAP VoLTE SDC call.



ONAP Meeting 5 is inviting you to a scheduled Zoom meeting. 




Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/137904496




Or iPhone one-tap (US Toll): +14086380968,137904496# or +16465588656,137904496#




Or Telephone:
  Dial: +1 408 638 0968 (US Toll) or +1 646 558 8656 (US

[onap-discuss] 答复: Re: [onap-tsc] ONAP VoLTE SDC call

2017-08-07 Thread huang.zhuoyao

Hi,  David, Dan and seshu




   Some questions about how WAN service descriptor works with SO and SDN-C:

How does SDN-C import the YANG file describing NBI of 3rd controller? By Json 
from SO? Or be placed manually according to specific apdator? Or by other ways?

What kind of infomation should be contained in the interface between SO and 
SDN-C? YANG describing NBI of 3rd controller? CSAR of WAN descriptor? 
Information sending to 3rd controller? Or something else?

SDN-C receive CSAR from SDC?

SO is responsible for abstracting YANG from CSAR which is discribing the NBI of 
3rd controller?

How to import the YANG describing NBI of 3rd controller into CSAR?

   


I suggest that we should discuss this topic outside the SDC call on Monday.  Do 
you have any good idea about suitable time for the discussion?




Thank you all!
















黄卓垚huangzhuoyao






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









深圳市南山区科技南路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

 



原始邮件



发件人：黄卓垚10112215
收件人：   
抄送人：袁越10008526   
 
日 期 ：2017年08月05日 16:45
主 题 ：答复: Re: [onap-tsc] ONAP VoLTE SDC call






There are some issues about how WAN service descriptor works with SO and SDN-C 
might need to be clarified. I suggest should we have a discussion on Monday 
8:00 PM UTC on these issues first? If this time is not suitable for everyone, 
please choose a better time for discussion.




Thank you all!



















黄卓垚huangzhuoyao






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









深圳市南山区科技南路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

 












发件人： 
收件人：袁越10008526黄卓垚10112215
抄送人：    

日 期 ：2017年08月05日 01:27
主 题 ：Re: [onap-tsc] ONAP VoLTE SDC call







Can we use the SDC call on Monday 8am PDT to discuss the WAN service descriptor?


 


Thanks,


David


 


From: yuan@zte.com.cn [mailto:yuan@zte.com.cn] 
 Sent: Thursday, August 03, 2017 10:49 PM
 To: SHADMI, DAVID  huang.zhuo...@zte.com.cn
 Cc: denghu...@huawei.com onap-discuss@lists.onap.org onap-...@lists.onap.org 
KAPELUTO, ZAHI  ROZIN, EDEN 
 Subject: 答复: Re: [onap-tsc] ONAP VoLTE SDC call


 

Congratulations! Great progress for ONAP R1.

@David:  SO, SDNC, SDC team and WAN provider of Volte usecase(ZTE and CMCC) 
might have further work on defining of WAN service descriptor which is not as 
clear as NS descriptor.

@Zhuoyao Huang: please prepare and arrange discussion with related teams.

Thank you all!

 

Yuan Yue

 


 


袁越 yuanyue


资深战略规划师   Senior Strategy Planner


技术规划部/技术规划部/系统产品 Technology Planning Dept./Technology Planning Dept./System 
Product


 






 南京市雨花区软件大道50号中兴通讯3号楼
 1/F,Building 3, ZTE Nanjing R 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















原始邮件



发件人： 



收件人：    




抄送人：  



日 期 ：2017年08月04日 01:52



主 题 ：Re: [onap-tsc] ONAP VoLTE SDC call




 


All,



 


SDC can support SO suggestion for VoLTE service design presented in th call.



 


With that, I believe we concluded the discussion about the different options, 
and we are moving forward with Option A.



1.   SDC supports onboarding the vIMS and vEPC validated (VNF SDK) VNFs.


2.   vIMS, vEPC, and WAN services design in SDC.


3.   VoLTE service design in SDC.


4.   Distribution of the 4 services to SO, SDNC, VF-C, A


 


Regards,



David



 


-Original Appointment-
  From: LANDO, MICHAEL On Behalf Of denghui (L)
  Sent: Thursday, August 03, 2017 5:09 AM
  To: denghui (L) KAPELUTO, ZAHI SHADMI, DAVID ROZIN, EDEN 
onap-discuss@lists.onap.org onap-tsc Lando,Michael
  Subject: FW: ONAP VoLTE SDC call
  When: Thursday, August 03, 2017 9:00 PM-10:00 PM (UTC+08:00) Beijing, 
Chongqing, Hong Kong, Urumqi.
  Where: https://zoom.us/j/137904496






-Original Appointment-
  From: denghui (L) [mailto:denghu...@huawei.com] 
  Sent: Thursday, August 03, 2017 9:20 AM
  To: denghui (L) onap-discuss@lists.onap.org onap-tsc Lando,Michael
  Subject: ONAP VoLTE SDC call
  When: Thursday,

[onap-discuss] 答复: Re: [onap-tsc] ONAP VoLTE SDC call

2017-08-06 Thread huang.zhuoyao

There are some issues about how WAN service descriptor works with SO and SDN-C 
might need to be clarified. I suggest should we have a discussion on Monday 
8:00 PM UTC on these issues first? If this time is not suitable for everyone, 
please choose a better time for discussion.




Thank you all!



















黄卓垚huangzhuoyao






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









深圳市南山区科技南路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

 



原始邮件



发件人： 
收件人：袁越10008526黄卓垚10112215
抄送人：    

日 期 ：2017年08月05日 01:27
主 题 ：Re: [onap-tsc] ONAP VoLTE SDC call







Can we use the SDC call on Monday 8am PDT to discuss the WAN service descriptor?


 


Thanks,


David


 


From: yuan@zte.com.cn [mailto:yuan@zte.com.cn] 
 Sent: Thursday, August 03, 2017 10:49 PM
 To: SHADMI, DAVID  huang.zhuo...@zte.com.cn
 Cc: denghu...@huawei.com onap-discuss@lists.onap.org onap-...@lists.onap.org 
KAPELUTO, ZAHI  ROZIN, EDEN 
 Subject: 答复: Re: [onap-tsc] ONAP VoLTE SDC call


 

Congratulations! Great progress for ONAP R1.

@David:  SO, SDNC, SDC team and WAN provider of Volte usecase(ZTE and CMCC) 
might have further work on defining of WAN service descriptor which is not as 
clear as NS descriptor.

@Zhuoyao Huang: please prepare and arrange discussion with related teams.

Thank you all!

 

Yuan Yue

 


 


袁越 yuanyue


资深战略规划师   Senior Strategy Planner


技术规划部/技术规划部/系统产品 Technology Planning Dept./Technology Planning Dept./System 
Product


 






 南京市雨花区软件大道50号中兴通讯3号楼
 1/F,Building 3, ZTE Nanjing R 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















原始邮件



发件人： 



收件人：    




抄送人：  



日 期 ：2017年08月04日 01:52



主 题 ：Re: [onap-tsc] ONAP VoLTE SDC call




 


All,



 


SDC can support SO suggestion for VoLTE service design presented in th call.



 


With that, I believe we concluded the discussion about the different options, 
and we are moving forward with Option A.



1.   SDC supports onboarding the vIMS and vEPC validated (VNF SDK) VNFs.


2.   vIMS, vEPC, and WAN services design in SDC.


3.   VoLTE service design in SDC.


4.   Distribution of the 4 services to SO, SDNC, VF-C, A


 


Regards,



David



 


-Original Appointment-
  From: LANDO, MICHAEL On Behalf Of denghui (L)
  Sent: Thursday, August 03, 2017 5:09 AM
  To: denghui (L) KAPELUTO, ZAHI SHADMI, DAVID ROZIN, EDEN 
onap-discuss@lists.onap.org onap-tsc Lando,Michael
  Subject: FW: ONAP VoLTE SDC call
  When: Thursday, August 03, 2017 9:00 PM-10:00 PM (UTC+08:00) Beijing, 
Chongqing, Hong Kong, Urumqi.
  Where: https://zoom.us/j/137904496






-Original Appointment-
  From: denghui (L) [mailto:denghu...@huawei.com] 
  Sent: Thursday, August 03, 2017 9:20 AM
  To: denghui (L) onap-discuss@lists.onap.org onap-tsc Lando,Michael
  Subject: ONAP VoLTE SDC call
  When: Thursday, August 03, 2017 9:00 PM-10:00 PM (UTC+08:00) Beijing, 
Chongqing, Hong Kong, Urumqi.
  Where: https://zoom.us/j/137904496



   


Hello all


 


This is for discussion ONAP VoLTE SDC call.



ONAP Meeting 5 is inviting you to a scheduled Zoom meeting. 




Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/137904496




Or iPhone one-tap (US Toll): +14086380968,137904496# or +16465588656,137904496#




Or Telephone:
  Dial: +1 408 638 0968 (US Toll) or +1 646 558 8656 (US Toll)
  Meeting ID: 137 904 496
  International numbers available: 
https://zoom.us/zoomconference?m=mi-ad1sMLWlXByAKLio5vDnd9JYqUR_a



 


Thanks a lot


 


DENG Hui___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] How to commit the files about WAN modeling?

2017-08-22 Thread huang.zhuoyao

Hi, DengHui and Michael

Would you please help me about this issue? I don't know how to commit 
the files about WAN modeling. Should I push them to SDC gerrit, or modeling 
gerrit, or somewhere else?


Thank you very much!




















黄卓垚huangzhuoyao






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









深圳市南山区科技南路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___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] about network-topology-operation

2017-09-21 Thread huang.zhuoyao

Hi Dan,




I get a question about the "svc-notification-url", could please you 
help me about it?










I could not find the usage of "svc-notification-url" in the 
northbound seed code (GenericResourceApiProvider, method 
"networkTopologyOperation"). Could you confirm whether the rpc 
network-topology-operation supports asynchronous response?




Thank you and best regards!
















黄卓垚huangzhuoyao






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









深圳市南山区科技南路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___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] 答复: Re: [sdc] About underlayvpn.yml

2017-09-14 Thread huang.zhuoyao

Hi david,





For a general purpose, 2 underlay vpns might be possible to connect to 
each other, for example, 2 l2 underlay vpn connected together by UNI (User 
Network Interface). And further more, if we figure out the overlay vpn, which 
is also vl, the overlay vpn might connect to the underlay vpn.




Thank you and best regards!




















黄卓垚huangzhuoyao






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









深圳市南山区科技南路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

 



原始邮件



发件人： 
收件人： 黄卓垚10112215袁虎10090474  

抄送人： 
日 期 ：2017年09月14日 02:04
主 题 ：Re: [onap-discuss][sdc] About underlayvpn.yml 







Quick question about the model before we adding it as a resource to the catalog.


According to current model, it is possible to connect the underlayvpn node to 
either a port/CP or another network/VL. Is that the desired behavior?


requirements:


- virtualLink:


capability: tosca.capabilities.network.Linkable


relationship: tosca.relationships.network.LinksTo


capabilities:


  virtual_linkable:


type: tosca.capabilities.network.Linkable


 


Thanks,


David


 


 



From: Gaurav agrawal [mailto:gaurav.agra...@huawei.com] 
 Sent: Tuesday, September 12, 2017 1:54 AM
 To: LANDO, MICHAEL  huang.zhuo...@zte.com.cn SHADMI, 
DAVID 
 Cc: yuan@zte.com.cn denghui (L)  
onap-discuss@lists.onap.org
 Subject: RE: RE: About underlayvpn.yml 




 


+1 to Option 1 considering UnderlayVPN is a reusable resource across multiple 
use cases which requires point to point vpn service.


 



From: Lando,Michael [mailto:ml6...@intl.att.com] 
 Sent: 2017年9月8日  13:58
 To: huang.zhuo...@zte.com.cn SHADMI, DAVID
 Cc: Gaurav agrawal yuan@zte.com.cn denghui (L) onap-discuss@lists.onap.org
 Subject: RE: RE: About underlayvpn.yml 




 


How can we decide on what option to follow?


 


 


 


 


 


BR,


 


Michael Lando


Opensource TL , SDC


AT Network Application Development · NetCom  


Tel Aviv | Tampa | Atlanta | New Jersey |Chicago


···


Office: +972 (3) 5451487


Mobile: +972 (54) 7833603


e-mail: ml6...@intl.att.com


 


From: huang.zhuo...@zte.com.cn [mailto:huang.zhuo...@zte.com.cn] 
 Sent: Friday, September 08, 2017 5:47 AM
 To: SHADMI, DAVID  Lando,Michael 
 Cc: gaurav.agra...@huawei.com yuan@zte.com.cn denghu...@huawei.com 
onap-discuss@lists.onap.org
 Subject: 答复: RE: About underlayvpn.yml 


 

Hi, David and Michael

 

Thanks for your advise! I think underlayvpn is a reusable resource, it 
could be used for multiple use cases not just for Volte only. I guess the 
category info of underlayvpn may like this.  If I'm wrong, please correct me, 
Thank you!

{

  "payloadName": "underlayvpn.yml",

  "contactId": "jh0003",

  "name": "VL UNDERLAYVPN",

  "description": "The node represents a underlay-vpn entity.",

  "resourceIconPath": "network",

  "resourceType": "VL",

  "categories": [

  {

"name": "Network Connectivity",

"subcategories": [

  {

"name": "Virtual Links"

  }

]

  }

],

  "tags": [

"VL UNDERLAYVPN"

  ]

}


 

Best regards!

 

 

 



 


黄卓垚huangzhuoyao


 


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


 






 深圳市南山区科技南路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


 





原始邮件



发件人： 



收件人：黄卓垚10112215   



抄送人：袁虎10090474   



日 期 ：2017年09月07日  23:56



主 题 ：RE: About underlayvpn.yml 




 


Hi,


 


There are two options the first option is to include the underlayvpn with SDC 
distribution. The second option is to import it into SDC at design time.


If the underlayvpn is a reusable resource, meaning it would be used for other 
services, then option 1 is the way forward. If it is VoLTE only, then I 
recommend option 2.


 


@Michael – If option 1 is selected, we need to include the underlayvpn in the 
catalog.


 


Thanks,


David


 


 


From: huang.zhuo...@zte.com.cn [mailto:huang.zhuo...@zte.com.cn] 
 Sent: Thursday, September 07, 2017 3:12 AM
 To: SHADMI, DAVID  LANDO, MICHAEL  
gaurav.agra...@huawei.com
 Cc: yuan@zte.com.cn

[onap-discuss] 答复: Re: 答复: RE: How to commit the files about WAN modeling?

2017-09-06 Thread huang.zhuoyao

Hi Gaurav,




David suggested we should treat underlayvpn as a vl, and I was not sure 
the whether the GENERIC-RESOURCE-API supports the deployment of vl, so we 
discuss about it these days, and the commit has been delay. But I find out the 
answer in yesterday SDN-C weekly meeting and I will commit the files soon. I 
will make you a reviewer of the commit.




Thanks and regards!

















黄卓垚huangzhuoyao






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









深圳市南山区科技南路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

 



原始邮件



发件人： 
收件人：黄卓垚10112215  
抄送人：袁越10008526  
日 期 ：2017年09月06日 19:43
主 题 ：Re: [onap-discuss]答复: RE: How to commit the files about WAN modeling?







Hi Zhuoyao,


 


Can you please let me know if WAN related YAML are already committed?


 


Thanks and Regards,


Gaurav


 



From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of 
huang.zhuo...@zte.com.cn
 Sent: 2017年8月30日  13:12
 To: ds2...@att.com ml6...@intl.att.com
 Cc: Patrick Liu yuan@zte.com.cn onap-discuss@lists.onap.org
 Subject: [onap-discuss] 答复: RE: How to commit the files about WAN modeling?



 

 

Hi, David and Michael

I'm not sure about that is it suitable to push the yaml files about WAN 
description of Volte use case to SDC? Would you please help me about that?

Thanks and best regards!

 

 



 


黄卓垚huangzhuoyao


 


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


 






 深圳市南山区科技南路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


 





原始邮件



发件人： 



收件人：黄卓垚10112215   



抄送人： 袁越10008526孟照星10024238张茂鹏10030173  
 



日 期 ：2017年08月23日 15:03



主 题 ：RE: How to commit the files about WAN modeling?




 


Hi, Zhuoyao


 


For modeling code, have you decided together with David about whether to build 
WAN resrouce in SDC  based on VF or VL? You could upload to SDC to  check 
whether their committers agree or not.


 


For modeling spec, once it is finalized in modeling committee, it will be kept 
in the repo of modeling  project.


 


Thanks


 


DENG Hui


 


From: huang.zhuo...@zte.com.cn [mailto:huang.zhuo...@zte.com.cn] 
 Sent: Wednesday, August 23, 2017 9:55 AM
 To: denghui (L)  ml6...@intl.att.com
 Cc: Patrick Liu  yuan@zte.com.cn 
meng.zhaoxi...@zte.com.cn zhang.maope...@zte.com.cn denglin...@chinamobile.com 
onap-discuss@lists.onap.org
 Subject: How to commit the files about WAN modeling?


 

Hi, DengHui and Michael

Would you please help me about this issue? I don't know how to commit 
the files about WAN modeling. Should I push them to SDC gerrit, or modeling 
gerrit, or somewhere else?

Thank you very much!

 

 

 

 



 


黄卓垚huangzhuoyao


 


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


 






 深圳市南山区科技南路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___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] 答复: RE: About underlayvpn.yml

2017-09-07 Thread huang.zhuoyao

Hi, David and Michael




Thanks for your advise! I think underlayvpn is a reusable resource, it 
could be used for multiple use cases not just for Volte only. I guess the 
category info of underlayvpn may like this. If I'm wrong, please correct me, 
Thank you!



{


  "payloadName": "underlayvpn.yml",

  "contactId": "jh0003",

  "name": "VL UNDERLAYVPN",

  "description": "The node represents a underlay-vpn entity.",

  "resourceIconPath": "network",

  "resourceType": "VL",

  "categories": [

  {

"name": "Network Connectivity",

"subcategories": [

  {

"name": "Virtual Links"

  }

]

  }

],

  "tags": [

"VL UNDERLAYVPN"

  ]

}





Best regards!

















黄卓垚huangzhuoyao






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









深圳市南山区科技南路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

 



原始邮件



发件人： 
收件人：黄卓垚10112215  
抄送人：袁虎10090474  
日 期 ：2017年09月07日 23:56
主 题 ：RE: About underlayvpn.yml 







Hi,


 


There are two options the first option is to include the underlayvpn with SDC 
distribution. The second option is to import it into SDC at design time.


If the underlayvpn is a reusable resource, meaning it would be used for other 
services, then option 1 is the way forward. If it is VoLTE only, then I 
recommend option 2.


 


@Michael – If option 1 is selected, we need to include the underlayvpn in the 
catalog.


 


Thanks,


David


 


 


From: huang.zhuo...@zte.com.cn [mailto:huang.zhuo...@zte.com.cn] 
 Sent: Thursday, September 07, 2017 3:12 AM
 To: SHADMI, DAVID  LANDO, MICHAEL  
gaurav.agra...@huawei.com
 Cc: yuan@zte.com.cn denghu...@huawei.com onap-discuss@lists.onap.org
 Subject: About underlayvpn.yml 


 

Hi David,

 

May I push the files of underlayvpn definition into SDC?  And if not, 
we have to use another way to import it to SDC  at design time manually?

 

Thank you and best regards!



 

 

 

 



 


黄卓垚huangzhuoyao


 


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


 






 深圳市南山区科技南路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___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] About underlayvpn.yml

2017-09-07 Thread huang.zhuoyao

Hi David,




May I push the files of underlayvpn definition into SDC?  And if not, 
we have to use another way to import it to SDC at design time manually?




Thank you and best regards!























黄卓垚huangzhuoyao






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









深圳市南山区科技南路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___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] 答复: [SO][SDNC] About underlay vpn deployment

2017-09-29 Thread huang.zhuoyao

Hi Ramun,






My replay is in green, thank you!







Best regards!



























黄卓垚huangzhuoyao






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









深圳市南山区科技南路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








原始邮件



发件人： ;
收件人：黄卓垚10112215; ;
抄送人： ; ;
日 期 ：2017年09月29日 15:21
主 题 ：[onap-discuss] [SO][SDNC] About underlay vpn deployment








Hi Zhuoyao,


 


For the underlay “create” GENERIC-RESOURCE-API request from SO, the response 
from SDNC will be like below..


 


"GENERIC-RESOURCE-API:output": {


"GENERIC-RESOURCE-API:topology-response-common": {


  "GENERIC-RESOURCE-API:svc-request-id": "", // the request id from 
the request message


  "GENERIC-RESOURCE-API:response-code": "", // a success code or an 
defined error code


  "GENERIC-RESOURCE-API:response-message": ""  // message included for 
error code


  "GENERIC-RESOURCE-API:ack-final-indicator": ""  // Expected to be Y or N


},


"GENERIC-RESOURCE-API:network-response-information": {


  "GENERIC-RESOURCE-API:instance-reference": {   


"GENERIC-RESOURCE-API:instance-id": "",// 
underlay network-instance record id(created by SDNC)


"GENERIC-RESOURCE-API:object-path": "",   // 
restconf retrieval path to this particular object


  },


},


"GENERIC-RESOURCE-API:service-response-information": {


  "GENERIC-RESOURCE-API:instance-reference": {   


"GENERIC-RESOURCE-API:instance-id": "",// same 
as service-instanceid passed by SO in the request, is it ok ?// hzy: ok!


"GENERIC-RESOURCE-API:object-path": "",   // can be 
empty ? //hzy: It seems ok by now.


  },


},


  }


 


For “underlay” delete request, I think SO need to send this network-id. Please 
find the same request for below..


 


{


  "GENERIC-RESOURCE-API:input": {


"GENERIC-RESOURCE-API:sdnc-request-header": {


  "GENERIC-RESOURCE-API:svc-request-id": "",  // Uniquely 
generated by calling system


  "GENERIC-RESOURCE-API:svc-action": "",   // delete


  "GENERIC-RESOURCE-API:svc-notification-url": "" 


},


"GENERIC-RESOURCE-API:request-information": {


  "GENERIC-RESOURCE-API:request-action": "",  // DeleteNetworkInstance


  "GENERIC-RESOURCE-API:notification-url": "",


  "GENERIC-RESOURCE-API:order-version": "",


  "GENERIC-RESOURCE-API:request-id": "",  // Uniquely generated by calling 
system


  "GENERIC-RESOURCE-API:order-number": "",


  "GENERIC-RESOURCE-API:source": "so"


},


"GENERIC-RESOURCE-API:service-information": {


  "GENERIC-RESOURCE-API:global-customer-id": "", // need for put of 
data to AnAI (SO provides)


  "GENERIC-RESOURCE-API:subscription-service-type": "",   // reference to 
a subscription-service-type


  "GENERIC-RESOURCE-API:service-id": "",
   // servive-instance-id from SO


  "GENERIC-RESOURCE-API:service-instance-id": "", // 
reference to a service-instance-id


  "GENERIC-RESOURCE-API:ecomp-model-information": {   


"GENERIC-RESOURCE-API:model-customization-uuid": "",


"GENERIC-RESOURCE-API:model-invariant-uuid": "",


"GENERIC-RESOURCE-API:model-name": "",


"GENERIC-RESOURCE-API:model-uuid": "",


"GENERIC-RESOURCE-API:model-version": ""


  },


  "GENERIC-RESOURCE-API:subscriber-name": "" 


},


"GENERIC-RESOURCE-API:network-information": {


  "GENERIC-RESOURCE-API:network-id": "",  // network-instance 
id provided by SDNC in “create” response


  "GENERIC-RESOURCE-API:network-type": "",  


  "GENERIC-RESOURCE-API:ecomp-model-information": {   


"GENERIC-RESOURCE-API:model-customization-uuid": "",


"GENERIC-RESOURCE-API:model-invariant-uuid": "",


"GENERIC-RESOURCE-API:model-name": "",


"GENERIC-RESOURCE-API:model-uuid": "",


"GENERIC-RESOURCE-API:model-version": ""


  },


},


"GENERIC-RESOURCE-API:network-request-input": {


  "GENERIC-RESOURCE-API:network-name": "",   


  "GENERIC-RESOURCE-API:region-identifier": {


"GENERIC-RESOURCE-API:tenant": "",  



"GENERIC-RESOURCE-API:aic-cloud-region": "",   


"GENERIC-RESOURCE-API:aic-clli": "",

[onap-discuss] about the extZteVL / extZteVDU / extZteCP

2017-09-29 Thread huang.zhuoyao

Hi Michael,






   I found three new types of resource in sdc repository: 
sdc/catalog-be/src/main/resources/import/tosca/onap-types. May I ask their 
usage and why they got a name with ZTE? Thank you very much!


   






Best regards! 































黄卓垚huangzhuoyao






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









深圳市南山区科技南路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___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] 答复: Re: 答复：[vfc][sdnc] How VFC will store network info in A

2017-09-30 Thread huang.zhuoyao

Hi Yang,







I'm not sure about some detail of the overlay vpn deployment, could you 
help me about that? Thank you!






 Vxlan tunnel model driven deployment is supported?


 If yes, which parameters of overlayTunnel.yml are related to vxlan tunnel, and 
how do they work?


The 3rd party controller NBI of vxlan tunnel is provider related, right?


Does SO controls the deployment sequence as: underlay vpn / vxlan tunnel / 
overlay vpn? Or So controls the deployment sequence as: underlay vpn / vxlan 
tunnel & overlay vpn, and then sdnc splits the data and launches the deployment 
in sequence of: vxlan tunnel / overlay vpn? Or any other way for the deployment 
sequence control?


The overlay vpn is supported in Release 1, even though the M4 has already past?






Best regards! 



















黄卓垚huangzhuoyao






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









深圳市南山区科技南路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

 



原始邮件



发件人： ;
收件人： ;张茂鹏10030173;
抄送人： ;
日 期 ：2017年09月28日 15:13
主 题 ：Re: [onap-discuss] 答复：[vfc][sdnc] How VFC will store network info in A






Hi Maopeng,
 
 We discussed this topic in F2F meeting yesterday. Would you please provide us 
the name of the developer who can help on VFC side so we can follow up 
directly? time is running out, please help.
 
 Thanks,
 -Yang
 
 Sent from HUAWEI AnyOffice
 


From:Gaurav agrawal

To:zhang.maope...@zte.com.cn,Yang Xu (Yang, Fixed Network)

Cc:onap-discuss@lists.onap.org

Date:2017-09-27 09:32:53

Subject:RE: [onap-discuss] 答复：[vfc][sdnc] How VFC will store network info in 
A

 


Hi Maopeng,


 


Let me provide my understanding on this topic, @Yang Xu please add to it.


 


This is required in case of VoLTE use case wherein SDNC needs to associate 
local network within datacenter to a VXLAN tunnel available between datacenters 
(edge and core). In this regard we expect user to input the network name and 
find the associated networkId in SDNC by referring to  the local network 
information added by VFC in A


 


Input from UUI 
(https://gerrit.onap.org/r/#/c/12933/2/catalog-be/src/main/resources/import/tosca/normative-types/overlayTunnel/overlayTunnel.yml)





 


Request to 3rd party controller from SDNC:


{


"l3-dci-connect": {


"id": "CDD702C3-7719-4FE6-A5AD-3A9C9E265309", 


 "name": "PODX-routerY", 


 "description": "VPC A connect VPC B", 


 "router_id": "CBB702C3-6789-1234-A5AD-3A9C9E265309", 


 "firewall_enable":  "false“ //false


"local_networks": 
["8a41319d-87cf-4cd6-8957-f4a1066c63a8","c1134ed3-dce8-41c4-af81-2b15834f0c7a"],
 


 "local_network_all":false, 


 "evpn_irts":  ["1:5000"],  


 "evpn_erts":  ["1:5000" ], 


 "l3_vni": "5001", 


 }


}


 


Thanks and Regards,


Gaurav


 



From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of 
zhang.maope...@zte.com.cn
 Sent: 2017年9月26日  13:11
 To: Yang Xu (Yang, Fixed Network)
 Cc: onap-discuss@lists.onap.org
 Subject: [onap-discuss] 答复：[vfc][sdnc] How VFC will store network info in A



 


hi yang 
 
 could you clearfy the network and subnetwork info from sdnc in the whole case, 
and how does the sdnc use it? 
 
 
 BR 
 maopeng 
 
 


原始邮件 



发件人： YangXu(Yang,FixedNetwork); 



收件人： 张茂鹏10030173; onap-discuss@lists.onap.org; 



抄送人： chinamobile; 



日期：2017-09-21 14:35:16



主题：[vfc][sdnc] How VFC will store network info in A 




Hi Maopeng and VFC team,


 


SDNC team needs to know some information about the networks created by VFC, 
e.g. network id and subnet. Where does VFC store the network information in 
A? Can you point to us A node and attributes used for such information? 
An A  query example would be greatly appreciated.


 


Regards,


-Yang___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] About the GENERIC-RESOURCE-API

2017-08-28 Thread huang.zhuoyao

Hi Dan,




Could you help me about the GENERIC-RESOURCE-API?  I saw your update on 
wiki page: https://wiki.onap.org/display/DW/SDNC+APIs, but I have not found the 
seed code on gerrit yet. If I want to invoke GENERIC-RESOURCE-API on SO, all I 
need is to follow the example of GENERIC-RESOURCE-API(2016-11-11).json which is 
downloaded from wiki page? Or I should refer to other seed code?




Thank you and best regards!




















黄卓垚huangzhuoyao






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









深圳市南山区科技南路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___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] 答复: Re: About the GENERIC-RESOURCE-API

2017-08-28 Thread huang.zhuoyao

Thank you very much! 




















黄卓垚huangzhuoyao






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









深圳市南山区科技南路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








原始邮件



发件人： 
收件人：黄卓垚10112215 
抄送人：  
日 期 ：2017年08月29日 11:12
主 题 ：Re: [onap-discuss] About the GENERIC-RESOURCE-API





Hi Zhuoyao,
 
 Saw the below patch in gerrit for generic-resource-api, maybe can help.
 
 https://gerrit.onap.org/r/#/c/8531/
 
 Thanks and Regards,
 Gaurav


From:huang.zhuo...@zte.com.cn

To:dtimo...@att.com,

Cc:onap-discuss@lists.onap.org,bdfreeman1...@gmail.com,

Date:2017-08-29 07:10:04

Subject:[onap-discuss] About the GENERIC-RESOURCE-API

 



Hi Dan,


 

Could you help me about the GENERIC-RESOURCE-API?  I saw your  update 
on wiki page: https://wiki.onap.org/display/DW/SDNC+APIs, but I have not found 
the seed code on gerrit yet. If I want to invoke GENERIC-RESOURCE-API on SO, 
all I need is to follow the example of GENERIC-RESOURCE-API(2016-11-11).json 
which is downloaded from wiki page? Or I should refer to other seed code?


 

Thank you and best regards!


 


 


 


 





 


黄卓垚huangzhuoyao



 


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



 





 深圳市南山区科技南路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___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] About the time out of generic-resource-api ////////////////////答复: 【SDNC SO 讨论纪要】

2017-09-01 Thread huang.zhuoyao

Hi, Dan





As I know, generic-resource-api invoke DG in a synchronous way. But I'm not 
sure how long it would go time out after the invoking the DG with no response. 
And it seams 500 return for all kinds of internal exception including time out 
exception. How could I know whether is it a timeout exception? Would you please 
help me about the time out issue?  And if I'm wrong, please correct me. 
Besides, is it possible for generic-resource-api to run in a asynchronous way, 
which could return fast and support progress feedback? 




Thank you and best regards!




















黄卓垚huangzhuoyao






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









深圳市南山区科技南路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





原始邮件



发件人： 
收件人：黄卓垚10112215
抄送人：    

日 期 ：2017年09月01日 11:36
主 题 ：【SDNC SO 讨论纪要】







Hi


 


 


1.  关于SO 提供给USECASEUI 
提供的北向接口，https://wiki.onap.org/display/DW/SO+R1+Interfaces?preview=/13600660/13600657/SO%20API%20v0.1.pdf


2.  在VOLTE用例中，关于SDC发给SO，刷新catalog-db刷新的数据，麻烦传雨反馈下最新进展。


 


3.  SO Main Process 和 SO SDN-C Sub Process 之间的参数。


 


输入参数如下：


Map  inputsMap = HashMap()


inputsMap.put(“key1”,“value1”)


inputsMap.put(“key2”,“value2”)


execution.setVariable(“SDCADAPTOR_INPUTS”, inputsMap)


execution.setVariable(“SDNC_Service_TEMPLATE_ID”, wanTemplateID)   
//这个依赖于SDNC提供的数据，可能是模板ID，可能是CSAR ID


 


输出参数，麻烦zhuoyao确认下，SDNC 提供接口，是否耗时，SDNC测是否会提供耗时的处理建议。


 


 


 


 


 


 


Best wishes


Jinxin


 


***
 
本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！**
 
 
***
 This e-mail and its attachments contain confidential information from HUAWEI, 
which is intended only for the person  or entity whose address is listed above. 
Any use of the information contained herein in any way (including, but not   
limited to, total or partial disclosure, reproduction, or dissemination) by 
persons other than the intended recipient(s) is  prohibited. If you receive 
this e-mail in error, please notify the sender by phone or email immediately 
and delete it!
 
***___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] 答复: Re: [aai][sdnc] The sdnc schema and Thirdparty-sdnc schema in A

2017-08-29 Thread huang.zhuoyao

Is location truly just “Core” or “Edge”, or could it be geographic?  In other 
words, do we need to take geography into account when querying for a third 
party controller?


LiZi: For Amsterdam release, there will be only one type of thirdparty sdn 
controller for one network, so temporarily in R1, the location will just “Core” 
or “Edge”. But infuture it could be geographic. Am I correct? @Zhuoyao


Zhuoyao: Yes, I think so.







黄卓垚huangzhuoyao






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









深圳市南山区科技南路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

 



原始邮件



发件人：李滋00164331
收件人： 黄卓垚10112215
抄送人：  
日 期 ：2017年08月29日 19:08
主 题 ：Re: [aai][sdnc] The sdnc schema and Thirdparty-sdnc schema in A







Hi Dan,




Replies sees below.




Thanks,

LiZi






















发件人： 
收件人：李滋00164331  黄卓垚10112215 

抄送人： 
日 期 ：2017年08月29日 02:54
主 题 ：Re: [aai][sdnc] The sdnc schema and Thirdparty-sdnc schema in A







LiZi,


 


The current SDN-C design would just use a properties file to map the URL, 
credentials, etc for one specific instance of a third party SDN controller.  f 
I understand this correctly, it looks like this model allows for multiple 
addresses  for a particular third party SDN controller, which is clearly a good 
thing but does introduce new complexities.


LiZi: According to the requirement there need a container to store the 
generic-address node, actually, there will be only one address for a thirdparty 
SDN Controller.


 


For Amsterdam, can we make a simplifying assumption that there will be only one 
instance of each third party SDN controller?If so, then it should be fairly 
straightforward I think for SDN-C to convert over to using ESR to retrieve the  
URL and credentials of the third party SDN controller.  There are still some 
details to be worked, like where we’d get the third-party-sdn-id (I’m guessing 
from TOSCA?), but that should be manageable.


LiZi: Yes, For Amsterdam, there will be only one instance for each third party 
SDN controller. As discussed with Zhuoyao, We have two ways to connect WAN with 
third party SDN controller. If I am misunderstand anything please correct me.






1. connect at design time, In SDC there is a way to input Service-type, 
for the value we can input vendor to this property. For Amsterdam, we assume 
that there will be one controller for each vendor. And then, create a 
relationship between WAN controller with thirdparty-sdnc while initial the WAN 
controller.






2. connect at runtime, when initial the WAN at runtime, user can query 
all the registered thirdparty-sdnc and select one to bind with WAN controller 
with lifecycle management portal. This way we need to discuss with the Usecase 
UI team.



 Since there is less than two weeks for us before the code freeze deadline. So 
personaly I suggest we take the aproach 1 for Amsterdam release.






If not, then I think there are a few questions/issues we’ll need to resolve to 
determine how to select the correct third party SDN-C URL and credentials:


 

Is location truly just “Core” or “Edge”, or could it be geographic?  In other 
words, do we need to take geography into account when querying for a third 
party controller?

LiZi: For Amsterdam release, there will be only one type of thirdparty sdn 
controller for one network, so temporarily in R1, the location will just “Core” 
or “Edge”. But infuture it could be geographic. Am I correct? @Zhuoyao


Each thirdparty-sdnc-info record seems like it can have multiple 
generic-addresses, but I don’t see a field that tells indicates whether load 
should be distributed evenly (round-robin)  across instances, or if the list is 
to be treated as priority order (primary, secondary, tertiary, etc).  Is that 
because for Amsterdam, we are assuming always one mode of distribution?

LiZi: Actually, there will be only one generic-address for each 
thirdparty-sdnc-info, for A schema, there need a container to nest a node.


 


Would it be acceptable to assume only one instance of each third party SDN 
controller for Amsterdam?


LiZi: Totally, I agree with you.


 


Separate but related question – the SDN-C developers asked me if I could set up 
a review of the VoLTE transaction flow for them.  Would you be the right person 
to help us with that, and if so, can we set up a call in the next day or so  to 
do that?


 LiZi: I agree, I think we need a meeting to discuss these issues. If there is 
a meeting I will join, I can share what I know and what I am thinking of, but I 
don't think I can be the leading role. :-)






Thanks!

[onap-discuss] 答复: RE: How to commit the files about WAN modeling?

2017-08-31 Thread huang.zhuoyao

Hi, David and Michael

I'm not sure about that is it suitable to push the yaml files about WAN 
description of Volte use case to SDC? Would you please help me about that?

Thanks and best regards!


















黄卓垚huangzhuoyao






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









深圳市南山区科技南路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

 



原始邮件



发件人： 
收件人：黄卓垚10112215  
抄送人： 袁越10008526孟照星10024238张茂鹏10030173 
 
日 期 ：2017年08月23日 15:03
主 题 ：RE: How to commit the files about WAN modeling?







Hi, Zhuoyao


 


For modeling code, have you decided together with David about whether to build 
WAN resrouce in SDC based on VF or VL? You could upload to SDC to  check 
whether their committers agree or not.


 


For modeling spec, once it is finalized in modeling committee, it will be kept 
in the repo of modeling project.


 


Thanks


 


DENG Hui


 


From: huang.zhuo...@zte.com.cn [mailto:huang.zhuo...@zte.com.cn] 
 Sent: Wednesday, August 23, 2017 9:55 AM
 To: denghui (L)  ml6...@intl.att.com
 Cc: Patrick Liu  yuan@zte.com.cn 
meng.zhaoxi...@zte.com.cn zhang.maope...@zte.com.cn denglin...@chinamobile.com 
onap-discuss@lists.onap.org
 Subject: How to commit the files about WAN modeling?


 

Hi, DengHui and Michael

Would you please help me about this issue? I don't know how to commit 
the files about WAN modeling. Should I push them to SDC gerrit, or modeling 
gerrit, or somewhere else?

Thank you very much!

 

 

 

 



 


黄卓垚huangzhuoyao


 


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


 






 深圳市南山区科技南路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

underlayVPN_template.yaml
Description: Binary data


underlayVPN_type_definition.yaml
Description: Binary data
___
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

[onap-discuss] 答复: Re: 答复：[vfc][sdnc][so] How VFC will store network info in A

2017-10-09 Thread huang.zhuoyao

Hi Gaurav,






Yes, it is network id.







Thank you and best regards!



























黄卓垚huangzhuoyao






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









深圳市南山区科技南路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








原始邮件



发件人： ;
收件人：黄卓垚10112215;
抄送人： ; ;
日 期 ：2017年10月09日 13:57
主 题 ：Re: [onap-discuss]答复：[vfc][sdnc][so] How VFC will store network info in 
A








Hi Zhuoyao,


 


Thanks for the update.


 


I agree with you that deactivation via site id is not a right way as SO should 
be transparent to network parameters. Regarding uuid for deactivation I assume  
you are referring to network-id. In my understand the flow is, during 
activation SDNC will feedback the network-id to SO and during deactivation SO 
is expected to provide the network-id pointing to network which needs to be 
deactivated, is that your understanding  too?


 


VoLTE overlay DGs for both activate and deactivate flow is added in SDNC and 
can be referred. Kindly let me know if you have any queries or any other sync 
up  is required for overlay.


 


Thanks and Regards,


Gaurav


 



From: huang.zhuo...@zte.com.cn [mailto:huang.zhuo...@zte.com.cn] 
 Sent: 2017年10月9日  8:13
 To: Gaurav agrawal
 Cc: Yang Xu (Yang, Fixed Network); onap-discuss@lists.onap.org; 
ramu@gmail.com; Jinxin (Saw)
 Subject: 答复: Re: [onap-discuss]答复：[vfc][sdnc][so]  How VFC will store network 
info in A



 

Hi Gaurav, 



I think a little more work is needed for overlay-vpn deployment in 
SO, such as a flag is needed for marking the overlay  parameters and underlay 
parameters, and activation and deactivation  sequence control.

Site id might not be passed to SDNC in deactivation, but a uuid of 
overlay-vpn for now. I guess we could get the site id from AAI by overlay-vpn 
uuid. If it doesn't work, we could  make some change about it.

 

Thank you and best regards! 





 

 

 

 

 


黄卓垚huangzhuoyao


 


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


 






 深圳市南山区科技南路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


 





原始邮件



发件人： ;



收件人： ;黄卓垚10112215;



抄送人： ;



日 期 ：2017年10月03日 20:29



主 题 ：Re: [onap-discuss]答复：[vfc][sdnc][so] How VFC will store network info in 
A




 



Hi Zhuoyao,


 


Do you have any idea whether the SO development completed for OverlayVpn 
deployment? If yes for deactivation  whether it’s going to pass siteId to SDNC?


 


Thanks and Regards,


Gaurav


 



From: Yang Xu (Yang, Fixed  Network) 
 Sent: 2017年10月1日   17:33
 To: huang.zhuo...@zte.com.cn
 Cc: Gaurav agrawal; zhang.maope...@zte.com.cn; onap-discuss@lists.onap.org
 Subject: RE: Re: [onap-discuss] 答复：[vfc][sdnc] How VFC will store network info 
in A




 


Hi Zhuoyao,


 


I am on travel, and will be back to office on Monday 10/2. You can schedule  a 
zoom meeting with  me on Monday EST to clarify your questions. See my brief 
answers  inlined below.


 


Thanks,


-Yang   


 



From: huang.zhuo...@zte.com.cn [mailto:huang.zhuo...@zte.com.cn] 
 Sent: Saturday, September 30, 2017 9:18 AM
 To: Yang Xu (Yang, Fixed Network)
 Cc: Gaurav agrawal; zhang.maope...@zte.com.cn; onap-discuss@lists.onap.org
 Subject: 答复: Re: [onap-discuss] 答复：[vfc][sdnc] How VFC will store network info 
in A



 

Hi Yang,

 

I'm not sure about some detail of the overlay vpn deployment, could you 
help me about that? Thank you!

 


1.   Vxlan tunnel model driven deployment is supported? [Yang] Yes, but 
only the part connecting the networks on edge and core data centers  is modeled 
 by overlay template. 


2.   If yes, which parameters of overlayTunnel.yml are related to vxlan 
tunnel, and how do they work? [Yang] The parameters in overlayTunnel.yml  
defines  how to connect the networks in two data centers, not about how to set 
up VXLAN tunnels. 


3.  The 3rd party controller NBI of vxlan tunnel is provider related, 
right? [Yang] VXLAN set up API is vendor related, but API to connect  the 
networks  on the two data centers are vendor agnostic. 


4.  Does SO controls the deployment sequence as: underlay vpn / vxlan 
tunnel / overlay vpn? Or So controls the deployment sequence as: underlay vpn / 
vxlan tunnel & overlay  vpn,  and then sdnc splits the data and launches the 
deployment in sequence of: vxlan tunnel / overlay vpn? Or any other way

[onap-discuss] 答复: RE: Re: 答复：[vfc][sdnc][so] How VFC will store network info in A

2017-10-11 Thread huang.zhuoyao

Hi Gaurav,






Thank you for your remind.






Best regards!























黄卓垚huangzhuoyao






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









深圳市南山区科技南路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

 



原始邮件



发件人： ;
收件人：黄卓垚10112215;
抄送人： ; ;
日 期 ：2017年10月11日 13:21
主 题 ：RE: Re: [onap-discuss]答复：[vfc][sdnc][so] How VFC will store network info 
in A








Hi Zhuoyao,


 


One more thing which needs to be considered while overlay implementation in SO.


For activate it will be required to provide svc-action as “activate” and 
request-action as “ActivateDCINetworkInstance”


For deactivate it will be required to provide svc-action as “deactivate” and 
request-action as “DeActivateDCINetworkInstance”


 


Thanks and Regards,


Gaurav


 



From: huang.zhuo...@zte.com.cn [mailto:huang.zhuo...@zte.com.cn] 
 Sent: 2017年10月9日  13:24
 To: Gaurav agrawal
 Cc: Jinxin (Saw); onap-discuss@lists.onap.org
 Subject: 答复: Re: [onap-discuss]答复：[vfc][sdnc][so]  How VFC will store network 
info in A



 

Hi Gaurav,

 

Yes, it is network id.

 

Thank you and best regards!

 

 

 

 

 


黄卓垚huangzhuoyao


 


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


 






 深圳市南山区科技南路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


 





原始邮件



发件人： ;



收件人：黄卓垚10112215;



抄送人： ; ;



日 期 ：2017年10月09日 13:57



主 题 ：Re: [onap-discuss]答复：[vfc][sdnc][so] How VFC will store network info in 
A




 



Hi Zhuoyao,


 


Thanks for the update.


 


I agree with you that deactivation via site id is not a right way as SO should 
be transparent to  network parameters. Regarding uuid for deactivation I assume 
 you are referring to network-id. In my understand the flow is, during 
activation SDNC will feedback the network-id to SO and during deactivation SO 
is expected to provide the network-id pointing  to network which needs to be 
deactivated, is that your understanding  too?


 


VoLTE overlay DGs for both activate and deactivate flow is added in SDNC and 
can be referred. Kindly  let me know if you have any queries or any other sync 
up  is required for overlay.


 


Thanks and Regards,


Gaurav


 



From: huang.zhuo...@zte.com.cn [mailto:huang.zhuo...@zte.com.cn] 
 Sent: 2017年10月9日   8:13
 To: Gaurav agrawal
 Cc: Yang Xu (Yang, Fixed Network); onap-discuss@lists.onap.org; 
ramu@gmail.com; Jinxin (Saw)
 Subject: 答复: Re: [onap-discuss]答复：[vfc][sdnc][so]   How VFC will store network 
info in A



 

Hi Gaurav, 



I think a little more work is needed for overlay-vpn deployment in 
SO, such as a flag is needed for marking the overlay  parameters and underlay 
parameters, and activation and deactivation   sequence control.

Site id might not be passed to SDNC in deactivation, but a uuid of 
overlay-vpn for now. I guess we could get the site id from AAI by overlay-vpn 
uuid. If it doesn't work, we could   make some change about it.

 

Thank you and best regards! 





 

 

 

 

 


黄卓垚huangzhuoyao


 


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


 






 深圳市南山区科技南路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


 





原始邮件



发件人： ;



收件人： ;黄卓垚10112215;



抄送人： ;



日 期 ：2017年10月03日 20:29



主 题 ：Re: [onap-discuss]答复：[vfc][sdnc][so] How VFC will store network info in 
A




 



Hi Zhuoyao,


 


Do you have any idea whether the SO development completed for OverlayVpn 
deployment? If yes for deactivation   whether it’s going to pass siteId to SDNC?


 


Thanks and Regards,


Gaurav


 



From: Yang Xu (Yang, Fixed   Network) 
 Sent: 2017年10月1日17:33
 To: huang.zhuo...@zte.com.cn
 Cc: Gaurav agrawal; zhang.maope...@zte.com.cn; onap-discuss@lists.onap.org
 Subject: RE: Re: [onap-discuss] 答复：[vfc][sdnc] How VFC will store network info 
in A




 


Hi Zhuoyao,


 


I am on travel, and will be back to office on Monday 10/2. You can schedule  a 
zoom meeting with   me on Monday EST to clarify your questions. See my brief 
answers  inlined below.


 


Thanks,


-Yang   


 



From: huang.zhuo...@zte.com.cn

[onap-discuss] 答复: Fw:Re: [sdc][vfc] SDC questions from VF-C

[onap-discuss] 答复: Re: [onap-tsc][SDNC] [SO] Hi, Here is the remain questions// summary and proposed action for SPTN WAN Model and implementation

[onap-discuss] about disscuss in VoLTE [SO] / [SDNC] Interface discussion (8/11, 10:00 pm UTC8 / 10:00 am EST )

[onap-discuss] 答复: RE: Here is a question about SDN-C adapter,wouldyouplease help me about it? Thank you!

[onap-discuss] 答复: RE: Here is a question about SDN-C adapter,wouldyouplease help me about it? Thank you!

[onap-discuss] 答复: RE: Here is a question about SDN-C adapter,wouldyouplease help me about it? Thank you!

[onap-discuss] 答复: RE: Re: [onap-tsc]答复: Re: ONAP VoLTE SDC call

[onap-discuss] 答复: Re: [onap-tsc]答复: Re: ONAP VoLTE SDC call

[onap-discuss] 答复: Re: [onap-tsc] ONAP VoLTE SDC call

[onap-discuss] 答复: Re: [onap-tsc] ONAP VoLTE SDC call

[onap-discuss] 答复: Re: [onap-tsc] ONAP VoLTE SDC call

[onap-discuss] How to commit the files about WAN modeling?

[onap-discuss] about network-topology-operation

[onap-discuss] 答复: Re: [sdc] About underlayvpn.yml

[onap-discuss] 答复: Re: 答复: RE: How to commit the files about WAN modeling?

[onap-discuss] 答复: RE: About underlayvpn.yml

[onap-discuss] About underlayvpn.yml

[onap-discuss] 答复: [SO][SDNC] About underlay vpn deployment

[onap-discuss] about the extZteVL / extZteVDU / extZteCP

[onap-discuss] 答复: Re: 答复：[vfc][sdnc] How VFC will store network info in A

[onap-discuss] About the GENERIC-RESOURCE-API

[onap-discuss] 答复: Re: About the GENERIC-RESOURCE-API

[onap-discuss] About the time out of generic-resource-api ////////////////////答复: 【SDNC SO 讨论纪要】

[onap-discuss] 答复: Re: [aai][sdnc] The sdnc schema and Thirdparty-sdnc schema in A

[onap-discuss] 答复: RE: How to commit the files about WAN modeling?

[onap-discuss] 答复: Re: 答复：[vfc][sdnc][so] How VFC will store network info in A

[onap-discuss] 答复: RE: Re: 答复：[vfc][sdnc][so] How VFC will store network info in A

27 matches

Site Navigation

Mail list logo

Footer information