[onap-discuss] [onap-tsc] Modelling discussion on Friday May 5th

[aayush.bhatna...@ril.com]

Dear Michael, Ling Li

I have a suggestion here to move forward -

We should indeed have a broader workflow discussion, and consider the end to 
end aspects (which would be ?realized? by ECOMP and Open-O merged at ONAP).

All workflows should have a reference to the TOSCA declarative model-driven 
orchestration, so that we arrive at ?ECOMP Templates? for each of the workflows.

Some of the workflows that we can take up are listed below as a suggestion 
(largely aligned to the ETSI MANO requirements):

1. Lifecycle Management workflows for VNFs (Onboarding, Packaging, 
Instantiation, Auto scaling and Termination)

2. Lifecycle Management workflows for Network Services (NS) on the same lines

3. Workflows for service creation through VNF FGs.

4. Onboarding of NFVI resources fulfilment (underlying hardware and 
virtualization to add resources to the pool) leading to resource discovery 
processes from a NFVO perspective (ECOMP AAI may play a role here).

5. Workflows for fault management and VNF shifting/migration

6. Other aspects ?

I believe our joint objective should be to define the scope of these workflows 
and arrive at an agreeable set of flows which can be implemented / realized 
using ECOMP.

BPMN based workflow implementations can also co-exist with the TOSCA 
model-driven graphs. However, we may discuss in more detail on how to move 
forward in this aspect.

There would always still remain specific workflows for users of the ECOMP 
platform, which can be then be designed using the ECOMP design time framework 
and perhaps the ?learnings? can be contributed back to the community

This can help us formally develop as a workflow design library for ECOMP, 
enabling VNF providers to quickly adopt the platform by using its templates and 
also contributing the learnings back to make it better.

If all agree in principle, we can discuss and move forward.

Regards

Aayush Bhatnagar
Reliance Jio

From: onap-tsc-bounces at lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Michael Brenner
Sent: 26 April 2017 22:00
To: Lingli Deng
Cc: onap-discuss; JANA, RITTWIK (RITTWIK); onap-tsc at lists.onap.org
Subject: Re: [onap-tsc] [onap-discuss] Modelling discussion on Friday May 5th

Lingli, all:

I though we are now discussing ONAP and how to improve it, and not Open-O?

Furthermore, ONAP is indeed using BPEL/BPMN workflows, but that is as part of 
the MSO. MSO may decide to delegate certain portion of the orchestration to a 
TOSCA-based orchestration engine, and what is delegated to such engine may have 
to use its own internal/native workflows.
The real question here is: are we trying to leverage the best of all we have 
available, or are we trying to keep replicating the status-quo forever. 
Regardless of the answer, I find it that it is a very narrow perspective if we 
only want to discuss workflows in the context of what was implemented initially 
in Open-O or ECOMP, instead of opening a broader discussion of what makes sense 
where in the overall architecture.

Best regards,
Michael



On Wed, Apr 26, 2017 at 2:10 AM, Lingli Deng mailto:denglingli at chinamobile.com>> wrote:

Hi Michael,

You may consult your gigaspace's colleage, as my recollection, native workflow 
proposed by gigaspaces was turned down by the consensus of the OPENO  
community, we decided to use BPMN/BPEL type of workflow, you can also find out 
the workflow in MSO /APPC of OPENCOMP are also using BPMN/DG
Thanks,
Lingli

From: onap-discuss-bounces at lists.onap.org<mailto:onap-discuss-bounces at 
lists.onap.org> [mailto:onap-discuss-bounces at 
lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org>] On Behalf Of 
Michael Brenner
Sent: 2017?4?26? 11:09
To: denghui (L) mailto:denghui12 at huawei.com>>
Cc: onap-tsc at lists.onap.org<mailto:onap-tsc at lists.onap.org>; JANA, 
RITTWIK (RITTWIK) mailto:rjana at 
research.att.com>>; onap-discuss at lists.onap.org<mailto:onap-discuss at 
lists.onap.org>

