Hi, Thanks Alla - I would like to elaborate on this. At the end of the release we have to be able to articulate what we are doing and why, otherwise we reduce ONAPs credibility. Part of this is ensuring architectural coherence and the appropriate project structure as part of our governance. There maybe cases where we justify allowing overlap to explore innovative technologies etc, and in such cases we should broadly discuss so that we have a common understanding of why - I haven't seen such justification here; furthermore we are producing a platform that should be applicable for different use cases, and if we have to introduce a new controller for each use case it implies that the existing controllers are insufficient and here we should understand why. This is why I was OK when we said that this would be further discussed in the architecture, however if that is not the case I´ll go more into the details.
>From an architecture perspective. The approved Beijing architecture is here: >https://wiki.onap.org/download/attachments/25431301/ONAP%20Beijing%20Architecture%20TSC%20v2.0.3.pdf?version=1&modificationDate=1521120444000&api=v2 * It has a SDN-C which is stated to configure and maintain the health of L1-3 VNFs/PNfs and network services throughout their lifecycle * It has an APPC to preform the functions to manage the lifecyle of VNFS and their components. (there is a description of what this specifically means) * It has CCSDK The longer term what was discussed as a generic NF controller and SDNC (i.e. consolidating the controllers). Question: what is missing from the APPC / SDNC combination for this to be applied to 5G Use cases? From this description is clear that APPC should be able to configure the RAN VNFs, or do I miss something? -- >From a project perspective, the projects have a scope: SDNC (which the SDNR subproject is subject to) (v6.1): Project Description: The SDN-C project provides a global network controller, built on the Common Controller Framework, which manages, assigns and provisions network resources. As a "global" controller, the SDN-C project is intended to run as one logical instance per enterprise, with potentially multiple geographically diverse virtual machines / docker containers in clusters to provide high availability. The project also will support the ability to invoke other local SDN controllers, including third party SDN controllers Project scope: · The following features are in scope for the SDN-C project for ONAP release 1: · Enhancements to support the ONAP release 1 use cases (vCPE, VoLTE) · Yang models, · Directed graphs · New Adapters needed to support use cases (details to be determined during planning phase) · Support for third party controllers: · Adapter to allow DG to connect to netconf devices (netconf-lite) · High availability (local) · The following features will be defined for the project: · Configuration versioning : ability to roll back the configuration · CLI adaptor : abstraction layer for CLI adaptor · Support for third party controllers: · Adapter layer to interface with downstream controllers · Support for geographically distributed network resources · QoS support APPC: Project Description: The Application Controller (APPC) performs functions to manage the lifecycle of VNFs and their components providing model driven configuration, abstracts cloud/VNF interfaces for repeatable actions, uses vendor agnostic mechanisms (NETCONF, Chef via Chef Server and Ansible) and enables automation. · Model and policy driven application controller with intrinsic VNF management capabilities. · Support of multi vendor system of VNFs with interdependence between them. · Provide uploading capabilities of standard data model which describe the management, configuration and inter-dependencies of the VNF. · APPC model will be based on ONAP TOSCA and Yang containing a dependency model, LCM recipes, configuration templates, policies etc. · APPC provides multi-protocol southbound plugins, including support for NETCONF, Chef via a Chef Server, and Ansible and ability to operate through vendor specific VNFM/EMS via adaptation through a plugin. · APPC provides a VNF configuration repository with the latest working configuration for each managed VNF instance it is responsible for. · Scope: * Support for complex ONAP use cases including vVOLTE (with vEPC) and vCPE * Provide Generic VNF LCM commands for Northbound consumers (SO, Policy, CMO, DCAE, etc.) * The implementation of LCM commands will use an uploaded VNFD TOSCA model to infer an execution protocol and drive workflows * Design-time ability to attach recipes (specified by Directed Graphs, aka DGs) to specific VNF LCM commands, or "Actions" received via the Northbound 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-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@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-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@01D3EDBF.0D6D26F0] 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@01D3EDBF.0D6D26F0] 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
