Re: [onap-tsc] Optimization framework

[PUTHENPURA, SARAT (SARAT)]

All (especially Steve and Chris),

Thanks much for your excellent suggestions to render additional clarity.
I have incorporated them to the proposal. 

Best regards,
Sarat


-Original Message-
From: Christopher Donley (Chris) [mailto:christopher.don...@huawei.com] 
Sent: Thursday, June 22, 2017 4:36 PM
To: SPATSCHECK, OLIVER (OLIVER) <spat...@research.att.com>
Cc: Stephen Terrill <stephen.terr...@ericsson.com>; PUTHENPURA, SARAT (SARAT) 
<sa...@research.att.com>; onap-tsc <onap-tsc@lists.onap.org>
Subject: RE: [onap-tsc] Optimization framework

Thanks Oliver.  That works for me.



Chris



-Original Message-

From: SPATSCHECK, OLIVER (OLIVER) [mailto:spat...@research.att.com] 

Sent: Thursday, June 22, 2017 12:50 PM

To: Christopher Donley (Chris)

Cc: Stephen Terrill; PUTHENPURA, SARAT (SARAT); onap-tsc

Subject: Re: [onap-tsc] Optimization framework





I would say something like:



“ It offers a set of MS which provide reusable optimization functionality which 
can optionally be used by other ECOMP components if required by a use case.” 



I like MS better then SDK but I think we agree.



Can certainly change to may.



Thx



Oliver



> On Jun 22, 2017, at 3:35 PM  EDT, Christopher Donley (Chris) 
> <christopher.don...@huawei.com> wrote:

> 

> Oliver,

>  

> Just to clarify the governance question: is this project producing a set of 
> services or an SDK that other projects can choose to implement or is it 
> producing artifacts that they must implement?  

>  

> From your example, I read it as the former (that projects can choose whether 
> or not to utilize oof), rather than a mandate.  If so, I’d recommend updating 
> the proposal (particularly the architecture alignment section) to change 
> “[may|will] need to….” language to “may ….” to clarify that point.

>  

> Also (since it will come up tomorrow), please adjust the committer list. 
> Everyone on the project is currently listed as a committer.

>  

> Chris

>  

> From: onap-tsc-boun...@lists.onap.org 
> [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of SPATSCHECK, OLIVER 
> (OLIVER)

> Sent: Thursday, June 22, 2017 10:31 AM

> To: Stephen Terrill

> Cc: PUTHENPURA, SARAT (SARAT); onap-tsc

> Subject: Re: [onap-tsc] Optimization framework

>  

>  

> I think there are a couple of misconceptions here. 

>  

> This is not the change management project. The change management project was 
> about the end to end use case flow needed to perform change management.  This 
> project ONLY provides the schedule optimization part of that flow. The flow 
> itself touches many projects and as discussed I agree is best handled as a 
> use case. The actual flows would be implemented using all the regular 
> components which at one point in the flow call out to this project for an 
> optimization decision. 

>  

> The same is true for homing. 

>  

> So let me try to illustrate the flow of this a bit better. The scope of the 
> project is algorithms and a run time framework to :

>  

> 1. gather and normalize data to perform an optimization decision based on a 
> request

> 2. gather the polices from the policy engine provided by the policy project 
> using standard APIs exported by that project

> 3. formulate the optimization problem

> 4. run the optimization algorithm (this might be iterative with the prior 
> steps)

> 5. return an optimization result to the requestor

>  

> So let me give a homing related example.

>  

> Let’s assume a workflow in the SO is triggered to instantiate a VNF. As part 
> of the workflow there might be a call into HAS to derive the optimal 
> location. The constrains for the placement are associated with the policy 
> (handled in the policy project) for that VNF. HAS will now go to A and 
> DCAE (using the regular A and DCAE APIs) to gather enough data to make a 
> placement decision at which point HAS would return the result back to the SO 
> so the SO can proceed instantiating the VNF following the rules in it’s 
> workflow.

>  

> Please note that the call out to HAS was part of the SO workflow for that 
> particular VNF.  It’s under the control of whoever designs the SO workflow 
> (likely the specific use case) if HAS gets called or not and what constraints 
> are communicated.

>  

> In terms of execution of all of this. Parts currently run as independent MS 
> other parts run as MS managed on DCAE. Again this project just uses 
> infrastructure that already exists.

>  

> You also mentioned CLAMP. CLAMP flows as any other flow in ONAP could call 
> out to the optimization framework if it helps. If it doesn’t the flows don’t.

>  

> So this should explain how this project does not “hurt” any other project and 
>  is alig

Re: [onap-tsc] Optimization framework

[Christopher Donley (Chris)]

Thanks Oliver.  That works for me.

Chris

-Original Message-
From: SPATSCHECK, OLIVER (OLIVER) [mailto:spat...@research.att.com] 
Sent: Thursday, June 22, 2017 12:50 PM
To: Christopher Donley (Chris)
Cc: Stephen Terrill; PUTHENPURA, SARAT (SARAT); onap-tsc
Subject: Re: [onap-tsc] Optimization framework


I would say something like:

“ It offers a set of MS which provide reusable optimization functionality which 
can optionally be used by other ECOMP components if required by a use case.” 

I like MS better then SDK but I think we agree.

Can certainly change to may.

Thx

Oliver

> On Jun 22, 2017, at 3:35 PM  EDT, Christopher Donley (Chris) 
> <christopher.don...@huawei.com> wrote:
> 
> Oliver,
>  
> Just to clarify the governance question: is this project producing a set of 
> services or an SDK that other projects can choose to implement or is it 
> producing artifacts that they must implement?  
>  
> From your example, I read it as the former (that projects can choose whether 
> or not to utilize oof), rather than a mandate.  If so, I’d recommend updating 
> the proposal (particularly the architecture alignment section) to change 
> “[may|will] need to….” language to “may ….” to clarify that point.
>  
> Also (since it will come up tomorrow), please adjust the committer list. 
> Everyone on the project is currently listed as a committer.
>  
> Chris
>  
> From: onap-tsc-boun...@lists.onap.org 
> [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of SPATSCHECK, OLIVER 
> (OLIVER)
> Sent: Thursday, June 22, 2017 10:31 AM
> To: Stephen Terrill
> Cc: PUTHENPURA, SARAT (SARAT); onap-tsc
> Subject: Re: [onap-tsc] Optimization framework
>  
>  
> I think there are a couple of misconceptions here. 
>  
> This is not the change management project. The change management project was 
> about the end to end use case flow needed to perform change management.  This 
> project ONLY provides the schedule optimization part of that flow. The flow 
> itself touches many projects and as discussed I agree is best handled as a 
> use case. The actual flows would be implemented using all the regular 
> components which at one point in the flow call out to this project for an 
> optimization decision. 
>  
> The same is true for homing. 
>  
> So let me try to illustrate the flow of this a bit better. The scope of the 
> project is algorithms and a run time framework to :
>  
> 1. gather and normalize data to perform an optimization decision based on a 
> request
> 2. gather the polices from the policy engine provided by the policy project 
> using standard APIs exported by that project
> 3. formulate the optimization problem
> 4. run the optimization algorithm (this might be iterative with the prior 
> steps)
> 5. return an optimization result to the requestor
>  
> So let me give a homing related example.
>  
> Let’s assume a workflow in the SO is triggered to instantiate a VNF. As part 
> of the workflow there might be a call into HAS to derive the optimal 
> location. The constrains for the placement are associated with the policy 
> (handled in the policy project) for that VNF. HAS will now go to A and 
> DCAE (using the regular A and DCAE APIs) to gather enough data to make a 
> placement decision at which point HAS would return the result back to the SO 
> so the SO can proceed instantiating the VNF following the rules in it’s 
> workflow.
>  
> Please note that the call out to HAS was part of the SO workflow for that 
> particular VNF.  It’s under the control of whoever designs the SO workflow 
> (likely the specific use case) if HAS gets called or not and what constraints 
> are communicated.
>  
> In terms of execution of all of this. Parts currently run as independent MS 
> other parts run as MS managed on DCAE. Again this project just uses 
> infrastructure that already exists.
>  
> You also mentioned CLAMP. CLAMP flows as any other flow in ONAP could call 
> out to the optimization framework if it helps. If it doesn’t the flows don’t.
>  
> So this should explain how this project does not “hurt” any other project and 
>  is aligned with the architecture.
>  
> Now if I interpret your second question correctly you are also asking “How 
> does it help?” .
>  
> The reason we want to combine all of this in one project is that there is 
> reusability in the code required in steps 1.-5.
>  
> For example:
>  
> 1. + 2. requires code to gather information from many existing ONAP 
> components and present them in a common format so they can be used to derive 
> the optimization formulation.
>  
> 3. + 4. as we do not believe that there is one formulation/optimizer which 
> solvers every problem we do believe that the same

Re: [onap-tsc] Optimization framework

[SPATSCHECK, OLIVER (OLIVER)]

I would say something like:

“ It offers a set of MS which provide reusable optimization functionality which 
can optionally be used by other ECOMP components if required by a use case.” 

I like MS better then SDK but I think we agree.

Can certainly change to may.

Thx

Oliver

> On Jun 22, 2017, at 3:35 PM  EDT, Christopher Donley (Chris) 
> <christopher.don...@huawei.com> wrote:
> 
> Oliver,
>  
> Just to clarify the governance question: is this project producing a set of 
> services or an SDK that other projects can choose to implement or is it 
> producing artifacts that they must implement?  
>  
> From your example, I read it as the former (that projects can choose whether 
> or not to utilize oof), rather than a mandate.  If so, I’d recommend updating 
> the proposal (particularly the architecture alignment section) to change 
> “[may|will] need to….” language to “may ….” to clarify that point.
>  
> Also (since it will come up tomorrow), please adjust the committer list. 
> Everyone on the project is currently listed as a committer.
>  
> Chris
>  
> From: onap-tsc-boun...@lists.onap.org 
> [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of SPATSCHECK, OLIVER 
> (OLIVER)
> Sent: Thursday, June 22, 2017 10:31 AM
> To: Stephen Terrill
> Cc: PUTHENPURA, SARAT (SARAT); onap-tsc
> Subject: Re: [onap-tsc] Optimization framework
>  
>  
> I think there are a couple of misconceptions here. 
>  
> This is not the change management project. The change management project was 
> about the end to end use case flow needed to perform change management.  This 
> project ONLY provides the schedule optimization part of that flow. The flow 
> itself touches many projects and as discussed I agree is best handled as a 
> use case. The actual flows would be implemented using all the regular 
> components which at one point in the flow call out to this project for an 
> optimization decision. 
>  
> The same is true for homing. 
>  
> So let me try to illustrate the flow of this a bit better. The scope of the 
> project is algorithms and a run time framework to :
>  
> 1. gather and normalize data to perform an optimization decision based on a 
> request
> 2. gather the polices from the policy engine provided by the policy project 
> using standard APIs exported by that project
> 3. formulate the optimization problem
> 4. run the optimization algorithm (this might be iterative with the prior 
> steps)
> 5. return an optimization result to the requestor
>  
> So let me give a homing related example.
>  
> Let’s assume a workflow in the SO is triggered to instantiate a VNF. As part 
> of the workflow there might be a call into HAS to derive the optimal 
> location. The constrains for the placement are associated with the policy 
> (handled in the policy project) for that VNF. HAS will now go to A and 
> DCAE (using the regular A and DCAE APIs) to gather enough data to make a 
> placement decision at which point HAS would return the result back to the SO 
> so the SO can proceed instantiating the VNF following the rules in it’s 
> workflow.
>  
> Please note that the call out to HAS was part of the SO workflow for that 
> particular VNF.  It’s under the control of whoever designs the SO workflow 
> (likely the specific use case) if HAS gets called or not and what constraints 
> are communicated.
>  
> In terms of execution of all of this. Parts currently run as independent MS 
> other parts run as MS managed on DCAE. Again this project just uses 
> infrastructure that already exists.
>  
> You also mentioned CLAMP. CLAMP flows as any other flow in ONAP could call 
> out to the optimization framework if it helps. If it doesn’t the flows don’t.
>  
> So this should explain how this project does not “hurt” any other project and 
>  is aligned with the architecture.
>  
> Now if I interpret your second question correctly you are also asking “How 
> does it help?” .
>  
> The reason we want to combine all of this in one project is that there is 
> reusability in the code required in steps 1.-5.
>  
> For example:
>  
> 1. + 2. requires code to gather information from many existing ONAP 
> components and present them in a common format so they can be used to derive 
> the optimization formulation.
>  
> 3. + 4. as we do not believe that there is one formulation/optimizer which 
> solvers every problem we do believe that the same formulation approach 
> combined with a set of optimizers and constraints can cover a large set of 
> diverse use cases leading to reuse in this area too.
>  
>  So the benefit of the project as the library of 
> formulations/optimizers/runtime framework grows will be that instead of 
> writing code

Re: [onap-tsc] Optimization framework

[SPATSCHECK, OLIVER (OLIVER)]

I think you are highlighting this:

> In terms of execution of all of this. Parts currently run as independent MS 
> other parts run as MS managed on DCAE. Again this project just uses 
> infrastructure that already exists.
>  

that survived.

Oliver


> On Jun 22, 2017, at 3:28 PM  EDT, ROSE, DANIEL V <dr6...@att.com> wrote:
> 
> The original design I saw had the SNIRO framework (att internal name for 
> this) as being a few microservices deployed via OOM. OOM would then place 
> them near other components based on needs (Ie if dcae needs a certain 
> optimization service, instances of it would be deployed closer to the edge 
> dace relies on. If it is something SO needs, it would be deployed closer to 
> the core but that placement logic was all in oom. Not sure if that logic 
> survives to the current proposal.
>  
> Thanks,
>  
> Daniel Rose
> ECOMP / ONAP
> com.att.ecomp
> 732-420-7308
>  
> From: onap-tsc-boun...@lists.onap.org 
> [mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Stephen Terrill
> Sent: Thursday, June 22, 2017 3:22 PM
> To: SPATSCHECK, OLIVER <spat...@research.att.com>
> Cc: PUTHENPURA, SARAT <sa...@research.att.com>; onap-tsc 
> <onap-tsc@lists.onap.org>
> Subject: Re: [onap-tsc] Optimization framework
>  
> Hi Oliver,
>  
> Thanks for the clarifications – I do understand better now and as a result I 
> am fine with this.
>  
> Two questions/comments though:
> -  I assume it could even be called by the controllers if this was 
> relivant (e.g. the VF-C, OOM).
>  
> Perhaps in the description at the start just after where it says the project 
> would provide 2 new services a) HAS and b) CMSO, you could put:
> These will be delivered as 3 modules.  One for HAS, one for CMSO and one for 
> the service design framework.
> The HAS and CMSO modules will execute both as services on DCAE and 
> independent processes.
> --
>  
> BR,
>  
> Steve
>  
> From: SPATSCHECK, OLIVER (OLIVER) [mailto:spat...@research.att.com] 
> Sent: 22 June 2017 19:31
> To: Stephen Terrill <stephen.terr...@ericsson.com>
> Cc: onap-tsc <onap-tsc@lists.onap.org>; PUTHENPURA, SARAT (SARAT) 
> <sa...@research.att.com>
> Subject: Re: [onap-tsc] Optimization framework
>  
>  
> I think there are a couple of misconceptions here. 
>  
> This is not the change management project. The change management project was 
> about the end to end use case flow needed to perform change management.  This 
> project ONLY provides the schedule optimization part of that flow. The flow 
> itself touches many projects and as discussed I agree is best handled as a 
> use case. The actual flows would be implemented using all the regular 
> components which at one point in the flow call out to this project for an 
> optimization decision. 
>  
> The same is true for homing. 
>  
> So let me try to illustrate the flow of this a bit better. The scope of the 
> project is algorithms and a run time framework to :
>  
> 1. gather and normalize data to perform an optimization decision based on a 
> request
> 2. gather the polices from the policy engine provided by the policy project 
> using standard APIs exported by that project
> 3. formulate the optimization problem
> 4. run the optimization algorithm (this might be iterative with the prior 
> steps)
> 5. return an optimization result to the requestor
>  
> So let me give a homing related example.
>  
> Let’s assume a workflow in the SO is triggered to instantiate a VNF. As part 
> of the workflow there might be a call into HAS to derive the optimal 
> location. The constrains for the placement are associated with the policy 
> (handled in the policy project) for that VNF. HAS will now go to A and 
> DCAE (using the regular A and DCAE APIs) to gather enough data to make a 
> placement decision at which point HAS would return the result back to the SO 
> so the SO can proceed instantiating the VNF following the rules in it’s 
> workflow.
>  
> Please note that the call out to HAS was part of the SO workflow for that 
> particular VNF.  It’s under the control of whoever designs the SO workflow 
> (likely the specific use case) if HAS gets called or not and what constraints 
> are communicated.
>  
> In terms of execution of all of this. Parts currently run as independent MS 
> other parts run as MS managed on DCAE. Again this project just uses 
> infrastructure that already exists.
>  
> You also mentioned CLAMP. CLAMP flows as any other flow in ONAP could call 
> out to the optimization framework if it helps. If it doesn’t the flows don’t.
>  
> So this should explain how this project does not “hurt” any other project and 
&

Re: [onap-tsc] Optimization framework

[SPATSCHECK, OLIVER (OLIVER)]

> On Jun 22, 2017, at 3:22 PM  EDT, Stephen Terrill 
> <stephen.terr...@ericsson.com> wrote:
> 
> Hi Oliver,
>  
> Thanks for the clarifications – I do understand better now and as a result I 
> am fine with this.
>  
> Two questions/comments though:
>   • I assume it could even be called by the controllers if this was 
> relivant (e.g. the VF-C, OOM).
>  

Certainly. Any ECOMP component could call this.

Thx

Oliver

> Perhaps in the description at the start just after where it says the project 
> would provide 2 new services a) HAS and b) CMSO, you could put:
> These will be delivered as 3 modules.  One for HAS, one for CMSO and one for 
> the service design framework.
> The HAS and CMSO modules will execute both as services on DCAE and 
> independent processes.
> --
>  
> BR,
>  
> Steve
>  
> From: SPATSCHECK, OLIVER (OLIVER) [mailto:spat...@research.att.com] 
> Sent: 22 June 2017 19:31
> To: Stephen Terrill <stephen.terr...@ericsson.com>
> Cc: onap-tsc <onap-tsc@lists.onap.org>; PUTHENPURA, SARAT (SARAT) 
> <sa...@research.att.com>
> Subject: Re: [onap-tsc] Optimization framework
>  
>  
> I think there are a couple of misconceptions here. 
>  
> This is not the change management project. The change management project was 
> about the end to end use case flow needed to perform change management.  This 
> project ONLY provides the schedule optimization part of that flow. The flow 
> itself touches many projects and as discussed I agree is best handled as a 
> use case. The actual flows would be implemented using all the regular 
> components which at one point in the flow call out to this project for an 
> optimization decision. 
>  
> The same is true for homing. 
>  
> So let me try to illustrate the flow of this a bit better. The scope of the 
> project is algorithms and a run time framework to :
>  
> 1. gather and normalize data to perform an optimization decision based on a 
> request
> 2. gather the polices from the policy engine provided by the policy project 
> using standard APIs exported by that project
> 3. formulate the optimization problem
> 4. run the optimization algorithm (this might be iterative with the prior 
> steps)
> 5. return an optimization result to the requestor
>  
> So let me give a homing related example.
>  
> Let’s assume a workflow in the SO is triggered to instantiate a VNF. As part 
> of the workflow there might be a call into HAS to derive the optimal 
> location. The constrains for the placement are associated with the policy 
> (handled in the policy project) for that VNF. HAS will now go to A and 
> DCAE (using the regular A and DCAE APIs) to gather enough data to make a 
> placement decision at which point HAS would return the result back to the SO 
> so the SO can proceed instantiating the VNF following the rules in it’s 
> workflow.
>  
> Please note that the call out to HAS was part of the SO workflow for that 
> particular VNF.  It’s under the control of whoever designs the SO workflow 
> (likely the specific use case) if HAS gets called or not and what constraints 
> are communicated.
>  
> In terms of execution of all of this. Parts currently run as independent MS 
> other parts run as MS managed on DCAE. Again this project just uses 
> infrastructure that already exists.
>  
> You also mentioned CLAMP. CLAMP flows as any other flow in ONAP could call 
> out to the optimization framework if it helps. If it doesn’t the flows don’t.
>  
> So this should explain how this project does not “hurt” any other project and 
>  is aligned with the architecture.
>  
> Now if I interpret your second question correctly you are also asking “How 
> does it help?” .
>  
> The reason we want to combine all of this in one project is that there is 
> reusability in the code required in steps 1.-5.
>  
> For example:
>  
> 1. + 2. requires code to gather information from many existing ONAP 
> components and present them in a common format so they can be used to derive 
> the optimization formulation.
>  
> 3. + 4. as we do not believe that there is one formulation/optimizer which 
> solvers every problem we do believe that the same formulation approach 
> combined with a set of optimizers and constraints can cover a large set of 
> diverse use cases leading to reuse in this area too.
>  
>  So the benefit of the project as the library of 
> formulations/optimizers/runtime framework grows will be that instead of 
> writing code for new optimization challenges they can be just configured or 
> at least will require minimal code development.
>  
> Does that address your concerns?
>  
> Please advice how you want to document this? E.g. 

Re: [onap-tsc] Optimization framework

[ROSE, DANIEL V]

The original design I saw had the SNIRO framework (att internal name for this) 
as being a few microservices deployed via OOM. OOM would then place them near 
other components based on needs (Ie if dcae needs a certain optimization 
service, instances of it would be deployed closer to the edge dace relies on. 
If it is something SO needs, it would be deployed closer to the core but that 
placement logic was all in oom. Not sure if that logic survives to the current 
proposal.

Thanks,

Daniel Rose
ECOMP / ONAP
com.att.ecomp
732-420-7308

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Stephen Terrill
Sent: Thursday, June 22, 2017 3:22 PM
To: SPATSCHECK, OLIVER <spat...@research.att.com>
Cc: PUTHENPURA, SARAT <sa...@research.att.com>; onap-tsc 
<onap-tsc@lists.onap.org>
Subject: Re: [onap-tsc] Optimization framework

Hi Oliver,

Thanks for the clarifications – I do understand better now and as a result I am 
fine with this.

Two questions/comments though:
-  I assume it could even be called by the controllers if this was 
relivant (e.g. the VF-C, OOM).

Perhaps in the description at the start just after where it says the project 
would provide 2 new services a) HAS and b) CMSO, you could put:
These will be delivered as 3 modules.  One for HAS, one for CMSO and one for 
the service design framework.
The HAS and CMSO modules will execute both as services on DCAE and independent 
processes.
--

BR,

Steve

From: SPATSCHECK, OLIVER (OLIVER) [mailto:spat...@research.att.com]
Sent: 22 June 2017 19:31
To: Stephen Terrill 
<stephen.terr...@ericsson.com<mailto:stephen.terr...@ericsson.com>>
Cc: onap-tsc <onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>>; 
PUTHENPURA, SARAT (SARAT) 
<sa...@research.att.com<mailto:sa...@research.att.com>>
Subject: Re: [onap-tsc] Optimization framework


I think there are a couple of misconceptions here.

This is not the change management project. The change management project was 
about the end to end use case flow needed to perform change management.  This 
project ONLY provides the schedule optimization part of that flow. The flow 
itself touches many projects and as discussed I agree is best handled as a use 
case. The actual flows would be implemented using all the regular components 
which at one point in the flow call out to this project for an optimization 
decision.

The same is true for homing.

So let me try to illustrate the flow of this a bit better. The scope of the 
project is algorithms and a run time framework to :

1. gather and normalize data to perform an optimization decision based on a 
request
2. gather the polices from the policy engine provided by the policy project 
using standard APIs exported by that project
3. formulate the optimization problem
4. run the optimization algorithm (this might be iterative with the prior steps)
5. return an optimization result to the requestor

So let me give a homing related example.

Let’s assume a workflow in the SO is triggered to instantiate a VNF. As part of 
the workflow there might be a call into HAS to derive the optimal location. The 
constrains for the placement are associated with the policy (handled in the 
policy project) for that VNF. HAS will now go to A and DCAE (using the 
regular A and DCAE APIs) to gather enough data to make a placement decision 
at which point HAS would return the result back to the SO so the SO can proceed 
instantiating the VNF following the rules in it’s workflow.

Please note that the call out to HAS was part of the SO workflow for that 
particular VNF.  It’s under the control of whoever designs the SO workflow 
(likely the specific use case) if HAS gets called or not and what constraints 
are communicated.

In terms of execution of all of this. Parts currently run as independent MS 
other parts run as MS managed on DCAE. Again this project just uses 
infrastructure that already exists.

You also mentioned CLAMP. CLAMP flows as any other flow in ONAP could call out 
to the optimization framework if it helps. If it doesn’t the flows don’t.

So this should explain how this project does not “hurt” any other project and  
is aligned with the architecture.

Now if I interpret your second question correctly you are also asking “How does 
it help?” .

The reason we want to combine all of this in one project is that there is 
reusability in the code required in steps 1.-5.

For example:

1. + 2. requires code to gather information from many existing ONAP components 
and present them in a common format so they can be used to derive the 
optimization formulation.

3. + 4. as we do not believe that there is one formulation/optimizer which 
solvers every problem we do believe that the same formulation approach combined 
with a set of optimizers and constraints can cover a large set of diverse use 
cases leading to reuse in this area too.

 So the benefit of the project as the libra

Re: [onap-tsc] Optimization framework

[Stephen Terrill]

Hi Oliver,

Thanks for the clarifications – I do understand better now and as a result I am 
fine with this.

Two questions/comments though:

  *   I assume it could even be called by the controllers if this was relivant 
(e.g. the VF-C, OOM).

Perhaps in the description at the start just after where it says the project 
would provide 2 new services a) HAS and b) CMSO, you could put:
These will be delivered as 3 modules.  One for HAS, one for CMSO and one for 
the service design framework.
The HAS and CMSO modules will execute both as services on DCAE and independent 
processes.
--

BR,

Steve

From: SPATSCHECK, OLIVER (OLIVER) [mailto:spat...@research.att.com]
Sent: 22 June 2017 19:31
To: Stephen Terrill <stephen.terr...@ericsson.com>
Cc: onap-tsc <onap-tsc@lists.onap.org>; PUTHENPURA, SARAT (SARAT) 
<sa...@research.att.com>
Subject: Re: [onap-tsc] Optimization framework


I think there are a couple of misconceptions here.

This is not the change management project. The change management project was 
about the end to end use case flow needed to perform change management.  This 
project ONLY provides the schedule optimization part of that flow. The flow 
itself touches many projects and as discussed I agree is best handled as a use 
case. The actual flows would be implemented using all the regular components 
which at one point in the flow call out to this project for an optimization 
decision.

The same is true for homing.

So let me try to illustrate the flow of this a bit better. The scope of the 
project is algorithms and a run time framework to :

1. gather and normalize data to perform an optimization decision based on a 
request
2. gather the polices from the policy engine provided by the policy project 
using standard APIs exported by that project
3. formulate the optimization problem
4. run the optimization algorithm (this might be iterative with the prior steps)
5. return an optimization result to the requestor

So let me give a homing related example.

Let’s assume a workflow in the SO is triggered to instantiate a VNF. As part of 
the workflow there might be a call into HAS to derive the optimal location. The 
constrains for the placement are associated with the policy (handled in the 
policy project) for that VNF. HAS will now go to A and DCAE (using the 
regular A and DCAE APIs) to gather enough data to make a placement decision 
at which point HAS would return the result back to the SO so the SO can proceed 
instantiating the VNF following the rules in it’s workflow.

Please note that the call out to HAS was part of the SO workflow for that 
particular VNF.  It’s under the control of whoever designs the SO workflow 
(likely the specific use case) if HAS gets called or not and what constraints 
are communicated.

In terms of execution of all of this. Parts currently run as independent MS 
other parts run as MS managed on DCAE. Again this project just uses 
infrastructure that already exists.

You also mentioned CLAMP. CLAMP flows as any other flow in ONAP could call out 
to the optimization framework if it helps. If it doesn’t the flows don’t.

So this should explain how this project does not “hurt” any other project and  
is aligned with the architecture.

Now if I interpret your second question correctly you are also asking “How does 
it help?” .

The reason we want to combine all of this in one project is that there is 
reusability in the code required in steps 1.-5.

For example:

1. + 2. requires code to gather information from many existing ONAP components 
and present them in a common format so they can be used to derive the 
optimization formulation.

3. + 4. as we do not believe that there is one formulation/optimizer which 
solvers every problem we do believe that the same formulation approach combined 
with a set of optimizers and constraints can cover a large set of diverse use 
cases leading to reuse in this area too.

 So the benefit of the project as the library of 
formulations/optimizers/runtime framework grows will be that instead of writing 
code for new optimization challenges they can be just configured or at least 
will require minimal code development.

Does that address your concerns?

Please advice how you want to document this? E.g. I can add this as a comment 
to the project proposal. I think the proposal already makes above points but I 
am probably biased as I have read it too many times …. .

Anybody else?

I am wondering what it would take to put this on the schedule tomorrow so we 
can close on those things?

Thx

Oliver


On Jun 22, 2017, at 12:38 PM, Stephen Terrill 
<stephen.terr...@ericsson.com<mailto:stephen.terr...@ericsson.com>> wrote:

Hi,

I had an action to start a thread about the optimization framework : 
https://wiki.onap.org/pages/viewpage.action?pageId=3247288<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_pages_viewpage.action-3FpageId-3D3247288=DwMFAw=LFYZ-o9_HUMeMTSQicvjIg=3WBYkehcha

[onap-tsc] Optimization framework

[Stephen Terrill]

Hi,

I had an action to start a thread about the optimization framework : 
https://wiki.onap.org/pages/viewpage.action?pageId=3247288

To start with, my question is not on the need of optimization and Change 
management, nor about release vs project (that can be sorted out) but about the 
architecture and related project structure we should have for this 
functionality. Basically I am wondering concretely what this is and how 
best it should be done.

For optimization:
The way HAS is described it sometimes appears as an extra module that receives 
information from DCAI, AAI, makes a resource allocation decision and stores 
that in A  This interpretation of the approach leaves me wondering about 
the overlap with:

  *   DCAE applications (if I can use the word)
  *   Policy framework
  *   Orchestration and controllers (which should update A).
  *   CLAMP from a SDC perspective?
Another interpretation is that HAS is something that is called from DCAE, 
CLAMP, SO, Controllers, and appears to be that there is commonality between 
them hence worth having as a common module.  Is it really common?  Instead 
isn't it addition on CLAMP, new DCAE applications, SO and controller modules?  
If so, should we go ahead and place the work in those projects?

For CMSO:

  *   I understand this replaces the change management project?
  *   I understand from this description that it is a separate, new module that 
is created.

BR,

Steve


[Ericsson]

STEPHEN TERRILL
Technology Specialist
DUIC, Systems and Technology
Development Unit IP & Cloud
Business Unit, IT & Cloud Products

Ericsson
Ericsson R Center, via de los Poblados 13
28033, Madrid, Spain
Phone +34 339 3005
Mobile +34 609 168 515
stephen.terr...@ericsson.com
www.ericsson.com


[http://www.ericsson.com/current_campaign]

Legal entity: Ericsson España S.A, compay registration number ESA288568603. 
This Communication is Confidential. We only send and receive email on the basis 
of the terms set out at 
www.ericsson.com/email_disclaimer

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