Subject: Re: [onap-discuss] Modelling discussion on Friday May 5th

But no TOSCA native workflows ... why?
Michael

On Tue, Apr 25, 2017 at 8:03 PM, denghui (L) mailto:denghui12 at huawei.com>> wrote:
Hi Michael,

Thanks for your suggestion, workflow is already covered in the Shitao?s 
session, they will discuss

1)   OPENCOMP Workflow

2)   OPEN-O Workflow.

Best regards,

DENG Hui

From: Michael Brenner [mailto:michael at 
gigaspaces.com<mailto:mich...@gigaspaces.com>]
Sent: Friday, April 21, 2017 7:14 AM
To: Amir Levy
Cc: JANA, RITTWIK (RITTWIK); Nguyenphu, Thinh (Nokia - US/Irving); denghui (L); 
onap-discuss at lists.onap.org<mailto:onap-discuss at lists.onap.org>; Nati 
Shalom; onap-tsc at lists.onap.org<mailto:onap-tsc at lists.onap.org>
Subject: Re: [onap-discuss] Modelling discussion on Friday May 5th


I'll be happy to attend and take part in the discussion and would like to 
suggest to add workflows to the agenda ...a topic which I offer

[onap-discuss] [onap-tsc] Modelling discussion on Friday May 5th

[denghui (L)]

Xiaojun,

You also made the point about SDN part, we should not only consider VNFD and 
SD, even for service configuration.
Thanks

DENG Hui

From: onap-discuss-bounces at lists.onap.org [mailto:onap-discuss-bounces at 
lists.onap.org] On Behalf Of xiexj...@chinatelecom.cn
Sent: Tuesday, April 25, 2017 10:26 AM
To: onap-discuss
Subject: Re: [onap-discuss] [onap-tsc] Modelling discussion on Friday May 5th

I agree with this.

Maybe we could consider the modeling from the perspective of the micro-service 
principle. The orchestrator is responsible for the execution of the workflow 
model(such as BPMN), and the controllers are charge of the execution of the 
configuration model(such as YANG). So in my opinion the modeling languages, 
which are suitable for the implementation of the orchestrator or the 
controllers respectively, are the best for ONAP now. In the future, if there is 
another better modeling language, the orchestrator or the controllers will 
autonomously evolve to a new version which adopt the new workflow or 
configuration modeling languages. The influence of the evolvement will be 
controllable.

Best Regards,

Xiaojun


 Ed Warnicke<mailto:hagbard at gmail.com>
? 2017-04-25 07:47
 Michael Brenner<mailto:michael at gigaspaces.com>
??? onap-discuss<mailto:onap-discuss at lists.onap.org>
??? Re: [onap-discuss][onap-tsc] ???Re: Modelling discussion on Friday May 5th
I strongly second this.

My experience is that there is a huge service for the good modelers who engage 
with the community to do incredible good... but modeling in a vacuum, away from 
the implementation, and then just expecting the implementers to follow 
directions works poorly.

I'd say that a far better activity for the long term health would be to plug 
good model people into the places in the community where models are in 
progress.  Their wisdom as participants can be huge, but they need to 
*participate*, not work off in a tower of UML.

Ed

On Mon, Apr 24, 2017 at 4:25 PM, Michael Brenner mailto:michael at gigaspaces.com>> wrote:
... on the other hand, what does one do with a smooth cohesive model, if you 
can't easily translate it to a data model? Without any intent to dive into a 
debate about whether the example is right or not ... we have an ETSI NFV VNF 
UML model ... and we cannot translate it into any data model - it takes manual 
work. The other issue is sort of the reverse - i.e. you don't actually KNOW 
that the UML model is right, until you implement it. And it is difficult to 
implement it, when you don't have the automatic translation tools. So you end 
up building an ideal model, but you don't know if it works ... until you have 
the right translation tools. How long is one to wait ... instead of 
implementing and iterating?
Like with any other project, it really comes down to a schedule, and knowing 
what you want to achieve within that schedule.

