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

2018-05-18 Thread 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 <parviz.yeg...@huawei.com>; Alla Goldner 
<alla.gold...@amdocs.com>; Vladimir Yanover (vyanover) <vyano...@cisco.com>; 
Dhananjay Pavgi <dp00476...@techmahindra.com>; SHANKARANARAYANAN, N K 
<shan...@research.att.com>; onap-usecase...@lists.onap.org
Cc: onap-disc...@lists.onap.org; onap-tsc <onap-tsc@lists.onap.org>
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: <onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org>> 
on behalf of Parviz Yegani 
<parviz.yeg...@huawei.com<mailto:parviz.yeg...@huawei.com>>
Date: Thursday, May 17, 2018 at 5:38 AM
To: Alla Goldner <alla.gold...@amdocs.com<mailto:alla.gold...@amdocs.com>>, 
"Vladimir Yanover (vyanover)" <vyano...@cisco.com<mailto:vyano...@cisco.com>>, 
Dhananjay Pavgi 
<dp00476...@techmahindra.com<mailto:dp00476...@techmahindra.com>>, 
"SHANKARANARAYANAN, N K" 
<shan...@research.att.com<mailto:shan...@research.att.com>>, 
"onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org>" 
<onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org>>
Cc: onap-discuss 
<onap-disc...@lists.onap.org<mailto:onap-disc...@lists.onap.org>>, onap-tsc 
<onap-tsc@lists.onap.org<mailto:onap-tsc@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 “Pinea

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

2018-05-17 Thread Martin Skorupski 
Thanks Dan!

 

I fully agree to your view! 

The SDN-R project just adds some wireless/ran related applications/functions 
according to ONAP procedures and process to SDNC. 

That was the reason, why SDN-R is a subproject of SDNC – also visible as 
subfolder of in the ONAP wiki and in ONAP gerrit. 

 

Cheers, 

Martin

 

Von: onap-usecasesub-boun...@lists.onap.org 
[mailto:onap-usecasesub-boun...@lists.onap.org] Im Auftrag von TIMONEY, DAN
Gesendet: Donnerstag, 17. Mai 2018 14:50
An: Parviz Yegani <parviz.yeg...@huawei.com>; Alla Goldner 
<alla.gold...@amdocs.com>; Vladimir Yanover (vyanover) <vyano...@cisco.com>; 
Dhananjay Pavgi <dp00476...@techmahindra.com>; SHANKARANARAYANAN, N K 
<shan...@research.att.com>; onap-usecase...@lists.onap.org
Cc: onap-disc...@lists.onap.org; onap-tsc <onap-tsc@lists.onap.org>
Betreff: Re: [Onap-usecasesub] [onap-tsc] 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: <onap-tsc-boun...@lists.onap.org <mailto:onap-tsc-boun...@lists.onap.org> 
> on behalf of Parviz Yegani <parviz.yeg...@huawei.com 
<mailto:parviz.yeg...@huawei.com> >
Date: Thursday, May 17, 2018 at 5:38 AM
To: Alla Goldner <alla.gold...@amdocs.com <mailto:alla.gold...@amdocs.com> >, 
"Vladimir Yanover (vyanover)" <vyano...@cisco.com <mailto:vyano...@cisco.com> 
>, Dhananjay Pavgi <dp00476...@techmahindra.com 
<mailto:dp00476...@techmahindra.com> >, "SHANKARANARAYANAN, N K" 
<shan...@research.att.com <mailto:shan...@research.att.com> >, 
"onap-usecase...@lists.onap.org <mailto:onap-usecase...@lists.onap.org> " 
<onap-usecase...@lists.onap.org <mailto:onap-usecase...@lists.onap.org> >
Cc: onap-discuss <onap-disc...@lists.onap.org 
<mailto:onap-disc...@lists.onap.org> >, onap-tsc <onap-tsc@lists.onap.org 
<mailto:onap-tsc@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

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

2018-05-17 Thread Stephen Terrill 
Very useful clarification.  BR, Steve.

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of TIMONEY, DAN
Sent: Thursday, May 17, 2018 2:50 PM
To: Parviz Yegani <parviz.yeg...@huawei.com>; Alla Goldner 
<alla.gold...@amdocs.com>; Vladimir Yanover (vyanover) <vyano...@cisco.com>; 
Dhananjay Pavgi <dp00476...@techmahindra.com>; SHANKARANARAYANAN, N K 
<shan...@research.att.com>; onap-usecase...@lists.onap.org
Cc: onap-disc...@lists.onap.org; onap-tsc <onap-tsc@lists.onap.org>
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: <onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org>> 
on behalf of Parviz Yegani 
<parviz.yeg...@huawei.com<mailto:parviz.yeg...@huawei.com>>
Date: Thursday, May 17, 2018 at 5:38 AM
To: Alla Goldner <alla.gold...@amdocs.com<mailto:alla.gold...@amdocs.com>>, 
"Vladimir Yanover (vyanover)" <vyano...@cisco.com<mailto:vyano...@cisco.com>>, 
Dhananjay Pavgi 
<dp00476...@techmahindra.com<mailto:dp00476...@techmahindra.com>>, 
"SHANKARANARAYANAN, N K" 
<shan...@research.att.com<mailto:shan...@research.att.com>>, 
"onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org>" 
<onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org>>
Cc: onap-discuss 
<onap-disc...@lists.onap.org<mailto:onap-disc...@lists.onap.org>>, onap-tsc 
<onap-tsc@lists.onap.org<mailto:onap-tsc@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: 
“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

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

2018-05-17 Thread TIMONEY, DAN 
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: <onap-tsc-boun...@lists.onap.org> on behalf of Parviz Yegani 
<parviz.yeg...@huawei.com>
Date: Thursday, May 17, 2018 at 5:38 AM
To: Alla Goldner <alla.gold...@amdocs.com>, "Vladimir Yanover (vyanover)" 
<vyano...@cisco.com>, Dhananjay Pavgi <dp00476...@techmahindra.com>, 
"SHANKARANARAYANAN, N K" <shan...@research.att.com>, 
"onap-usecase...@lists.onap.org" <onap-usecase...@lists.onap.org>
Cc: onap-discuss <onap-disc...@lists.onap.org>, onap-tsc 
<onap-tsc@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: 
“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://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.

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

2018-05-17 Thread 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) <vyano...@cisco.com>; Dhananjay Pavgi 
<dp00476...@techmahindra.com>; SHANKARANARAYANAN, N K (N K) 
<shan...@research.att.com>; onap-usecase...@lists.onap.org
Cc: onap-disc...@lists.onap.org; onap-tsc <onap-tsc@lists.onap.org>
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 archit

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

2018-05-17 Thread Stephen Terrill 
orthbound APIs.
  *   Provide a model driven configuration API composed from a Yang-based VNF 
configuration model and set of templates to map payloads to the VNF 
configuration protocol.
 *   Provide configuration repository APIs getLatestConfig, configAudit etc.
  *   Manage the VNF operational state including Blocking, Sequencing and  
Session Throttling
  *   Provide conflict resolution for multiple LCM requests
  *   Provide flexible deployment options such as HA, single node or 
geo-distributed deployment
  *   Adaptation of additional NBI definitions established by ETSI-MANO using 
NFV-O to leverage existing APPC functions, including:
 *   Scale VNF
 *   Terminate VNF
 *   Query VNF
 *   Operate VNF
 *   Modify VNF Information
 *   Get Operation Status
  *   Adaptation of NBI definition at the orchestration level by invoking 
existing orchestrator functions, including:
 *   Create VNF Identifier
 *   Delete VNF Identifier
 *   Instantiate VNF
  *   Build additional DGs to implement new ETSI defined NB APIs not currently 
supported by APPC
 *   Scale VNF to Level
 *   Change VNF Flavour
 *   Heal VNF
  *   Support for GVNFM functionality through additional SB adapters to support:
 *   Bridging to a compliant S-VNFM when this functionality is provided by 
the VNF
 *   Utilize ETSI VNFD acquired from a VNF to define the configuration and 
management data model of the VNF.


---
>From the above, its hard for me to see that the scope of controlling a RAN is 
>in the purview of the SDNC project.  (Hence shouldn't be having Repos for that 
>functionality).  When the SDNR sub-project was raised, I was of the 
>understanding from the December developers conference that its fit was under 
>the SDNC scope of "New Adapters needed to support use cases (details to be 
>determined during planning phase)"

The concept of the a CCSDC based controller persona as being raised a few 
times, and indeed discussed in the architecture committee.  That is quite an 
interesting concept.  When we adopt that, there are a few questions that we 
need to consider:

  *   When adopting that properly in ONAP, then the tool to "create"/"design" 
the controller persona is should be included.  Without that, we are still 
building the controllers in ONAP in a traditional sense, utilizing common 
comonents (which is a good thing).
  *   When adopting that there are a few questions we need to consider: How 
many personas do we want to "create/design" and bring into the integration 
project.  Is the current project structure the right one?

For the sake of progress on Monday I was accepting that we state "controller" 
requirements with the details to be worked out with the architecture 
sub-committee as that is what I understood of the discussion.  This is due to 
that as I haven't seen the motivation for why the SDNC and APPC combination is 
not sufficient.   I don't think that placing this on a new controller or 
extending SDNC to cover VNF controller in general is the correct action at this 
stage.

BR,

Steve




From: onap-usecasesub-boun...@lists.onap.org 
[mailto:onap-usecasesub-boun...@lists.onap.org] On Behalf Of Alla Goldner
Sent: Thursday, May 17, 2018 8:08 AM
To: Vladimir Yanover (vyanover) <vyano...@cisco.com>; Dhananjay Pavgi 
<dp00476...@techmahindra.com>; SHANKARANARAYANAN, N K (N K) 
<shan...@research.att.com>; onap-usecase...@lists.onap.org
Cc: onap-disc...@lists.onap.org; onap-tsc <onap-tsc@lists.onap.org>
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 regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D3EDBF.0D6D26F0]

From: Vladimir Yanover (vyanover) [mailto:vyano...@cisco.com]
Sent: Thursday, May 17, 2018 8:53 AM
To: Alla Goldner <alla.gold...@amdocs.com<mailto:alla.gold...@amdocs.com>>; 
Dhananjay Pavgi 
<dp00476...@techmahindra.com<mailto:dp00476...@techmahindra.com>>; 
SHANKARANARAYANAN, N K (N K) 
<shan...@research.att.com<mailto:shan...@research.att.com>>; 
onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org>
Cc: onap-disc...@lists.onap.org<mailto:onap-disc...@lists.onap.org>; onap-tsc 
<onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>>
Subject: RE: [Onap-usecasesub] [onap-tsc] The summary of Usecase subcommittee 
meeting 14/

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

2018-05-17 Thread Alla Goldner 
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 regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D3EDBE.84CB1FF0]

From: Vladimir Yanover (vyanover) [mailto:vyano...@cisco.com]
Sent: Thursday, May 17, 2018 8:53 AM
To: Alla Goldner <alla.gold...@amdocs.com>; Dhananjay Pavgi 
<dp00476...@techmahindra.com>; SHANKARANARAYANAN, N K (N K) 
<shan...@research.att.com>; onap-usecase...@lists.onap.org
Cc: onap-disc...@lists.onap.org; onap-tsc <onap-tsc@lists.onap.org>
Subject: RE: [Onap-usecasesub] [onap-tsc] The summary of Usecase subcommittee 
meeting 14/05/2017 - Casablanca use cases/functional requirements endorsement

SDN-R is ONF project based on the Microwave Information Model TR-532, which is 
quite distant from what is needed for cellular RAN.
So what we knew as SDN-R in fact never was SDN Radio controller :)
Therefore we are free to keep the name SDN-R or find another good looking name. 
After all, it's just trademark.
I propose SADRAN= SoftwAre Defined RAN.
Thanks
Vladimir




From: 
onap-usecasesub-boun...@lists.onap.org<mailto:onap-usecasesub-boun...@lists.onap.org>
 
<onap-usecasesub-boun...@lists.onap.org<mailto:onap-usecasesub-boun...@lists.onap.org>>
 On Behalf Of Alla Goldner
Sent: Wednesday, May 16, 2018 10:28 PM
To: Dhananjay Pavgi 
<dp00476...@techmahindra.com<mailto:dp00476...@techmahindra.com>>; 
SHANKARANARAYANAN, N K (N K) 
<shan...@research.att.com<mailto:shan...@research.att.com>>; 
onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org>
Cc: onap-disc...@lists.onap.org<mailto:onap-disc...@lists.onap.org>; onap-tsc 
<onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>>
Subject: Re: [Onap-usecasesub] [onap-tsc] The summary of Usecase subcommittee 
meeting 14/05/2017 - Casablanca use cases/functional requirements endorsement

Guys,

All proponents of SDN-R terminology - when I asked during the meeting are there 
any concerns regarding the compromise proposal of saying "SDN-C" and then 
explicitly describing the functionality of this sub-module, there were no 
concerns about it.

One additional sub-compromise :) - can we agree on calling it "SDN-R (SDN-C 
sub-module)"?

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D3EDBE.84CB1FF0]

From: Dhananjay Pavgi [mailto:dp00476...@techmahindra.com]
Sent: Thursday, May 17, 2018 7:07 AM
To: SHANKARANARAYANAN, N K (N K) 
<shan...@research.att.com<mailto:shan...@research.att.com>>; Alla Goldner 
<alla.gold...@amdocs.com<mailto:alla.gold...@amdocs.com>>; 
onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org>
Cc: onap-disc...@lists.onap.org<mailto:onap-disc...@lists.onap.org>; onap-tsc 
<onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>>
Subject: RE: [onap-tsc] [Onap-usecasesub] The summary of Usecase subcommittee 
meeting 14/05/2017 - Casablanca use cases/functional requirements endorsement

Concur with views below from Shankar. Why confuse by changing it to SDN-C when 
we know it's functionality quite "Radio" and wireless domain specific.

thanks & regards,
Dhananjay Pavgi
+91 98220 22264

From: onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org> 
<onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org>> On 
Behalf Of SHANKARANARAYANAN, N K (N K)
Sent: Thursday, May 17, 2018 8:39 AM
To: Alla Goldner <alla.gold...@amdocs.com<mailto:alla.gold...@amdocs.com>>; 
onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org>
Cc: onap-disc...@lists.onap.org<mailto:onap-disc...@lists.onap.org>; onap-tsc 
<onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>>
Subject: Re: [onap-tsc] [Onap-usecasesub] The summary of Usecase subcommittee 
meeting 14/05/2017 - Casablanca use cases/functional requirements endorsement

Alla,

I don't understand the decision to change the SDN-R term after the several 
discussions in the 5G and SDN-R groups
using this term to describe the single ONAP OA controller persona (derived 
from CC-SDK) for mobility and wireless PNF/VNFs.
The reasons were articulated in the discussions. There has been momentum in 
using the SDN-R term, and changing it to SDN-C now causes confusion.

Regards,

Shankar


From: 
onap-usecasesub-boun...@lists.onap.org<mailto:onap-usecasesub-boun...@lists.onap.org>
 [onap-usecasesub-boun...@lists.onap.org] on behalf of All

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

2018-05-16 Thread Vladimir Yanover (vyanover) 
SDN-R is ONF project based on the Microwave Information Model TR-532, which is 
quite distant from what is needed for cellular RAN.
So what we knew as SDN-R in fact never was SDN Radio controller :)
Therefore we are free to keep the name SDN-R or find another good looking name. 
After all, it's just trademark.
I propose SADRAN= SoftwAre Defined RAN.
Thanks
Vladimir



From: onap-usecasesub-boun...@lists.onap.org 
<onap-usecasesub-boun...@lists.onap.org> On Behalf Of Alla Goldner
Sent: Wednesday, May 16, 2018 10:28 PM
To: Dhananjay Pavgi <dp00476...@techmahindra.com>; SHANKARANARAYANAN, N K (N K) 
<shan...@research.att.com>; onap-usecase...@lists.onap.org
Cc: onap-disc...@lists.onap.org; onap-tsc <onap-tsc@lists.onap.org>
Subject: Re: [Onap-usecasesub] [onap-tsc] The summary of Usecase subcommittee 
meeting 14/05/2017 - Casablanca use cases/functional requirements endorsement

Guys,

All proponents of SDN-R terminology - when I asked during the meeting are there 
any concerns regarding the compromise proposal of saying "SDN-C" and then 
explicitly describing the functionality of this sub-module, there were no 
concerns about it.

One additional sub-compromise :) - can we agree on calling it "SDN-R (SDN-C 
sub-module)"?

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D3ED66.740666A0]

From: Dhananjay Pavgi [mailto:dp00476...@techmahindra.com]
Sent: Thursday, May 17, 2018 7:07 AM
To: SHANKARANARAYANAN, N K (N K) 
<shan...@research.att.com<mailto:shan...@research.att.com>>; Alla Goldner 
<alla.gold...@amdocs.com<mailto:alla.gold...@amdocs.com>>; 
onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org>
Cc: onap-disc...@lists.onap.org<mailto:onap-disc...@lists.onap.org>; onap-tsc 
<onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>>
Subject: RE: [onap-tsc] [Onap-usecasesub] The summary of Usecase subcommittee 
meeting 14/05/2017 - Casablanca use cases/functional requirements endorsement

Concur with views below from Shankar. Why confuse by changing it to SDN-C when 
we know it's functionality quite "Radio" and wireless domain specific.

thanks & regards,
Dhananjay Pavgi
+91 98220 22264

From: onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org> 
<onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org>> On 
Behalf Of SHANKARANARAYANAN, N K (N K)
Sent: Thursday, May 17, 2018 8:39 AM
To: Alla Goldner <alla.gold...@amdocs.com<mailto:alla.gold...@amdocs.com>>; 
onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org>
Cc: onap-disc...@lists.onap.org<mailto:onap-disc...@lists.onap.org>; onap-tsc 
<onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>>
Subject: Re: [onap-tsc] [Onap-usecasesub] The summary of Usecase subcommittee 
meeting 14/05/2017 - Casablanca use cases/functional requirements endorsement

Alla,

I don't understand the decision to change the SDN-R term after the several 
discussions in the 5G and SDN-R groups
using this term to describe the single ONAP OA controller persona (derived 
from CC-SDK) for mobility and wireless PNF/VNFs.
The reasons were articulated in the discussions. There has been momentum in 
using the SDN-R term, and changing it to SDN-C now causes confusion.

Regards,

Shankar


From: 
onap-usecasesub-boun...@lists.onap.org<mailto:onap-usecasesub-boun...@lists.onap.org>
 [onap-usecasesub-boun...@lists.onap.org] on behalf of Alla Goldner 
[alla.gold...@amdocs.com]
Sent: Tuesday, May 15, 2018 4:21 AM
To: onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org>
Cc: onap-disc...@lists.onap.org<mailto:onap-disc...@lists.onap.org>; onap-tsc
Subject: [Onap-usecasesub] The summary of Usecase subcommittee meeting 
14/05/2017 - Casablanca use cases/functional requirements endorsement
Hi all,

Here is the summary of our yesterday's meeting.
Thanks to all meeting participants!


1.   We have fully endorsed the following use cases/functional requirements:

a.   OSAM

b.  Auto Scaling out

c.   Consistent representation and identification of a cloud region in ONAP

d.  Edge Automation through ONAP



2.   5G group of functional requirements is endorsed, with the following 
exceptions:

a.   Terminology of SDN-R will be replaced by SDN-C, while it will be 
clarified what is the functionality of the SDN-C sub-module (used to be called 
SDN-R) to cover necessary enhancements

b.  SON and slice optimization topics will be re-discussed till next 
Monday's Usecase subcommittee meeting by all interested parties. There are 
concerns expressed by Cisco (Vladimir Yanover) which require additional 
discussions. We will monitor their progress and see if consensus is achieved or 
this issue needs to be raised and decided by the TSC



3.

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

2018-05-16 Thread Alla Goldner 
Guys,

All proponents of SDN-R terminology - when I asked during the meeting are there 
any concerns regarding the compromise proposal of saying "SDN-C" and then 
explicitly describing the functionality of this sub-module, there were no 
concerns about it.

One additional sub-compromise :) - can we agree on calling it "SDN-R (SDN-C 
sub-module)"?

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D3EDB8.E8F74180]

From: Dhananjay Pavgi [mailto:dp00476...@techmahindra.com]
Sent: Thursday, May 17, 2018 7:07 AM
To: SHANKARANARAYANAN, N K (N K) <shan...@research.att.com>; Alla Goldner 
<alla.gold...@amdocs.com>; onap-usecase...@lists.onap.org
Cc: onap-disc...@lists.onap.org; onap-tsc <onap-tsc@lists.onap.org>
Subject: RE: [onap-tsc] [Onap-usecasesub] The summary of Usecase subcommittee 
meeting 14/05/2017 - Casablanca use cases/functional requirements endorsement

Concur with views below from Shankar. Why confuse by changing it to SDN-C when 
we know it's functionality quite "Radio" and wireless domain specific.

thanks & regards,
Dhananjay Pavgi
+91 98220 22264

From: onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org> 
<onap-tsc-boun...@lists.onap.org<mailto:onap-tsc-boun...@lists.onap.org>> On 
Behalf Of SHANKARANARAYANAN, N K (N K)
Sent: Thursday, May 17, 2018 8:39 AM
To: Alla Goldner <alla.gold...@amdocs.com<mailto:alla.gold...@amdocs.com>>; 
onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org>
Cc: onap-disc...@lists.onap.org<mailto:onap-disc...@lists.onap.org>; onap-tsc 
<onap-tsc@lists.onap.org<mailto:onap-tsc@lists.onap.org>>
Subject: Re: [onap-tsc] [Onap-usecasesub] The summary of Usecase subcommittee 
meeting 14/05/2017 - Casablanca use cases/functional requirements endorsement

Alla,

I don't understand the decision to change the SDN-R term after the several 
discussions in the 5G and SDN-R groups
using this term to describe the single ONAP OA controller persona (derived 
from CC-SDK) for mobility and wireless PNF/VNFs.
The reasons were articulated in the discussions. There has been momentum in 
using the SDN-R term, and changing it to SDN-C now causes confusion.

Regards,

Shankar


From: 
onap-usecasesub-boun...@lists.onap.org<mailto:onap-usecasesub-boun...@lists.onap.org>
 [onap-usecasesub-boun...@lists.onap.org] on behalf of Alla Goldner 
[alla.gold...@amdocs.com]
Sent: Tuesday, May 15, 2018 4:21 AM
To: onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org>
Cc: onap-disc...@lists.onap.org<mailto:onap-disc...@lists.onap.org>; onap-tsc
Subject: [Onap-usecasesub] The summary of Usecase subcommittee meeting 
14/05/2017 - Casablanca use cases/functional requirements endorsement
Hi all,

Here is the summary of our yesterday's meeting.
Thanks to all meeting participants!


1.   We have fully endorsed the following use cases/functional requirements:

a.   OSAM

b.  Auto Scaling out

c.   Consistent representation and identification of a cloud region in ONAP

d.  Edge Automation through ONAP



2.   5G group of functional requirements is endorsed, with the following 
exceptions:

a.   Terminology of SDN-R will be replaced by SDN-C, while it will be 
clarified what is the functionality of the SDN-C sub-module (used to be called 
SDN-R) to cover necessary enhancements

b.  SON and slice optimization topics will be re-discussed till next 
Monday's Usecase subcommittee meeting by all interested parties. There are 
concerns expressed by Cisco (Vladimir Yanover) which require additional 
discussions. We will monitor their progress and see if consensus is achieved or 
this issue needs to be raised and decided by the TSC



3.   Casablanca's HPA and Change Management authors - please upload your 
proposals under 
https://wiki.onap.org/display/DW/Casablanca+use+cases+proposals+for+endorsement<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_Casablanca-2Buse-2Bcases-2Bproposals-2Bfor-2Bendorsement=DwMFAg=LFYZ-o9_HUMeMTSQicvjIg=3F6B_OfdEFaZplwZX72F9ItZySDTzOU-cPey8nzXnHA=0xTbqUdLR-851l7UAd83zDbYq3UV0fmlrYmnbjQLwow=f2cGhvhTgxPybLCBOP_WT5ljK9FymPHnXzRnM6kRavI=>.
 We will discuss them next Monday



4.   Cross Domain and Cross Layer VPN Service was presented for the first 
time yesterday. Some comments were received. Team will update according to the 
comments received and we will continue our discussion next Monday as well. 
Also, the team has asked for additional volunteering companies to participate 
in this development (please approach Lingli and Lin in case of interest)

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D3EDB8.E8F74180]

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs p

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

2018-05-16 Thread Dhananjay Pavgi 
Concur with views below from Shankar. Why confuse by changing it to SDN-C when 
we know it's functionality quite "Radio" and wireless domain specific.

thanks & regards,
Dhananjay Pavgi
+91 98220 22264

From: onap-tsc-boun...@lists.onap.org <onap-tsc-boun...@lists.onap.org> On 
Behalf Of SHANKARANARAYANAN, N K (N K)
Sent: Thursday, May 17, 2018 8:39 AM
To: Alla Goldner <alla.gold...@amdocs.com>; onap-usecase...@lists.onap.org
Cc: onap-disc...@lists.onap.org; onap-tsc <onap-tsc@lists.onap.org>
Subject: Re: [onap-tsc] [Onap-usecasesub] The summary of Usecase subcommittee 
meeting 14/05/2017 - Casablanca use cases/functional requirements endorsement

Alla,

I don't understand the decision to change the SDN-R term after the several 
discussions in the 5G and SDN-R groups
using this term to describe the single ONAP OA controller persona (derived 
from CC-SDK) for mobility and wireless PNF/VNFs.
The reasons were articulated in the discussions. There has been momentum in 
using the SDN-R term, and changing it to SDN-C now causes confusion.

Regards,

Shankar


From: 
onap-usecasesub-boun...@lists.onap.org<mailto:onap-usecasesub-boun...@lists.onap.org>
 [onap-usecasesub-boun...@lists.onap.org] on behalf of Alla Goldner 
[alla.gold...@amdocs.com]
Sent: Tuesday, May 15, 2018 4:21 AM
To: onap-usecase...@lists.onap.org<mailto:onap-usecase...@lists.onap.org>
Cc: onap-disc...@lists.onap.org<mailto:onap-disc...@lists.onap.org>; onap-tsc
Subject: [Onap-usecasesub] The summary of Usecase subcommittee meeting 
14/05/2017 - Casablanca use cases/functional requirements endorsement
Hi all,

Here is the summary of our yesterday's meeting.
Thanks to all meeting participants!


1.   We have fully endorsed the following use cases/functional requirements:

a.   OSAM

b.  Auto Scaling out

c.   Consistent representation and identification of a cloud region in ONAP

d.  Edge Automation through ONAP



2.   5G group of functional requirements is endorsed, with the following 
exceptions:

a.   Terminology of SDN-R will be replaced by SDN-C, while it will be 
clarified what is the functionality of the SDN-C sub-module (used to be called 
SDN-R) to cover necessary enhancements

b.  SON and slice optimization topics will be re-discussed till next 
Monday's Usecase subcommittee meeting by all interested parties. There are 
concerns expressed by Cisco (Vladimir Yanover) which require additional 
discussions. We will monitor their progress and see if consensus is achieved or 
this issue needs to be raised and decided by the TSC



3.   Casablanca's HPA and Change Management authors - please upload your 
proposals under 
https://wiki.onap.org/display/DW/Casablanca+use+cases+proposals+for+endorsement<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_Casablanca-2Buse-2Bcases-2Bproposals-2Bfor-2Bendorsement=DwMFAg=LFYZ-o9_HUMeMTSQicvjIg=3F6B_OfdEFaZplwZX72F9ItZySDTzOU-cPey8nzXnHA=0xTbqUdLR-851l7UAd83zDbYq3UV0fmlrYmnbjQLwow=f2cGhvhTgxPybLCBOP_WT5ljK9FymPHnXzRnM6kRavI=>.
 We will discuss them next Monday



4.   Cross Domain and Cross Layer VPN Service was presented for the first 
time yesterday. Some comments were received. Team will update according to the 
comments received and we will continue our discussion next Monday as well. 
Also, the team has asked for additional volunteering companies to participate 
in this development (please approach Lingli and Lin in case of interest)

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D3EDC2.9180EBE0]

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.com_about_email-2Ddisclaimer=DwMFAg=LFYZ-o9_HUMeMTSQicvjIg=3F6B_OfdEFaZplwZX72F9ItZySDTzOU-cPey8nzXnHA=0xTbqUdLR-851l7UAd83zDbYq3UV0fmlrYmnbjQLwow=XxYSFDToxAXoSTjMATJ9oiE7C1VyCwK7AvEXwLLE-lY=>


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 
<http://www.techmahindra.com/Disclaimer.html> externally 
http://tim.techmahindra.com/tim/disclaimer.html 
<http://tim.techmahindra.com/tim/disclaimer.html> internally within 
TechMahindra.


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

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

2018-05-16 Thread SHANKARANARAYANAN, N K (N K) 
Alla,

I don't understand the decision to change the SDN-R term after the several 
discussions in the 5G and SDN-R groups
using this term to describe the single ONAP OA controller persona (derived 
from CC-SDK) for mobility and wireless PNF/VNFs.
The reasons were articulated in the discussions. There has been momentum in 
using the SDN-R term, and changing it to SDN-C now causes confusion.

Regards,

Shankar


From: onap-usecasesub-boun...@lists.onap.org 
[onap-usecasesub-boun...@lists.onap.org] on behalf of Alla Goldner 
[alla.gold...@amdocs.com]
Sent: Tuesday, May 15, 2018 4:21 AM
To: onap-usecase...@lists.onap.org
Cc: onap-disc...@lists.onap.org; onap-tsc
Subject: [Onap-usecasesub] The summary of Usecase subcommittee meeting 
14/05/2017 - Casablanca use cases/functional requirements endorsement

Hi all,

Here is the summary of our yesterday’s meeting.
Thanks to all meeting participants!


1.   We have fully endorsed the following use cases/functional requirements:

a.   OSAM

b.  Auto Scaling out

c.   Consistent representation and identification of a cloud region in ONAP

d.  Edge Automation through ONAP



2.   5G group of functional requirements is endorsed, with the following 
exceptions:

a.   Terminology of SDN-R will be replaced by SDN-C, while it will be 
clarified what is the functionality of the SDN-C sub-module (used to be called 
SDN-R) to cover necessary enhancements

b.  SON and slice optimization topics will be re-discussed till next 
Monday’s Usecase subcommittee meeting by all interested parties. There are 
concerns expressed by Cisco (Vladimir Yanover) which require additional 
discussions. We will monitor their progress and see if consensus is achieved or 
this issue needs to be raised and decided by the TSC



3.   Casablanca’s HPA and Change Management authors – please upload your 
proposals under 
https://wiki.onap.org/display/DW/Casablanca+use+cases+proposals+for+endorsement.
 We will discuss them next Monday



4.   Cross Domain and Cross Layer VPN Service was presented for the first 
time yesterday. Some comments were received. Team will update according to the 
comments received and we will continue our discussion next Monday as well. 
Also, the team has asked for additional volunteering companies to participate 
in this development (please approach Lingli and Lin in case of interest)

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D3EC3B.04166B00]

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