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

[Andrei Kojukhov]

Hello Deng Hui, Andy,

As the topics 1 -  6 are more or less covered (or in the process of finalizing) 
by the ETSI GS NFV-SOL001 so it would not be a big deal to re-use the TOSCA 
constructs from there.

However the topic # 7 is not covered (and not planned to be covered) by SOL001 
so to my understanding we really have an issue. I'm aware of existence of TOSCA 
based monitoring definitions done by AT&T team and I was requested to 
contribute it in ETSI SOL but this contribution may take time.

BR

Andrei

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of denghui (L)
Sent: Thursday, March 08, 2018 2:46 PM
To: onap-disc...@lists.onap.org; onap-tsc 
Cc: Rittwik Jana 
Subject: [onap-tsc] [modeling] ONAP R2 IM to DM design

Hello all

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

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

The tasks including:
1. VDU: https://jira.onap.org/browse/MODELING-67
2. HPA: https://jira.onap.org/browse/MODELING-68
3. CP: https://jira.onap.org/browse/MODELING-69
4. DeploymentFlavor: https://jira.onap.org/browse/MODELING-70
5. VL: https://jira.onap.org/browse/MODELING-71
6. VNFD: https://jira.onap.org/browse/MODELING-72
7. monitor: https://jira.onap.org/browse/MODELING-73

It's expected that the lead would help provide tosca definitions on the 
contribution page 
(https://wiki.onap.org/display/DW/Data+Model+align+with+TOSCA+NFV+Profile) and
help implement related logic in SDC, APPC/VFC projects.

Thanks a lot

DENG Hui
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

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

Re: [onap-tsc] [onap-discuss] [Modeling] Modeling subcommittee F2F Cont. on Wednesday

[Andrei Kojukhov]

Dear Deng Hui,

I would also keep the meeting as it was originally planned later today so the 
VNF-SDK Modeling team will be involved.

BR

Andrei

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Vul, Alex
Sent: Wednesday, September 27, 2017 9:58 AM
To: denghui (L) ; onap-disc...@lists.onap.org; onap-tsc 

Subject: Re: [onap-tsc] [onap-discuss] [Modeling] Modeling subcommittee F2F 
Cont. on Wednesday

Deng Hui,

The R2 VNF modeling work is being led by Andy as part of the VNF SDK project 
being driven by Chris. I think it would be good for the folks who doing the 
model definition to actually hear the inputs... :) Otherwise, I don't see the 
point...

Kind regards,

Alex

From: denghui (L) [mailto:denghu...@huawei.com]
Sent: Wednesday, September 27, 2017 12:50 AM
To: Vul, Alex mailto:alex@intel.com>>; 
onap-disc...@lists.onap.org; onap-tsc 
mailto:onap-tsc@lists.onap.org>>
Subject: RE: [onap-discuss] [Modeling] Modeling subcommittee F2F Cont. on 
Wednesday

Alex,

we have already heard yesterday feedback from Chris Donley Andy, VNFSDK & 
Architecture, ,
and now we need to move on and would expect more from the implementers side.

Thanks

DENG Hui

From: Vul, Alex [mailto:alex@intel.com]
Sent: Wednesday, September 27, 2017 9:45 AM
To: denghui (L) mailto:denghu...@huawei.com>>; 
onap-disc...@lists.onap.org; onap-tsc 
mailto:onap-tsc@lists.onap.org>>
Subject: RE: [onap-discuss] [Modeling] Modeling subcommittee F2F Cont. on 
Wednesday

Hi,

I don't see how we the critical mass to do this. If you want the feedback to be 
heard, you need to include the people who are working on the VNF models, 
including those who are leading the work - Chris, Andy, others. Chris is on 
stage presenting. Andy is asleep...

My two cents,

Alex

From: 
onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of denghui (L)
Sent: Wednesday, September 27, 2017 12:32 AM
To: onap-disc...@lists.onap.org; onap-tsc 
mailto:onap-tsc@lists.onap.org>>
Subject: [onap-discuss] [Modeling] Modeling subcommittee F2F Cont. on Wednesday

Hello all

We haven't finished yesterday session, let's continue 10:30-11:30 this morning 
in the meeting room (Algebre), 2nd floor.
Agenda would be :

1)   SDC feedback to VNF modeling

2)   VFC feedback to VNF modeling

3)   Summary of VNF Modeling

4)   OSM modeling comparison

Apologies to US remote attendees, we couldn't conflict with TSC meeting in the 
afternoon.

Thanks a lot for your attending
Best regards,

DENG Hui
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

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

Re: [onap-tsc] Architecture Progress

[Andrei Kojukhov]

Hi Chris,

My concern is that a resource orchestrator is not an agreed entity in ETSI NFV 
architecture and its functionality is not agreed. To my understanding the ETSI 
NFV study item that should develop its functionality is currently stopped.

BR

Andrei

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Christopher Donley (Chris)
Sent: Thursday, July 20, 2017 11:05 PM
To: onap-tsc@lists.onap.org; onap-disc...@lists.onap.org
Cc: onap-...@lists.onap.org
Subject: [onap-tsc] Architecture Progress

Dear ONAP Technical Community,

I'd like to update you on progress from the Architecture Committee.

* For Amsterdam, we agreed to use the current architecture, as 
discussed since ONS.  This is to reduce risk of late changes to the project 
teams, who have built their plans based on the current baseline.

* Longer-term, starting with Release 2, we reached consensus on an 
approach to resolve the APP-C/VF-C challenge.  We are developing a three-layer 
orchestrator/controller functional architecture, with service 
orchestration/resource orchestration/controllers.  Note that this functional 
architecture does not imply a project structure.  Between now and the beginning 
of the R2 planning cycle, the team will drill down to the next level of detail 
on interfaces and project alignment, and then the projects will map code into 
the architecture to guide R2 plans. Cross-project discussions have already 
begun, and will continue over the coming weeks.  Meeting logistics will be sent 
to the ONAP-discuss email list for those who are interested in participating.

I have attached a set of diagrams that we reviewed in the Architecture 
Committee to illustrate both the R1 and R2 architecture.  Note that in the R2 
slide, since we are focused on the functional architecture and not the 
projects, we removed some of the boxes listing projects that support ONAP, but 
don't provide interfaces or data flows through the system.

For those interested in more detail, we will discuss this during the developer 
meeting next week.

Chris

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

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

[onap-tsc] ETSI Webinar on VNF package standard

[Andrei Kojukhov]

Dear ONAP community,

FYI: Tomorrow there will be an ETSI Webinar - NFV Tutorial on VNF packaging 
specification (ETSI NFV SOL004). This topic is by my opinion relevant for a 
number of ONAP projects:
VNF-SDK, VNF validation, VNF requirements, SDC, Modeling and probably some 
others. The link for registration/participation: 
http://www.etsi.org/news-events/webinars - see the first in the list.

BR

Andrei
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

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

Re: [onap-tsc] [onap-discuss] Tentative July ONAP Developers Face-to-Face Meeting

[Andrei Kojukhov]

Hi Gildas,

Tks for considering the “Matrix” we sent. My clarifications regarding your 
comments:


1.   The goal of the matrix we built was not to highlight the 
consumer/provider relationship. Based on what currently specified in each 
project description we wanted to find the inconsistencies in how the project 
creator sees the interactions with other projects (row per project) versus what 
other projects thing about their interaction with this specific project (column 
per project). The green boxes indicate an existence of the record of such 
interaction as described in all the approved projects.

2.   The idea behind the blue boxes was to indicate an existence of logical 
interaction but not necessarily requiring developing of an API. For instance 
VNF Requirement or Modeling have logical relation with other projects but do 
not require developing API’s in between.

3.   The red box intent is to indicate the inconsistency I mentioned in 
(1). To our understanding this analysis is the primary goal of the matrix.

4.   Thanks for spotting the fact that the two proposed projects (Network 
Function change management and External System Register) have not approved yet.

BR

Andrei

From: Gildas Lanilis [mailto:gildas.lani...@huawei.com]
Sent: Tuesday, June 20, 2017 3:11 AM
To: Andrei Kojukhov 
Cc: onap-disc...@lists.onap.org; onap-tsc ; Alla 
Goldner ; Phil Robb ; Arul 
Nambi 
Subject: RE: [onap-discuss] [onap-tsc] Tentative July ONAP Developers 
Face-to-Face Meeting

Thanks Andrei for putting the deck together. It helps to move forward.
It was my intention to build a similar table based on the dependencies 
input<https://wiki.onap.org/display/DW/Release+Planning+Template#ReleasePlanningTemplate-ONAPDependencies>
 for each and every project.
I posted your table as a reference on wiki at 
https://wiki.onap.org/display/DW/Release+Planning#ReleasePlanning-ReleaseDependencies
 and started to build directly into the wiki the same table (so far with only 
approved projects). That should help into avoiding the question “what is the 
latest version?”.

A couple of questions:


1)  I was wondering how to read the dependency table. In other words who is 
the API provider and who is the API consumer? In the Release Planning 
Template<https://wiki.onap.org/display/DW/Release+Planning+Template#ReleasePlanningTemplate-APIIncomingDependencies>,
 I called it “API Incoming Dependencies” (provider) and “API Outgoing 
Dependencies” (consumer). Your clarification would help (my guess is that the 
projects in the column have dependencies on the projects in the row). Thanks to 
confirm.

2)  Would you mind clarifying the blue boxes “Interact but no direct 
interface”? To some extend everything interact through a different level of 
connection in ONAP.

3)  For the red boxes “Likely but not mentioned”. Would you mind explaining 
where it is not mentioned?  May be we should wait until all projects have 
created their release plan.

4)  Not sure what are the “Change Man”, “Ext Sys Reg” projects. To my 
knowledge, none have not been approved so far, and I do not see them in the 
list of “proposed project<https://wiki.onap.org/display/DW/Proposed+Projects>”. 
May be it is just a wording issue. It would help if you could provide a link.

Thanks,
Gildas
ONAP Release Manager
1 415 238 6287

From: 
onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> 
[mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Andrei Kojukhov
Sent: Monday, June 19, 2017 6:17 AM
To: Alla Goldner; Phil Robb; Arul Nambi
Cc: onap-disc...@lists.onap.org<mailto:onap-disc...@lists.onap.org>; onap-tsc
Subject: Re: [onap-discuss] [onap-tsc] Tentative July ONAP Developers 
Face-to-Face Meeting

Alla, Phil,

Please take an updated slide (attached) – I sent you an email twice by mistake.

BR

Andrei

From: onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org> 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Alla Goldner
Sent: Monday, June 19, 2017 4:06 PM
To: Phil Robb mailto:pr...@linuxfoundation.org>>; 
Arul Nambi mailto:arul.na...@amdocs.com>>
Cc: Elhay Efrat mailto:elhay.efr...@amdocs.com>>; 
onap-disc...@lists.onap.org<mailto:onap-disc...@lists.onap.org>; onap-tsc 
mailto:onap-tsc@lists.onap.org>>
Subject: Re: [onap-tsc] [onap-discuss] Tentative July ONAP Developers 
Face-to-Face Meeting

Hi Phil, all,

Given the huge number of approved projects and their complexity, from one side, 
and lack of well-defined interactions and interfaces between those 
projects/modules representing the projects, from the other side, I would say we 
may need a meeting to define those, to synchronize on those, to see if all 
needed interfaces are indeed defined etc.

We’ve been trying to access the complexity internally and came up with the list 
of all potential interactions which will have to be developed, attached. The 
list may not 

[onap-tsc] FW: project proposal: VNF SDK

[Andrei Kojukhov]

Hi Chris,

Where and when the discussion about the content and the leadership of VNF 
Validation Program (TBD) projects, which will handle vnf guidelines and 
compliance/validation, respectively will be held?

BR

Andrei

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Christopher Donley (Chris)
Sent: Saturday, May 27, 2017 3:27 AM
To: onap-tsc@lists.onap.org
Subject: [onap-tsc] project proposal: VNF SDK

Dear ONAP TSC,

The VNF SDK team would like to formally propose the VNF SDK project: 
https://wiki.onap.org/display/DW/VNF+SDK.

Note that we have adjusted the scope of this project and split the original 
proposal into three parts.  VNF SDK (this project) is focused on developing 
tools for VNF packaging and validation.  It will work closely with two 
independent projects: VNF Requirements project 
(https://wiki.onap.org/display/DW/VNF+Requirements) and VNF Validation Program 
(TBD) projects, which will handle vnf guidelines and compliance/validation, 
respectively.

Thanks,
Chris
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

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

Re: [onap-tsc] ONAP Architecture subcommittee kickoff

[Andrei Kojukhov]

Hi Lingli,

Where can I find the info about the modelling weekly calls?

Tks,

Andrei

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Lingli Deng
Sent: Saturday, May 27, 2017 2:55 AM
To: 'Christopher Donley (Chris)' ; 
onap-tsc@lists.onap.org; onap-disc...@lists.onap.org
Subject: Re: [onap-tsc] ONAP Architecture subcommittee kickoff

Hi Chris,

Thanks for the arrangements.

I am interested to join but found a conflict with modeling weekly calls.
Will the suggested time slot be used for subsequent routine calls or is it only 
a one-time suggestion?
Since I expect several people including myself to be regularly attending both 
meeting series, would you consider the possibility that we might reschedule it 
to another slot?

Thanks again,
Lingli

From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Christopher Donley (Chris)
Sent: 2017年5月27日 7:44
To: onap-tsc@lists.onap.org; 
onap-disc...@lists.onap.org
Subject: [onap-tsc] ONAP Architecture subcommittee kickoff

Dear ONAP community,

This is a call-for-participation message for our newly created architecture 
subcommittee.

We will have a kickoff meeting next Tuesday, May 30 at 1500 UTC.  Preliminary 
agenda includes:

  *   Introductions
  *   Discuss subcommittee goals, roles, purpose, processes/tools/communication 
mechanisms, and formation next steps
  *   Recurring meeting dates/times
  *   Discuss the starting point and open issues 
(https://wiki.onap.org/download/attachments/3245203/ONAP%20Architecture%20Evolution%2005022017_v7.pptx?version=1&modificationDate=1493761356000&api=v2)
  *   As time permits, continue the SO-APP-C-VF-C discussion


For those interested in joining, here are the logistics:
Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/525972941

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

Or Telephone:
Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll)
Meeting ID: 525 972 941
International numbers available: 
https://zoom.us/zoomconference?m=TTavi4JgYzPQg9seHf6L8GWCn-g6ehUy

Chris
This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

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

Re: [onap-tsc] [onap-discuss] Proposal for structuring Modeling projects

[Andrei Kojukhov]

Hi Zahi,

Tks, 

Yes, It looks like we are aligned about that all design related initiatives as 
part of other projects (Policy, CLAMP, merged ICE-VNF SDK) should be handled 
under the SDC umbrella - Option 1 in my proposal.
I believe that is the proposal that we need to socialize in ONAP.

BR

Andrei

-Original Message-
From: Kapeluto, Zahi [mailto:zk0...@intl.att.com] 
Sent: Sunday, May 14, 2017 3:16 PM
To: Dhananjay Pavgi ; Andrei Kojukhov 
; onap-discuss ; 
onap-tsc@lists.onap.org
Subject: Re: [onap-discuss] Proposal for structuring Modeling projects

Hi Andrei,

AT&T already has plans to embed the policy framework and the design-related 
CLAMP activities under the SDC umbrella, so I think we’re aligned on the vision.

Zahi Kapeluto
Lead Architect, Network Communications LOB AT&T Network Applications 
Development · SD&E Tel Aviv | Tampa | Atlanta | New Jersey | Chicago 
·
Mobile: +972 (54) 6636831
Office: +972 (3) 9280064

From:  on behalf of Dhananjay Pavgi 

Date: Sunday, 14 May 2017 at 9:24
To: Andrei Kojukhov , onap-discuss 
, "onap-tsc@lists.onap.org" 

Subject: Re: [onap-discuss] Proposal for structuring Modeling projects

Hi Andrei,

Valid point. There’s certainly an overlap in multiple ONAP projects that deal 
with modelling. Option 1 sounds more logical. Would have all aspects of Design 
Time environment covered under one umbrella than having yet another umbrella 
project (as depicted in Option 2 and 3).

thanks & regards,
Dhananjay Pavgi
Mobile : +91 98220 22264
[id:image002.png@01CE7323.F2727500]   [NAP_logo_Sig]
www.techmahindra.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.techmahindra.com_&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=Tb4B9h_-wR6nA2dMKyowUg&m=HMJsNMwlmAxrjKiNZXrFSOE5Drprem6D42xHa42MB2I&s=caz6QTiwXN_Li1UXXY8IK9dw4Mr76f7-i2ocPbE3tTU&e=>
 Platinum Member. Visit : 
http://www.onap.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.onap.org_&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=Tb4B9h_-wR6nA2dMKyowUg&m=HMJsNMwlmAxrjKiNZXrFSOE5Drprem6D42xHa42MB2I&s=mRRpgdP08SjSBIA9krT_L9oR4IqfOszTZkottejz2F0&e=>

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Andrei Kojukhov
Sent: Thursday, May 11, 2017 12:46 AM
To: onap-discuss ; onap-tsc@lists.onap.org
Subject: [onap-tsc] Proposal for structuring Modeling projects

Dear all,

Currently there are 6 draft projects in ONAP that deal with modeling, 
onboarding and certification. The below table summarizes the 6 initiatives and 
presents the feature coverage of each one of them.


ONAP Project

Features covered by the project

VNF/Service Design

VNF Guidelines

VNF Certification

VNFD/VNF package onboard

Modeling – overall modeling issues

V







Incubation and Certification Entity (ICE)



V

V

V

Service Design and Create (SDC)

v

V

V

V

VNF-SDK

V

V

V

CLAMP

V







Policy Framework

V









Besides an overlap in content and resources allocation of contributors, my 
expectation is that there will be issues with synchronization of requirements 
such as VNF guidelines and requirements derived from Use cases as well as 
maintaining open source.
Therefore, I’m proposing to consider structuring the above described ONAP 
projects. One of possible umbrella projects may be SDC covering most if not all 
the design and onboarding related features.

The Service Design and Create can be seen as one candidate as unified platform 
for

· Validation and verification of VNF guidelines,

· VNF/Service Design studio

· Standard VNFD/VNF package onboarding platform based on ETSI NFV 
SOL001, SOL004 specifications leveraging TOSCA YAML modeling and CSAR packaging

· Multilayered VNF Certification including VNF package integrity and 
authenticity validation, VNF deployment and running VNF tests verifying 
non-functional VNF KPI’s that are currently specified in ETSI NFV EVE011 work,
There may be different options of structuring all or part of the ONAP 
initiatives as shown in the following pictures.

Option 1: SDC umbrella
[cid:image003.png@01D2CCC4.F2B6FAA0]


Option 2: “Design Automation” umbrella including on-boarding and certification 
[cid:image004.png@01D2CCC4.F2B6FAA0]


Option 3: “Design Automation” umbrella excluding on-boarding and certification 
[cid:image005.png@01D2CCC4.F2B6FAA0]


I would like to invite ONAP community members to provide their view on possible 
structuring.


BR,

Andrei



Andrei Kojukhov, PhD

Open Network Division
Amdocs Technology


[cid:image006.png@01D2CCC4.F2B6FAA0]




This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement, you may review at 
https://www.amdocs.com/about/email-disclaimer<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.amdocs.

Re: [onap-tsc] [onap-discuss] [modeling] TOSCA BPMN support proposalat OASIS TOSCA WG

[Andrei Kojukhov]

Second to Michael, the way it is proposed by Huabing, it is like you have an 
ocean of BPMN with small optional islands of TOSCA.

BR

Andrei

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Michael Brenner
Sent: Friday, May 12, 2017 1:46 PM
To: Huabing Zhao 
Cc: onap-discuss ; onap-tsc@lists.onap.org
Subject: Re: [onap-tsc] [onap-discuss] [modeling] TOSCA BPMN support proposalat 
OASIS TOSCA WG

Huabing,

The way you propose it ... you might as well ask the question "why use TOSCA at 
all"? This was one of my points in our discussion last Friday.
I cannot understand why one tries to cannibalize a good standard that was 
purposefully defined for cloud workloads intent-driven deployment and 
orchestration. TOSCA should be used as it was intended, and take advantage of 
its characteristics, instead of twisted around to fit some existing 
implementation.

Best regards,
Michael


On Fri, May 12, 2017 at 3:39 AM, 
mailto:zhao.huab...@zte.com.cn>> wrote:

Hi Ranny,

Thanks for your comments.



It's an interesting use case, in my opinion, why not put all these activities 
into a BPMN workflow, including the creation of VNF, the IP config of the peer 
physical MME and the port config of the security group, the parameters exchange 
is supported between different BPMN task nodes.



OPEN-O has a workflow design tool which can design Lifecycle Management 
workflows for a Network Service. The designer can design a BPMN task to call 
the operation of a tosca node, and an external service as well, including 
Catalog, Inventory(A&AI), NFV-O, VNFM, etc.  So the parameters needed for a 
specific orchestration activity can get from either the BPMN task parameter or 
a service call to an external service.



For this use case, if we put it in the context of OPEN-O, the creation request 
of VNF is passed to NFV-O by a BPMN task node, which creates VNF and returns 
the IP as an output parameter. The output parameter can be used as an input 
parameter of the next BPMN task node, which uses this parameter to config the 
physical MME, in turn, the output of this task can be passed to the next task 
to config the security group. The actual workflow may have more tasks, 
including the interactions with Catalog(get VNF Package) and Inventory(Update 
the service instance), etc.



Furthermore, normally there're multiple nodes in a network service template, 
OPEN-O use parser to get all the nodes from service template and sort the nodes 
based on their topology dependency and then pass the nodes list to a BPMN loop. 
By this approach, we can see that BPMN is not an opposite of topology driven( 
aka declarative workflow), on the contrary, BPMN can complement and enhance 
declarative approach to include external service as well when needed.



Thanks,

Huabing


Original Mail
Sender:  ＜ranny.ha...@nokia.com＞;
To:  ＜na...@gigaspaces.com＞; 
＜mich...@gigaspaces.com＞;zhaohuabing10201488;
CC:  ＜onap-disc...@lists.onap.org＞; 
＜onap-tsc@lists.onap.org＞;
Date: 2017/05/12 01:52
Subject: RE: [onap-discuss] [onap-tsc] [modeling] TOSCA BPMN support proposalat 
OASIS TOSCA WG


Huabing,

I like your direction of giving concrete examples for possible implementation 
that you did in some other branch of this thread. Following that, could you 
please illustrate how the following scenario will be addressed with a BPMN 
workflow:

Let say I am deploying an EPC P-GW, and in that process I need to configure 
DIAMETER-peers on a physical MME so it can communicate with my newly created 
GW. So, after creating some server nodes, TOSCA will need to call an external 
BPMN  workflow and pass as a parameter the IP address of one of the newly 
created server nodes. Also, after the workflow is completed, a port number is 
allocated for the DIAMETER session and it needs to be configured on a security 
group, so it needs to be passed  back to TOSCA as a parameter. Could you 
elaborate on how this back and forth switch of control and information exchange 
could happen?

Thanks,

Ranny.

From: 
onap-discuss-boun...@lists.onap.org 
[mailto:onap-discuss-boun...@lists.onap.org]
 On Behalf Of Nati Shalom
Sent: Thursday, May 11, 2017 6:41 AM
To: Michael Brenner ＜mich...@gigaspaces.com＞; 
Huabing Zhao ＜zhao.huab...@zte.com.cn＞
Cc: onap-discuss 
＜onap-disc...@lists.onap.org＞; 
onap-tsc@lists.onap.org
Subject: Re: [onap-discuss] [onap-tsc] [modeling] TOSCA BPMN support proposal 
at OASIS TOSCA WG

"The proposal has been discussed in the OASIS TOSCA for a couple of weeks and 
most of the members agreed on it except the strong pushback from Michael of 
Gigaspaces.

[onap-tsc] Proposal for structuring Modeling projects

[Andrei Kojukhov]

Dear all,

Currently there are 6 draft projects in ONAP that deal with modeling, 
onboarding and certification. The below table summarizes the 6 initiatives and 
presents the feature coverage of each one of them.


ONAP Project

Features covered by the project

VNF/Service Design

VNF Guidelines

VNF Certification

VNFD/VNF package onboard

Modeling - overall modeling issues

V







Incubation and Certification Entity (ICE)



V

V

V

Service Design and Create (SDC)

v

V

V

V

VNF-SDK

V

V

V

CLAMP

V







Policy Framework

V









Besides an overlap in content and resources allocation of contributors, my 
expectation is that there will be issues with synchronization of requirements 
such as VNF guidelines and requirements derived from Use cases as well as 
maintaining open source.
Therefore, I'm proposing to consider structuring the above described ONAP 
projects. One of possible umbrella projects may be SDC covering most if not all 
the design and onboarding related features.

The Service Design and Create can be seen as one candidate as unified platform 
for

* Validation and verification of VNF guidelines,

* VNF/Service Design studio

* Standard VNFD/VNF package onboarding platform based on ETSI NFV 
SOL001, SOL004 specifications leveraging TOSCA YAML modeling and CSAR packaging

* Multilayered VNF Certification including VNF package integrity and 
authenticity validation, VNF deployment and running VNF tests verifying 
non-functional VNF KPI's that are currently specified in ETSI NFV EVE011 work,
There may be different options of structuring all or part of the ONAP 
initiatives as shown in the following pictures.

Option 1: SDC umbrella
[cid:image007.png@01D2C9B5.447E30F0]


Option 2: "Design Automation" umbrella including on-boarding and certification
[cid:image008.png@01D2C9B5.447E30F0]


Option 3: "Design Automation" umbrella excluding on-boarding and certification
[cid:image009.png@01D2C9B5.447E30F0]


I would like to invite ONAP community members to provide their view on possible 
structuring.


BR,

Andrei



Andrei Kojukhov, PhD

Open Network Division
Amdocs Technology


[cid:image010.png@01D2C9B5.447E30F0]




This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 
<https://www.amdocs.com/about/email-disclaimer>
___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc