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-discuss@lists.onap.org; onap-tsc <onap-...@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-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>; onap-tsc <onap-...@lists.onap.org<mailto:onap-...@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-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>; onap-tsc <onap-...@lists.onap.org<mailto:onap-...@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-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>; onap-tsc <onap-...@lists.onap.org<mailto:onap-...@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-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>; onap-tsc <onap-...@lists.onap.org<mailto:onap-...@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-discuss@lists.onap.org<mailto:onap-discuss@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 externally http://tim.techmahindra.com/tim/disclaimer.html 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 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-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
