Vladimir,

As of now, the expectation is that all categories of parameters would be supported by the ONAP controller derived from CC-SDK for Mobility Wireless.

We have dubbed this controller “SDN-R,” as you know, because this particular label has meaning (traction, actually) within both ONAP and ONF.

SDN-R = SDN-C + APP-C for Mobility Wireless, in other words.

What we do not yet know is what will be configured via Netconf/YANG versus what will be configured via Ansible, but I believe the community will have this question answered fairly early within the Casblanca release timeframe.

Tracy

Tracy, Steve and Vimal

I have to admit that I am confused as well and need your help.

Which categories of parameters will be supported by the SDN-R?

Which categories of “the parameters needed for DU & CUs” cannot be supported by the SDN-R (why?) and will be supported by the APP-C?

Thanks

Vladimir

Whatever we elect to call it, “SDN-R” in Casablanca is evolving to include all (or most) logic + features/functionality derived from CC-SDK, whether considered “SDN-C” or “APP-C.”  This will include Ansible and Chef interfaces as well as the additional parameters that may be defined/documented within ONAP or within a related open source project.

Refer to the “ONAP OAM Controller” slides on SDN-R wiki page (https://wiki.onap.org/display/DW/SDN-R+Documents) that were reviewed with you and with others last month.

The seed code is already packaged and will be uploaded to the repository as soon as it becomes available.

***Security Advisory: This Message Originated Outside of AT&T ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.

Steve,

  We have a SDN-C sub-project called SND-R, that focuses on radio configuration using NetConf Yang, but it did not cover all the parameters needed for DU & CUs (and UPF) and need support Ansible.  We also realized that all mobility network elements should be managed by the same controllers (as we might combine CU-UP, a RAN element, with UPF, a core elements).  Hence, we need some of the capabilities from SDN-C  and some from App-C.  Therefore, we decided this controller persona should be created from CCSDK, taking required modules from SDN-C and App-C (we can give a short presentation either during 5G Use case call or use case subcommittee call).  This could be a starting point for generic NF 4-7 Controller.

Hope that helps.

Regards,

Vimal

Hi Alla, All,

I had one question for clarification – in the 5G use case work there is the statement “Support full application level configuration (+ansible), allow various mobile network elements to be controlled from the same controller persona created from CC-SDK”

Today in the architecture we have the APP-C, VFC and SDNC.  I was wondering whether there was clarification on how the statement relates to the existing controllers, and the motivation for the “same” controller”.

BR,

Steve.

Hi all,

Thanks to all meeting attendants!

Here is the summary:

1. We reviewed Edge automation presentation by Ramki and, specifically, what is planned for Casablanca

2. We reviewed EUAG feedback (Vodafone, Verizon, AT&T, Bell, Orange) regarding their priorities for Casablanca. I put those requirements under https://wiki.onap.org/display/DW/Casablanca+goals . The bottom line is that platform quality seem to be significantly more important that functional enrichment of the platform at this point, still.

a. This information, along with E2E use cases proposals will serve as input for TSC decision on the E2E use cases approval (May 10^th)

Our next meeting will be dedicated to review of E2E use cases before bringing them for TSC approval next week.

Best regards,

Alla Goldner

Open Network Division

Amdocs Technology