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 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? <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=> 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 <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=> ONF Wireless Transport project into the ONAP framework. Beginning in 4Q 2015, the Wireless Transport Project within the <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=> Open Transportgroup of the Open Networking Foundation ( <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=> ONF) 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 <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=> TR-532, the SDN controller is based on <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=> OpenDaylight, and the software code for the controller is available at an <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=> open source github repository. 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://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=> 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 <mailto:parviz.yeg...@huawei.com> 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 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 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 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