Best,
Michael

On Mon, Apr 24, 2017 at 6:23 PM, Brian Hedstrom mailto:brian.hedstrom at oamtechnologies.com>> wrote:
While the tools are maturing and advancing, if we choose to close that door 
now, there's no cohesive UML Common Information Model for ONAP.  Consequently, 
we would lack a protocol agnostic information model and when the next cool data 
modeling language or encoding scheme comes out, we have to start again with 
working backward. Another key benefit is that UML is much easier to comprehend 
due to it's graphical diagram nature, versus needing to understand a data 
modeling language and/or data encoding mechanism.
Consensus can be made on class diagrams for example, then translation to a data 
modeling language can be easily done by hand or by the emerging tools (see my 
previous email with the links).

On Mon, Apr 24, 2017 at 12:29 PM, Michael Brenner mailto:michael at gigaspaces.com>> wrote:
Hi all,

I actually tend to agree with Ed. While it may be an ideal approach in theory, 
tools for automatic generation from UML to Yang, or other modeling languages 
for that matter are improving, they are still too far from perfect, and require 
a lot of hand-holding so-to-speak, and as a result - too many headaches. We may 
be mired in tool debugging, instead on progressing on ONAP.

Michael

From: Ash Young mailto:a...@yunify.org>>
Subject: Re: [onap-discuss] [onap-tsc] ???Re: Modelling discussion on Friday 
May 5th
Date: April 24, 2017 at 10:09:22 AM PDT
To: Ed Warnicke mailto:hagbard at gmail.com>>, Brian 
Hedstrom mailto:brian.hedstrom at 
oamtechnologies.com>>
Cc: "JANA, RITTWIK \(RITTWIK\)" mailto:rjana at 
research.att.com>>, onap-discuss mailto:onap-discuss at lists.onap.org>>, onap-tsc mailto:onap-tsc at lists.onap.org>>

I'm actually in agreement with Brian on approach and tool. So much work has 
been going on here that I really don't want to see us go backwards by thinking 
Yang solves everything.

Ash

Sent from my iPhone

On Apr 24, 2017, at 12:01, Ed 

[onap-discuss] [onap-tsc] Modelling discussion on Friday May 5th

[xiexj...@chinatelecom.cn]

I agree with this.

Maybe we could consider the modeling from the perspective of the micro-service 
principle. The orchestrator is responsible for the execution of the workflow 
model(such as BPMN), and the controllers are charge of the execution of the 
configuration model(such as YANG). So in my opinion the modeling languages, 
which are suitable for the implementation of the orchestrator or the 
controllers respectively, are the best for ONAP now. In the future, if there is 
another better modeling language, the orchestrator or the controllers will 
autonomously evolve to a new version which adopt the new workflow or 
configuration modeling languages. The influence of the evolvement will be 
controllable.

Best Regards,

Xiaojun


 Ed Warnicke
? 2017-04-25 07:47
 Michael Brenner
??? onap-discuss
??? Re: [onap-discuss][onap-tsc] ???Re: Modelling discussion on Friday May 5th
I strongly second this.

My experience is that there is a huge service for the good modelers who engage 
with the community to do incredible good... but modeling in a vacuum, away from 
the implementation, and then just expecting the implementers to follow 
directions works poorly.

I'd say that a far better activity for the long term health would be to plug 
good model people into the places in the community where models are in 
progress.  Their wisdom as participants can be huge, but they need to 
*participate*, not work off in a tower of UML.

Ed

On Mon, Apr 24, 2017 at 4:25 PM, Michael Brenner  
wrote:
... on the other hand, what does one do with a smooth cohesive model, if you 
can't easily translate it to a data model? Without any intent to dive into a 
debate about whether the example is right or not ... we have an ETSI NFV VNF 
UML model ... and we cannot translate it into any data model - it takes manual 
work. The other issue is sort of the reverse - i.e. you don't actually KNOW 
that the UML model is right, until you implement it. And it is difficult to 
implement it, when you don't have the automatic translation tools. So you end 
up building an ideal model, but you don't know if it works ... until you have 
the right translation tools. How long is one to wait ... instead of 
implementing and iterating?
Like with any other project, it really comes down to a schedule, and knowing 
what you want to achieve within that schedule.

Best,
Michael

On Mon, Apr 24, 2017 at 6:23 PM, Brian Hedstrom  wrote:
While the tools are maturing and advancing, if we choose to close that door 
now, there's no cohesive UML Common Information Model for ONAP.  Consequently, 
we would lack a protocol agnostic information model and when the next cool data 
modeling language or encoding scheme comes out, we have to start again with 
working backward. Another key benefit is that UML is much easier to comprehend 
due to it's graphical diagram nature, versus needing to understand a data 
modeling language and/or data encoding mechanism. 
Consensus can be made on class diagrams for example, then translation to a data 
modeling language can be easily done by hand or by the emerging tools (see my 
previous email with the links).

On Mon, Apr 24, 2017 at 12:29 PM, Michael Brenner  
wrote:
Hi all,

I actually tend to agree with Ed. While it may be an ideal approach in theory, 
tools for automatic generation from UML to Yang, or other modeling languages 
for that matter are improving, they are still too far from perfect, and require 
a lot of hand-holding so-to-speak, and as a result - too many headaches. We may 
be mired in tool debugging, instead on progressing on ONAP.

Michael

From: Ash Young <a...@yunify.org>
Subject: Re: [onap-discuss] [onap-tsc] ???Re: Modelling discussion on Friday 
May 5th
Date: April 24, 2017 at 10:09:22 AM PDT
To: Ed Warnicke , Brian Hedstrom 
Cc: "JANA, RITTWIK \(RITTWIK\)" , onap-discuss 
, onap-tsc 

I'm actually in agreement with Brian on approach and tool. So much work has 
been going on here that I really don't want to see us go backwards by thinking 
Yang solves everything.

Ash

Sent from my iPhone

On Apr 24, 2017, at 12:01, Ed Warnicke  wrote:

I love UML in a variety of contexts, but for expressing things that are 
destined to be expressed in yang, or for creating things to be rendered to 
yang, in my experience its been a very poor fit.

Ed

On Mon, Apr 24, 2017 at 9:41 AM, Brian Hedstrom  wrote:
The way to put all these different data models under a single umbrella is to 
create a UML Information Model using Eclipse/Papyrus (as an open source tool).  
Unified Modeling Language (UML) is a standard syntax for describing the 
architectural design of a system
Object Management Group (OMG) & ISO standard
Originated from object-oriented software development methods
UML includes many diagrams types to graphically represent parts of a system?s 
model, including
Structural Views: The static nature of the system using objects, attributes and 
relationships (e.g., information or components 

[onap-discuss] [onap-tsc] Modelling discussion on Friday May 5th

[Brijesh Khandelwal]

Greetings,

Adding some thoughts on information model:
Orchestration need to interoperate among different interfaces, which in turn 
need to deal with very different payloads in form of YAML, YANG, JSON  etc. 
There will be lots of data processing among these models to process complete 
service. Handling these templates in orchestrator will impose limitations on 
capability and performance of orchestrator.
So, there should have standardized data model for smooth processing among 
orchestration steps.

Probably first time, orchestration is composing 3 different worlds of Network, 
Infra, IT, with different tunes of YANG, YAML, JSON/XML.
Is there a play to develop standardized data models for orchestration, which 
will meet needs of each area? Is TOSCA sufficient? Or need some extended JSON 
data models?


-Brijesh

From: onap-tsc-bounces at lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of GILBERT, MAZIN E (MAZIN E)
Sent: Thursday, April 20, 2017 8:30 AM
To: denghui (L); JANA, RITTWIK (RITTWIK)
Cc: onap-discuss at lists.onap.org; onap-tsc at lists.onap.org
Subject: Re: [onap-tsc] Modelling discussion on Friday May 5th

Rittwik, Deng,

This is great. Thank you  for taking the lead.

I realize the focus is on TOSCA and parsers. Wonderful!
I want to take you one level higher to start by discussing
what the framework look like for the information model. Perhaps  invite folks 
who have
operational experience. Then start describing the differernt
data models and how TOSCA plays a role in driving service chaining and micro 
services
(like analytics, data collections, etc).

It would be great if the outcome of this mini session to
be a recommendation position/paper or a proposal for a project.

Mazin


On Apr 20, 2017, at 4:34 AM, denghui (L) mailto:denghui12 at huawei.com>> wrote:

Hello all

We are happy to let you know that we are hosting a modeling session on Friday, 
May 5th, AT Lab.
9:00-10:30 Shitao moderate: TOSCA NFV Profile
10:30-12:00 Rittwik moderate: AT Parser
13:30-16:00 DengHui moderate: Modelling & Opendeployment

Please kindly help to let us know if you are interested in joining us, so that 
we can book a proper meeting room for our discussion

Best regards,

Rittwik & DENG Hui
___
ONAP-TSC mailing list
ONAP-TSC at lists.onap.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=2dwD7a5k4V9cZl09O7uTpejnZMF8aa01W3yMqrrZC5Y=HRoKLiOZCWLzl3Z-00DLQIUCwCAWqQL50mUFHtfYXYA=731fuCUnXbuPSOGHEcVf4U29cHpOGPKmwevRHGAoeiY=



Disclaimer:  This message and the information contained herein is proprietary 
and confidential and subject to the Tech Mahindra policy statement, you may 
review the policy at http://www.techmahindra.com/Disclaimer.html 
 externally 
http://tim.techmahindra.com/tim/disclaimer.html 
 internally within 
TechMahindra.


-- next part --
An HTML attachment was scrubbed...
URL: 

[onap-discuss] [onap-tsc] Modelling discussion on Friday May 5th

[GILBERT, MAZIN E (MAZIN E)]

Rittwik, Deng,

This is great. Thank you  for taking the lead.

I realize the focus is on TOSCA and parsers. Wonderful!
I want to take you one level higher to start by discussing
what the framework look like for the information model. Perhaps  invite folks 
who have
operational experience. Then start describing the differernt
data models and how TOSCA plays a role in driving service chaining and micro 
services
(like analytics, data collections, etc).

It would be great if the outcome of this mini session to
be a recommendation position/paper or a proposal for a project.

Mazin



On Apr 20, 2017, at 4:34 AM, denghui (L) mailto:denghui12 at huawei.com>> wrote:

Hello all

We are happy to let you know that we are hosting a modeling session on Friday, 
May 5th, AT Lab.
9:00-10:30 Shitao moderate: TOSCA NFV Profile
10:30-12:00 Rittwik moderate: AT Parser
13:30-16:00 DengHui moderate: Modelling & Opendeployment

Please kindly help to let us know if you are interested in joining us, so that 
we can book a proper meeting room for our discussion

Best regards,

Rittwik & DENG Hui
___
ONAP-TSC mailing list
ONAP-TSC at lists.onap.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Dtsc=DwICAg=LFYZ-o9_HUMeMTSQicvjIg=2dwD7a5k4V9cZl09O7uTpejnZMF8aa01W3yMqrrZC5Y=HRoKLiOZCWLzl3Z-00DLQIUCwCAWqQL50mUFHtfYXYA=731fuCUnXbuPSOGHEcVf4U29cHpOGPKmwevRHGAoeiY=

-- next part --
An HTML attachment was scrubbed...
URL: