Re: [onap-discuss] [Onap-usecasesub] [**EXTERNAL**] [onap-tsc] The summary of Usecase subcommittee meeting 14/05/2017 - Casablanca use cases/functional requirements endorsement

[Parviz Yegani]

Is this meeting on? I dialed in ..it says the meeting has not started;)

Regards,
Parviz

---
PARVIZ YEGANI, PhD
Chief SDN/NFV Architect
CTO Office, Cloud Network Solutions

FutureWei Technologies, Inc.
2330 Central Express Way
Santa Clara, CA 95050, USA
Phone: +1 (408) 330-4668
Mobile : +1 (408) 759-1973
parviz.yeg...@huawei.com<mailto:parviz.yeg...@huawei.com>



From: Cheung, Ben (Nokia - US/Murray Hill) [mailto:ben.che...@nokia.com]
Sent: Wednesday, May 30, 2018 9:19 AM
To: VAN BRAKLE, TRACY L ; Parviz Yegani 
; Ranganathan, Raghu 
Cc: TIMONEY, DAN ; SMITH JR., PAUL ; onap-tsc 
; Dhananjay Pavgi ; 
onap-discuss@lists.onap.org; onap-usecase...@lists.onap.org; Horn, Linda (Nokia 
- US/Murray Hill) ; Hillis, Marge (Nokia - US) 
; Nowak, Damian (Nokia - PL/Wroclaw) 

Subject: RE: [Onap-usecasesub] [**EXTERNAL**] [onap-tsc] The summary of Usecase 
subcommittee meeting 14/05/2017 - Casablanca use cases/functional requirements 
endorsement

Tracy,

   None of us can get on this SDN-R zoom call … (says host has another meeting 
in progress)

Best regards,
-Ben Cheung, PhD, DMTS, ALTA
  ATF Architecture Systems Engineer
  Mobile Networks, Nokia
  Tel +1 (908) 679-6615
  Email  ben.che...@nokia.com<mailto:ben.che...@nokia.com>
  600-700 Mountain Ave, Murray Hill, NJ 07974-0636 USA / #2C-378

From: 
onap-usecasesub-boun...@lists.onap.org<mailto:onap-usecasesub-boun...@lists.onap.org>
 [mailto:onap-usecasesub-boun...@lists.onap.org] On Behalf Of VAN BRAKLE, TRACY 
L
Sent: Wednesday, May 30, 2018 6:15 AM
To: Parviz Yegani mailto:parviz.yeg...@huawei.com>>; 
Ranganathan, Raghu mailto:rra...@ciena.com>>
Cc: TIMONEY, DAN mailto:dt5...@att.com>>; SMITH JR., PAUL 
mailto:ps7...@att.com>>; onap-tsc 
mailto:onap-...@lists.onap.org>>; Dhananjay Pavgi 
mailto:dp00476...@techmahindra.com>>; 
onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>; 
onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org>
Subject: Re: [Onap-usecasesub] [**EXTERNAL**] [onap-tsc] The summary of Usecase 
subcommittee meeting 14/05/2017 - Casablanca use cases/functional requirements 
endorsement

Parviz,
Raghu,

Please join the weekly SDN-R call (see below) to discuss this topic.

We can allow 15 or 20 minutes on the agenda for the call today, May 30th, or 
for the call next week, June 6th  - just let me know your preference.

Thank you in advance,

Tracy

Tracy Van Brakle mailto:vanbra...@att.com>>
AT&T Labs - Wireless Network Architecture and Design
+1 732.420.3003  office
+1 732.306.2387  cell


[sdnr] team meeting (updated Apr. 3, 2018)
When

Weekly from 9am to 10am on Wednesday from Wed Apr 4 to Wed Mar 13, 2019 Pacific 
Time

Where

https://zoom.us/j/502876187<https://urldefense.proofpoint.com/v2/url?u=https-3A__zoom.us_j_502876187&d=DwQFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=7TfzZqNtM8rzzpoqgbTKTw&m=AHXO5YHRW_Gzfg7saO8FEW35tAJwGEXy3BnSeOEsA1E&s=z3Du9SfpzoCOGcpc-3C2At0v8ZB2iO0YQkVcZPhCfZA&e=>
 
(map<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.google.com_url-3Fq-3Dhttps-253A-252F-252Fzoom.us-252Fj-252F502876187-26sa-3DD-26usd-3D2-26usg-3DAFQjCNGBy9wN4iPnChWbXF4om9L8rybi9A&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=7TfzZqNtM8rzzpoqgbTKTw&m=AHXO5YHRW_Gzfg7saO8FEW35tAJwGEXy3BnSeOEsA1E&s=IGK8tA7A0zQa4qBM1pNLcC3qERjT55I1_NHRjuQOFPw&e=>)

Calendar

tv8...@att.com<mailto:tv8...@att.com>






From: 
onap-usecasesub-boun...@lists.onap.org<mailto:onap-usecasesub-boun...@lists.onap.org>
 
mailto:onap-usecasesub-boun...@lists.onap.org>>
 On Behalf Of Parviz Yegani
Sent: Wednesday, May 30, 2018 2:03 AM
To: Ranganathan, Raghu mailto:rra...@ciena.com>>
Cc: TIMONEY, DAN mailto:dt5...@att.com>>; onap-tsc 
mailto:onap-...@lists.onap.org>>; Dhananjay Pavgi 
mailto:dp00476...@techmahindra.com>>; 
onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>; 
onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org>
Subject: Re: [Onap-usecasesub] [**EXTERNAL**] [onap-tsc] The summary of Usecase 
subcommittee meeting 14/05/2017 - Casablanca use cases/functional requirements 
endorsement

Hi Raghu,

I think we need to have a call to discuss SDN-R and it’s relation to SDN-C. 
I’ll be happy to send an invite for this.

How about Thursday, 1:00PM Pacific?

Regards,
Parviz

---
PARVIZ YEGANI, PhD
Chief SDN/NFV Architect
CTO Office, Cloud Network Solutions

FutureWei Technologies, Inc.
2330 Central Express Way
Santa Clara, CA 95050, USA
Phone: +1 (408) 330-4668
Mobile : +1 (408) 759-1973
parviz.yeg...@huawei.com<mailto:parviz.yeg...@huawei.com>



From: Ranganathan, Raghu [mailto:rra...@ciena.com]
Sent: Tuesday, May 22, 2018 5:39 PM
To: Parviz Yegani mailto:parviz.yeg...@huawei.com>>
Cc: TIMONEY, DAN mailto:dt5...@att.com>>; Alla Goldner 
mailto:alla.gold...@amdocs.com>>; Vladimir Yanover 
(vyanover) mailto:

Re: [onap-discuss] [onap-tsc] [Onap-usecasesub] The summary of Usecase subcommittee meeting 14/05/2017 - Casablanca use cases/functional requirements endorsement

[Parviz Yegani]

Hi Dan,

Thanks for the clarification. I checked the SDN-R documents on the wiki page …

According to the SDN-R subproject proposal (drafted Nov. 2017) the following 
features are in scope for R2:


· Enhancements to support the ONAP release 2 use cases, e.g., RAN 
deployment, Slicing, SON

o   Yang models

o   Directed graphs

o   New Adapters needed to support use cases (details to be determined during 
planning phase)



· Support for third party controllers

o   Adapter to allow DG to connect to netconf devices
This is inline with what I said in my previous email (see below). Ie, for the 
SDN-R (based on SDN-C plus any additional capability)
the DG config node in SDN-C is enhanced to enable 3rd party controllers to 
connect wireless network devices (netconf, ..) via the SB
network adapters. So, the current SDN controller hierarchy (global+local) stays 
intact.

Rgds,
Parviz

From: TIMONEY, DAN [mailto:dt5...@att.com]
Sent: Thursday, May 17, 2018 5:50 AM
To: Parviz Yegani ; Alla Goldner 
; Vladimir Yanover (vyanover) ; 
Dhananjay Pavgi ; SHANKARANARAYANAN, N K 
; onap-usecase...@lists.onap.org
Cc: onap-discuss@lists.onap.org; onap-tsc 
Subject: Re: [onap-tsc] [Onap-usecasesub] The summary of Usecase subcommittee 
meeting 14/05/2017 - Casablanca use cases/functional requirements endorsement

All,

I think perhaps when thinking about the relationship between SDN-R and SDN-C, 
it might be helpful to draw a parallel to OpenDaylight.   OpenDaylight consists 
of many projects (the project list on their Gerrit is 4 pages long, with about 
25 per page – so close to a hundred), but a given deployment of the 
OpenDaylight platform will generally use only a handful of those that it needs 
to implement its specific domain.

I see the SDNC project in ONAP as being similar.  SDNC is the sole Network 
Controller project in ONAP, which contains a set of components that can be used 
for different network domains / functions.   As we add more and more 
functionality over time, we are likely to find that carriers will choose to 
deploy only a subset of those components, or to deploy multiple instances of 
SDNC-based controllers with different components installed/enabled in order to 
segment their traffic load.  We’re not prescribing or proscribing any of those 
deployment options:  we’re just providing a base platform that we’ve tested in 
a specific configuration with specific use cases.


I think perhaps the confusion is that we’ll often use that term SDN-R to refer 
to 2 different things:


  1.  A software development deliverable (Epic) for the ONAP Casablanca 
release, which will deliver a number of new components to SDNC that are useful 
for radio configuration.
  2.  A specific instance of a network controller that uses those components to 
implement radio network configuration.

That first usage above is the work we’re planning for Casablanca.  The second 
is a possible deployment option that we suspect many carriers will choose.  
However, if for whatever reason a carrier wanted to also use that same instance 
to support other functionality, that really just boils down to an engineering 
decision.  Our software architecture won’t require the SDN-R functionality to 
be deployed separately from other SDN functionality.

I hope this helps,

Dan


--
Dan Timoney
SDN-CP / OpenECOMP SDN-C SSO

Please go to  D2 ECOMP Release Planning 
Wiki<https://wiki.web.att.com/display/DERP/D2+ECOMP+Release+Planning+Home> for 
D2 ECOMP Project In-take, 2016 Release Planning, Change Management, and find 
key Release Planning Contact Information.


From: mailto:onap-tsc-boun...@lists.onap.org>> 
on behalf of Parviz Yegani 
mailto:parviz.yeg...@huawei.com>>
Date: Thursday, May 17, 2018 at 5:38 AM
To: Alla Goldner mailto:alla.gold...@amdocs.com>>, 
"Vladimir Yanover (vyanover)" mailto:vyano...@cisco.com>>, 
Dhananjay Pavgi 
mailto:dp00476...@techmahindra.com>>, 
"SHANKARANARAYANAN, N K" 
mailto:shan...@research.att.com>>, 
"onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org>" 
mailto:onap-usecase...@lists.onap.org>>
Cc: onap-discuss 
mailto:onap-discuss@lists.onap.org>>, onap-tsc 
mailto:onap-...@lists.onap.org>>
Subject: Re: [onap-tsc] [Onap-usecasesub] The summary of Usecase subcommittee 
meeting 14/05/2017 - Casablanca use cases/functional requirements endorsement

Agree with Alla. The name doesn’t matter. You can call it “Pineapple”.

What we need to do is to review the ONF architecture and other relevant specs 
to see if this module, indeed, implements only a subset of the SDN-C functions. 
 I glanced through some of these documents. The good news is like SDNC (and 
APPC) SDNR is also modeled after ODL. This is evident from the many POCs 
conducted by ONF (see the ONF white papers that have been published since 
2015). The same point is also echoed in the project objectives below. It says: 
“Becau

Re: [onap-discuss] [Onap-usecasesub] [onap-tsc] The summary of Usecase subcommittee meeting 14/05/2017 - Casablanca use cases/functional requirements endorsement

[Parviz Yegani]

Agree with Alla. The name doesn’t matter. You can call it “Pineapple”.

What we need to do is to review the ONF architecture and other relevant specs 
to see if this module, indeed, implements only a subset of the SDN-C functions. 
 I glanced through some of these documents. The good news is like SDNC (and 
APPC) SDNR is also modeled after ODL. This is evident from the many POCs 
conducted by ONF (see the ONF white papers that have been published since 
2015). The same point is also echoed in the project objectives below. It says: 
“Because the controller is based on OpenDaylight, it is consistent with the 
ONAP architecture, and we believe that the majority of the software for the 
applications can be ported into ONAP with only minor modifications.”

Well, the devil is in the details;) We (in ONAP) have to do our due diligence 
to make sure SDNR can leverage SDNC+CCSDK functions to support target use cases 
for both fixed and wireless access scenarios. Some questions may arise. For 
example, how are we going to use the device models developed for RAN equipment 
by BBF (based on TR-069)? This doesn’t exist in ONAP today, AFAIK. We can 
possibly tweak the DG config node in SDNC to adapt to vendor’s SBI 
implementation (proprietary adaptor), similar to what we did for the VoLTE use 
case in R1/Amsterdam. If so, then SDNR would be a better fit for the 3rd party 
controller, sitting below SDNC (as a downstream controller), no?

Said that, we certainly need to figure out how this module fits into the rest 
of the ONAP architecture. Architecture discussion should focus on SDNC (and 
perhaps APPC) functional mapping/alignment with SDNR first. SDNR is designed to 
support multi-vendor equipment (presumably physical devices/PNFs in initial 
deployment phases). If so, then this question crosses one’s mind: Shouldn’t PNF 
PnP support a key requirement for this project?

SDN-R Objectives<https://wiki.onap.org/display/DW/SDN-R+Objectives>
Port the SDN controller developed by the ONF Wireless Transport Project into 
ONAP
This objective is to port the models and controller of the ONF Wireless 
Transport 
project<https://wiki.opennetworking.org/display/OTCC/Wireless+Transport> into 
the ONAP framework.  Beginning in 4Q 2015, the Wireless Transport Project 
within the Open 
Transport<https://www.opennetworking.org/projects/open-transport/>group of the 
Open Networking Foundation (ONF<https://www.opennetworking.org/>) has pursued 
the goals of defining a shared data model for wireless network elements and 
developing a Software Defined Network (SDN) controller to manage a network made 
up of equipment from several manufacturers.  The model is defined in the ONF 
Technical Reference 
TR-532<https://3vf60mmveq1g8vzn48q2o71a-wpengine.netdna-ssl.com/wp-content/uploads/2013/05/TR-532-Microwave-Information-Model-V1.pdf>,
 the SDN controller is based on OpenDaylight<https://www.opendaylight.org/>, 
and the software code for the controller is available at an open source github 
repository<https://github.com/OpenNetworkingFoundation/CENTENNIAL>.  Because 
the controller is based on OpenDaylight, it is consistent with the ONAP 
architecture, and we believe that the majority of the software for the 
applications can be ported into ONAP with only minor modifications.  The 
greatest difference is in the deployment of the controller.  The Wireless 
Transport Project deploys the controller as a standalone virtual machine.  In 
contrast, ONAP deploys the controller as a set of Docker containers within the 
larger ONAP framework.  Our tasks are to learn and apply the ONAP tools and 
practices for deployment.
Draft proposal →  
https://wiki.onap.org/download/attachments/20087400/SDN-R_proposal_v6.docx?api=v2

My 2c,
Rgds,
Parviz
---
PARVIZ YEGANI, PhD
Chief SDN/NFV Architect
CTO Office, Cloud Network Solutions

FutureWei Technologies, Inc.
2330 Central Express Way
Santa Clara, CA 95050, USA
Phone: +1 (408) 330-4668
Mobile : +1 (408) 759-1973
parviz.yeg...@huawei.com<mailto:parviz.yeg...@huawei.com>



From: onap-usecasesub-boun...@lists.onap.org 
[mailto:onap-usecasesub-boun...@lists.onap.org] On Behalf Of Alla Goldner
Sent: Wednesday, May 16, 2018 11:08 PM
To: Vladimir Yanover (vyanover) ; Dhananjay Pavgi 
; SHANKARANARAYANAN, N K (N K) 
; onap-usecase...@lists.onap.org
Cc: onap-discuss@lists.onap.org; onap-tsc 
Subject: Re: [Onap-usecasesub] [onap-tsc] The summary of Usecase subcommittee 
meeting 14/05/2017 - Casablanca use cases/functional requirements endorsement

Vladimir,

if I understood Steve’s comment correctly, it is not about any particular name, 
but more about recognition of yet additional standalone controller, while we 
don’t have it as a part of our architecture.
This is why the proposal is to contain it under SDN-C (as, also according to 
our architecture, this is SDN-C’s sub-module/sub-project), but explain 
explicitly what this module’s functionality is.

Best rega

Re: [onap-discuss] Some thoughts about ONAP Microservice Architecture for Casablanca and beyond: Service Mesh, Centralized Authentication and unified API standards

[Parviz Yegani]

Thanks Huabing. Sure, you can present it next week.

Thank you
Parviz

---
PARVIZ YEGANI, PhD
Chief SDN/NFV Architect
CTO Office, Cloud Network Solutions

FutureWei Technologies, Inc.
2330 Central Express Way
Santa Clara, CA 95050, USA
Phone: +1 (408) 330-4668
Mobile : +1 (408) 759-1973
parviz.yeg...@huawei.com<mailto:parviz.yeg...@huawei.com>



From: zhao.huab...@zte.com.cn [mailto:zhao.huab...@zte.com.cn]
Sent: Tuesday, March 20, 2018 1:30 AM
To: Parviz Yegani 
Cc: Christopher Donley (Chris) ; 
onap-arch-tiger-t...@lists.onap.org; onap-discuss@lists.onap.org; 
manoj.k.n...@netcracker.com; alex@intel.com
Subject: Re:RE: Some thoughts about ONAP Microservice Architecture for 
Casablanca and beyond: Service Mesh, Centralized Authentication and unified API 
standards


Hi Parviz,

Is this scheduled for Monday? Sorry I missed it. Could we move it to the next 
call, is that this Friday?

Thanks,

Huabing
Original Mail
Sender: ParvizYegani mailto:parviz.yeg...@huawei.com>>
To: zhaohuabing10201488;Christopher Donley(Chris) 
mailto:christopher.don...@huawei.com>>
CC: 
onap-arch-tiger-t...@lists.onap.org<mailto:onap-arch-tiger-t...@lists.onap.org> 
mailto:onap-arch-tiger-t...@lists.onap.org>>onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>
 mailto:onap-discuss@lists.onap.org>>Manoj K Nair 
mailto:manoj.k.n...@netcracker.com>>'Vul, Alex' 
mailto:alex@intel.com>>
Date: 2018/03/19 14:59
Subject: RE: Some thoughts about ONAP Microservice Architecture for Casablanca 
and beyond: Service Mesh, Centralized Authentication and unified API standards
Hi Huabing,

Thanks for launching the discussions on ONAP Microservices architecture. Right 
timing! This is a very important topic that we need to consider for the ONAP 
target  architecture (R3+)!

I added the following item to the agenda for today’s tiger team call:

-  ONAP Microservices Architecture for Casablanca and beyond

Please share your slides prior to the call. I hope Manoj, Alex, Manish and 
other folks who have been quite active in driving this work in ONAP can join 
the call as well.
Thank you
Parviz

---
PARVIZ YEGANI, PhD
Chief SDN/NFV Architect
CTO Office, Cloud Network Solutions

FutureWei Technologies, Inc.
2330 Central Express Way
Santa Clara, CA 95050, USA
Phone: +1 (408) 330-4668
Mobile : +1 (408) 759-1973
parviz.yeg...@huawei.com<mailto:parviz.yeg...@huawei.com>



From: zhao.huab...@zte.com.cn<mailto:zhao.huab...@zte.com.cn> 
[mailto:zhao.huab...@zte.com.cn]
Sent: Wednesday, March 14, 2018 4:01 AM
To: Parviz Yegani mailto:parviz.yeg...@huawei.com>>; 
Christopher Donley (Chris) 
mailto:christopher.don...@huawei.com>>
Cc: 
onap-arch-tiger-t...@lists.onap.org<mailto:onap-arch-tiger-t...@lists.onap.org>;
 onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>
Subject: Some thoughts about ONAP Microservice Architecture for Casablanca and 
beyond: Service Mesh, Centralized Authentication and unified API standards


Hi all,

I'd like to share some of my thoughts about ONAP Microservice Architecture for 
Casablanca and beyond



1. Service Mesh

Service Mesh is the next generation of Microservice approach, which can bring 
lots of benefits to ONAP and its users at both the development and operation 
sides. Such as

· the separation of business logic and Microservice 
infrastructure(communication, security, metrics etc)

· allowing free choice of development tech stack

· flexible route rules to enable traffic steering and canary release

· monitoring and tracing visibility

· fault injection for resiliency testing, etc

We should take service mesh into consideration. There are multiple choices on 
the table right now, given its tight relationship with kubernetes which is used 
for ONAP deployment, I suggest we give Istio a shot in Casablanca. MSB project 
is investigating  the possibility of integration of Istio and ONAP right now.



2. Centralized Authentication

ONAP is a huge system consisting of many services. Currently, different 
services such as AAI, SDC, Policy etc. have their own authentication process, 
which makes ONAP difficult to use and adds burden to the individual project to 
enforce the cross-project  authentication logic. We need to consider 
implementing some kind of centralized authentication, which means user login 
once and can access all the services. We also need to consider how to secure 
the access of 3-party systems by using API token or OAuth.



3. Unified API standard

Most of the projects produce RESTFul APIs for consuming, but in a 
none-consistent way. we need to define some unified standards/best practices on 
the REST API definition across the ONAP projects such as versioning, url, error 
code.  There is a draft in the  wiki page: 
https://wiki.onap.org/display/DW/RESTful+API+Design+Specification

BR,

Huabing


___

Re: [onap-discuss] Some thoughts about ONAP Microservice Architecture for Casablanca and beyond: Service Mesh, Centralized Authentication and unified API standards

[Parviz Yegani]

Hi Huabing,

Thanks for launching the discussions on ONAP Microservices architecture. Right 
timing! This is a very important topic that we need to consider for the ONAP 
target architecture (R3+)!

I added the following item to the agenda for today’s tiger team call:

-  ONAP Microservices Architecture for Casablanca and beyond

Please share your slides prior to the call. I hope Manoj, Alex, Manish and 
other folks who have been quite active in driving this work in ONAP can join 
the call as well.
Thank you
Parviz

---
PARVIZ YEGANI, PhD
Chief SDN/NFV Architect
CTO Office, Cloud Network Solutions

FutureWei Technologies, Inc.
2330 Central Express Way
Santa Clara, CA 95050, USA
Phone: +1 (408) 330-4668
Mobile : +1 (408) 759-1973
parviz.yeg...@huawei.com<mailto:parviz.yeg...@huawei.com>



From: zhao.huab...@zte.com.cn [mailto:zhao.huab...@zte.com.cn]
Sent: Wednesday, March 14, 2018 4:01 AM
To: Parviz Yegani ; Christopher Donley (Chris) 

Cc: onap-arch-tiger-t...@lists.onap.org; onap-discuss@lists.onap.org
Subject: Some thoughts about ONAP Microservice Architecture for Casablanca and 
beyond: Service Mesh, Centralized Authentication and unified API standards


Hi all,

I'd like to share some of my thoughts about ONAP Microservice Architecture for 
Casablanca and beyond



1. Service Mesh

Service Mesh is the next generation of Microservice approach, which can bring 
lots of benefits to ONAP and its users at both the development and operation 
sides. Such as

· the separation of business logic and Microservice 
infrastructure(communication, security, metrics etc)

· allowing free choice of development tech stack

· flexible route rules to enable traffic steering and canary release

· monitoring and tracing visibility

· fault injection for resiliency testing, etc

We should take service mesh into consideration. There are multiple choices on 
the table right now, given its tight relationship with kubernetes which is used 
for ONAP deployment, I suggest we give Istio a shot in Casablanca. MSB project 
is investigating the possibility of integration of Istio and ONAP right now.



2. Centralized Authentication

ONAP is a huge system consisting of many services. Currently, different 
services such as AAI, SDC, Policy etc. have their own authentication process, 
which makes ONAP difficult to use and adds burden to the individual project to 
enforce the cross-project authentication logic. We need to consider 
implementing some kind of centralized authentication, which means user login 
once and can access all the services. We also need to consider how to secure 
the access of 3-party systems by using API token or OAuth.



3. Unified API standard

Most of the projects produce RESTFul APIs for consuming, but in a 
none-consistent way. we need to define some unified standards/best practices on 
the REST API definition across the ONAP projects such as versioning, url, error 
code.  There is a draft in the wiki page: 
https://wiki.onap.org/display/DW/RESTful+API+Design+Specification

BR,

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

Re: [onap-discuss] [modeling]Modeling call next week

[Parviz Yegani]

Hi Deng Hui,

Wed 6:00AM PST clashes with the SDNC weekly call. We should avoid this overlap 
for next week's vF2F if possible.

Thank you
Parviz

---
PARVIZ YEGANI, PhD
Chief SDN/NFV Architect
CTO Office, Cloud Network Solutions

FutureWei Technologies, Inc.
2330 Central Express Way
Santa Clara, CA 95050, USA
Phone: +1 (408) 330-4668
Mobile : +1 (408) 759-1973
parviz.yeg...@huawei.com<mailto:parviz.yeg...@huawei.com>



From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of denghui (L)
Sent: Friday, February 02, 2018 4:46 AM
To: onap-discuss@lists.onap.org; onap-...@lists.onap.org P 

Cc: Rittwik Jana 
Subject: [onap-tsc] [modeling]Modeling call next week

Hello all

Our modeling subcommittee call will be cancelled next week due to vf2f,

Hi Kenny,

could you kindly help to cancel next week call, thanks a lot

and we will have our modeling subcommittee session on Wednesday 9am eastern 
time, 10pm Beijing time.

1)  Resource IM Xu Yang

2)  Service IM Maopeng Zhang

3)  Data modeling Anatoly

4)  Centralized Parser Atul

5)  Modeling tools Nigel

6) Projects follow up modeling spec discussion (Modeling contact from each 
Project)
Let me know if you have any other suggestions.

Thanks a lot

DENG Hui

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

Re: [onap-discuss] A Big Thanks to all your efforts !!! ONAP SO is sucessfully delivered for Amsterdam

[Parviz Yegani]

Seshu, SO team,

Wonderful news. Congratulations!

---
PARVIZ YEGANI, PhD
Chief SDN/NFV Architect
CTO Office, Cloud Network Solutions

FutureWei Technologies, Inc.
2330 Central Express Way
Santa Clara, CA 95050, USA
Phone: +1 (408) 330-4668
Mobile : +1 (408) 759-1973
parviz.yeg...@huawei.com<mailto:parviz.yeg...@huawei.com>



From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Seshu m
Sent: Friday, November 17, 2017 5:26 AM
To: DAUGHERTY, ROBERT E ; FAZAL, ABBAS 
; cl6...@att.com; Byung-Woo Jun 
; Chenchuanyu ; DeWayne 
Filppi ; Ethan Lynn ; Jinxin 
(Saw) ; sylvain.desbure...@orange.com; alex@intel.com; 
denghui (L) ; Zhoujun (ONAP) ; 
jh7...@att.com; BULLARD, GIL ; MARTELLA, ARTHUR W (ARTHUR) 
; BORALE, SHAILENDRA S ; 
lxin...@vmware.com; frank.obr...@amdocs.com; Kevin McDonnell 
; huang.zhuo...@zte.com.cn; Kang Xi 
; Yang Xu (Yang, Fixed Network) ; 
FREEMAN, BRIAN D ; onap-discuss@lists.onap.org
Subject: Re: [onap-discuss] A Big Thanks to all your efforts !!! ONAP SO is 
sucessfully delivered for Amsterdam

Dear All,

Thanks to all your efforts, ONAP SO is sucessfully delivered for Amsterdam.
It was definitely not a cake-walk but a roller-coaster ride that we had to pass 
through.
But, the results are here and this is a stepping stone for us to move on to 
Beijing.
Lets togther achieve more such successful milestones and make ONAP a global 
success.

Best Regards,
Seshu
**
 This email 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 here 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 
email 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

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

[Parviz Yegani]

Yes, I am getting the same error.

Thanks,
Parviz

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of ???/Lingli Deng
Sent: Monday, November 13, 2017 4:14 PM
To: Kenny Paul; onap-discuss; onap-tsc
Cc: Lisa Caywood
Subject: [onap-tsc] 答复: Official ONAP Architecture Slide

Hi Kenny

I am a raid that the link returns a error as Page not found.

Lingli

发送自 Windows 10 版邮件应用

发件人: Kenny Paul
发送时间: 2017年11月14日 8:04
收件人: onap-discuss; 
onap-tsc
抄送: Lisa Caywood
主题: [onap-tsc] Official ONAP Architecture Slide

As was pointed out in Paris there are too many variations of the Amsterdam 
architecture which is bad to say the least.
The officially approved image for the Amsterdam Architecture and be found here:
https://wiki.onap.org/download/attachments/1015842/ONAP%20Amsterdam%20arch.png?api=v2



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

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

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

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

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

Thanks!



Best Regards,
-kenny

Kenny Paul,  Technical Program Manager
kp...@linuxfoundation.org
510.766.5945


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

Re: [onap-discuss] [Modeling]The result of PTL election of modeling project

[Parviz Yegani]

Congrats Deng Hui!

Parviz

From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of denghui (L)
Sent: Tuesday, June 27, 2017 5:11 AM
To: onap-discuss@lists.onap.org; onap-...@lists.onap.org
Subject: [onap-discuss] [Modeling]The result of PTL election of modeling project

Hello all

I would like to share the result of PTL election of modeling project, Deng Hui 
is only one candidate and got 17 “+1”
So Deng Hui win this election, thanks a lot for your support

Best regards,

DENG Hui


From: denghui (L) [mailto:denghu...@huawei.com]
Sent: 2017年6月25日 22:42
To: JANA, RITTWIK (RITTWIK) 
mailto:rj...@research.att.com>>; 
alex@intel.com; 
a...@gigaspaces.com; 
andr...@amdocs.com; 
art...@gigaspaces.com; 
bru...@cisco.com; 
wangchen...@chinamobile.com; 
ethanly...@vmware.com; 
don...@raisecom.com; 
ll...@chinatelecom.cn; 
denglin...@chinamobile.com; 
zhonghe...@boco.com.cn; 
zhang.maope...@zte.com.cn; 
ss00473...@techmahindra.com; Lishitao 
mailto:lishi...@huawei.com>>; 
thinh.nguyen...@nokia.com; 
lxin...@vmware.com; 
shiyb...@chinatelecom.cn; 
hanya...@raisecom.com; 
yangyuan...@boco.com.cn; 
meng.zhaoxi...@zte.com.cn
Cc: Kenny Paul mailto:kp...@linuxfoundation.org>>; 
Casey Cain mailto:cc...@linuxfoundation.org>>; Phil 
Robb mailto:pr...@linuxfoundation.org>>
Subject: ONAP Modeling project PTL election

Hello all

In order to NOT generating so much traffic in TSC list, I am sending this email 
to committers and LF only, will close the vote at 8am EDT, June 27th, Tuesday,
will disclose the election result to the TSC list once we finished.

Upon closing our self-nomination period, we have only one candidate: Hui Deng
Committers, if you support Hui Deng for PTL, please send “+1”, if you don’t, 
please send “-1”, if you are neutral, please send “0”

Thanks a lot for your kind help
Best regards,

DENG Hui

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

Re: [onap-discuss] Integration project PTL Election Result

[Parviz Yegani]

Congrats Helen!

Thank you
Parviz

---
PARVIZ YEGANI, PhD
Chief SDN/NFV Architect
CTO Office, Cloud Network Solutions

FutureWei Technologies, Inc.
2330 Central Express Way
Santa Clara, CA 95050, USA
Phone: +1 (408) 330-4668
Mobile : +1 (408) 759-1973
parviz.yeg...@huawei.com<mailto:parviz.yeg...@huawei.com>



From: onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Yunxia Chen
Sent: Monday, June 26, 2017 4:31 PM
To: onap-discuss@lists.onap.org
Subject: [onap-discuss] Integration project PTL Election Result

Dear all,

I’d like to share with you the result of PTL election for Integration project: 
the winner is Helen Chen.

Election close time @ 6/23/2017, 11:59 PM PDT: [onap-discuss] Integration 
project PTL Election 
<https://lists.onap.org/pipermail/onap-discuss/2017-June/001792.html>
Self-nomination end @ 6/20/2017, 11:59 PM PDT: [onap-discuss] Integration 
project PTL nomination solicitation 
<https://lists.onap.org/pipermail/onap-discuss/2017-June/001694.html>

Thank you for your support! I am looking forward to working with you all!

Regards,
Helen Chen

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