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 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.onap.org_display_DW_SDN-2DR-2BObjectives&d=DwMFJg&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=-LEJUsMiBktHUgRI6XoLfGuL6Sn9bKvl9-apU4wLVZg&s=L-BwKYegj5ZnwIo2xqFpP4-prckp76k1C7oOjSHh9cI&e=>
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://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.opennetworking.org_display_OTCC_Wireless-2BTransport&d=DwMFJg&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=-LEJUsMiBktHUgRI6XoLfGuL6Sn9bKvl9-apU4wLVZg&s=nNEivuSSPjAeHlhyK8OknTbT88U1fOvP_hEHnzII79w&e=>
 into the ONAP framework.  Beginning in 4Q 2015, the Wireless Transport Project 
within the Open 
Transport<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.opennetworking.org_projects_open-2Dtransport_&d=DwMFJg&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=-LEJUsMiBktHUgRI6XoLfGuL6Sn9bKvl9-apU4wLVZg&s=yOLzYnvwqiSLlNZlJftgyazfMsmeKFGpx7r_M4NSGv4&e=>group
 of the Open Networking Foundation 
(ONF<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.opennetworking.org_&d=DwMFJg&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=-LEJUsMiBktHUgRI6XoLfGuL6Sn9bKvl9-apU4wLVZg&s=XA34K8-hZY6UIocauHxzFMPRqTbi9Mco9IpxPzMAAxQ&e=>)
 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://urldefense.proofpoint.com/v2/url?u=https-3A__3vf60mmveq1g8vzn48q2o71a-2Dwpengine.netdna-2Dssl.com_wp-2Dcontent_uploads_2013_05_TR-2D532-2DMicrowave-2DInformation-2DModel-2DV1.pdf&d=DwMFJg&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=-LEJUsMiBktHUgRI6XoLfGuL6Sn9bKvl9-apU4wLVZg&s=bpmWxB3QRcYUPoq1hKD0KFCCN3-3NoOJXPKv8T-gNlw&e=>,
 the SDN controller is based on 
OpenDaylight<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.opendaylight.org_&d=DwMFJg&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=-LEJUsMiBktHUgRI6XoLfGuL6Sn9bKvl9-apU4wLVZg&s=TCidGamdoMtVRPdLqBWAyiz6AbnCWThQ1Dao5Qx_4eI&e=>,
 and the software code for the controller is available at an open source github 
repository<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_OpenNetworkingFoundation_CENTENNIAL&d=DwMFJg&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=-LEJUsMiBktHUgRI6XoLfGuL6Sn9bKvl9-apU4wLVZg&s=miGeT52_xbjo6BO5l-sHvqZ_KFoTWM43cOPsFt8YUaI&e=>.
  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<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_download_attachments_20087400_SDN-2DR-5Fproposal-5Fv6.docx-3Fapi-3Dv2&d=DwMFJg&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=-LEJUsMiBktHUgRI6XoLfGuL6Sn9bKvl9-apU4wLVZg&s=nRGE6UCXs08jbU0h-3aDT4dvm6kdApiyO6YrrFPvHHI&e=>

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>
 [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<mailto:vyano...@cisco.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/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@01D3ED71.101BC8A0]

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/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@01D3ED71.101BC8A0]

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&M 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&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=3F6B_OfdEFaZplwZX72F9ItZySDTzOU-cPey8nzXnHA&m=0xTbqUdLR-851l7UAd83zDbYq3UV0fmlrYmnbjQLwow&s=f2cGhvhTgxPybLCBOP_WT5ljK9FymPHnXzRnM6kRavI&e=>.
 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@01D3ED71.101BC8A0]

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&d=DwMFAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=3F6B_OfdEFaZplwZX72F9ItZySDTzOU-cPey8nzXnHA&m=0xTbqUdLR-851l7UAd83zDbYq3UV0fmlrYmnbjQLwow&s=XxYSFDToxAXoSTjMATJ9oiE7C1VyCwK7AvEXwLLE-lY&e=>
============================================================================================================================
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<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.techmahindra.com_Disclaimer.html&d=DwMFJg&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=-LEJUsMiBktHUgRI6XoLfGuL6Sn9bKvl9-apU4wLVZg&s=sE_qqdHGKFn4vVmLosTsnr_KqKXEVQAYwFCBuCWenjQ&e=>
 externally 
http://tim.techmahindra.com/tim/disclaimer.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__tim.techmahindra.com_tim_disclaimer.html&d=DwMFJg&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=-LEJUsMiBktHUgRI6XoLfGuL6Sn9bKvl9-apU4wLVZg&s=hf_TiOw4ERebU11Qbl-B3z3WkPbG8ZdVZ_4WBi1M6Rk&e=>
 internally within TechMahindra.
============================================================================================================================
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&d=DwMFJg&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=-LEJUsMiBktHUgRI6XoLfGuL6Sn9bKvl9-apU4wLVZg&s=vm0ug0xDJ7ddFS3tnBCUt5GDvBNi9jeCaHyE61wqqBI&e=>
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&d=DwMFJg&c=LFYZ-o9_HUMeMTSQicvjIg&r=qLcfee4a2vOwYSub0bljcQ&m=-LEJUsMiBktHUgRI6XoLfGuL6Sn9bKvl9-apU4wLVZg&s=vm0ug0xDJ7ddFS3tnBCUt5GDvBNi9jeCaHyE61wqqBI&e=>
_______________________________________________
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Reply via email to