Re: [onap-tsc] Kenny, please move Usecase subcommittee meeting from MOnday to Tuesday next week, the same timeslot

[Alla Goldner]

Kenny,

I sent 5 requests since last Tuesday to reschedule this meeting next week. As 
you've mentioned there are no guaranteed slots on Wednesday, I suggested to 
reschedule for Tuesday next week 4 pm CET, as Architecture subcommittee meeting 
is cancelled, and use their bridge.

Please reschedule. Lack of rescheduling creates a LOT of confusion and people 
approach me asking if/when this meeting will happen next week.

TEAM - as discussed this week, we will cover remaining functional requirements 
(Change Management and HPA) proposals for Casablanca as well as go back to 
controversial issues related to 5G and review progress made for Cross Domain 
and Cross layer VPN service.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D3EE7D.03451CA0]

From: Alla Goldner
Sent: Thursday, May 17, 2018 5:15 PM
To: 'Kenny Paul' 
Cc: onap-usecase...@lists.onap.org
Subject: Kenny, please move Usecase subcommittee meeting from MOnday to Tuesday 
next week, the same timeslot

We can use arch subcommittee bridge, their meeting is cancelled next week

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D3EE7D.03451CA0]

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-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

[onap-tsc] TSC Decision to postpone Beijing Release Sign-Off by 2 weeks

[Gildas Lanilis]

Hi All,

This email is to communicate the decision the TSC has taken to postpone the 
Sign-Off of Beijing Release by 2 weeks.
The new dates becomes:

  1.  RC2: Thursday, May 31, 2018
  2.  Sign-Off: Thursday, June 7, 2018
This decision will allow the community to complete the tasks related to 
Integration testing and bugs fixing on the following scope:

1.   S3P (Stability, Security, Resiliency) + vCPE + VoLTE

2.   Supporting both OOM and HEAT deployment
The Functional Requirements (HPA, CM, Manual Scaling Out) remain a stretch goal 
for Beijing Release.
The vote decision is documented in IRC 
Log
 (Topic Integration, section am).
The Beijing Release 
Calendar
 has been updated accordingly.
Materials presented at TSC are posted in wiki 
here
 and 
here.
Let me know if you have any question, I will be glad to help.
Thanks,
Gildas

[HuaweiLogowithName]
Gildas Lanilis
ONAP Release Manager
Santa Clara CA, USA
gildas.lani...@huawei.com
Mobile: 1 415 238 6287

___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] ONAP TSC Survey Results

[Kenny Paul]

Hi Frank,

 

Yes, the poll only went to the current TSC members. 

I'll incorporate this into today's discussion.

 

Thanks!

-kenny

 

From: "Frank Brockners (fbrockne)" 
Date: Thursday, May 17, 2018 at 6:45 AM
To: Kenny Paul , onap-tsc 
Subject: RE: ONAP TSC Survey Results

 

Thanks Kenny. Who did the poll go to? It seems that it was just the current TSC.

 

While the current TSC will be the one deciding (read: voting), it would have 
been nice to get the temperature and opinion of the overall community (“all 
active members”), because ultimately the TSC should represent the community. 
Would it be feasible to extend the poll to all active ONAP members?

 

Thanks, Frank

 

From: onap-tsc-boun...@lists.onap.org  On 
Behalf Of Kenny Paul
Sent: Donnerstag, 17. Mai 2018 02:43
To: onap-tsc 
Subject: [onap-tsc] ONAP TSC Survey Results

 

 

 

Best Regards, 
-kenny

Kenny Paul, Technical Program Manager, The Linux Foundation
kp...@linuxfoundation.org, 510.766.5945
San Francisco Bay Area, Pacific Time Zone

 

 

___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] [Onap-usecasesub] The summary of Usecase subcommittee meeting 14/05/2017 - Casablanca use cases/functional requirements endorsement

[Martin Skorupski]

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 ; Alla Goldner 
; Vladimir Yanover (vyanover) ; 
Dhananjay Pavgi ; SHANKARANARAYANAN, N K 
; onap-usecase...@lists.onap.org
Cc: onap-disc...@lists.onap.org; onap-tsc 
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 
  for D2 
ECOMP Project In-take, 2016 Release Planning, Change Management, and find key 
Release Planning Contact Information.

 

 

From:  
> on behalf of Parviz Yegani  >
Date: Thursday, May 17, 2018 at 5:38 AM
To: Alla Goldner  >, 
"Vladimir Yanover (vyanover)"  
>, Dhananjay Pavgi  >, "SHANKARANARAYANAN, N K" 
 >, 
"onap-usecase...@lists.onap.org  " 
 >
Cc: onap-discuss  >, onap-tsc  >
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 

Re: [onap-tsc] ONAP TSC Survey Results

[Frank Brockners (fbrockne)]

Thanks Kenny. Who did the poll go to? It seems that it was just the current TSC.

While the current TSC will be the one deciding (read: voting), it would have 
been nice to get the temperature and opinion of the overall community (“all 
active members”), because ultimately the TSC should represent the community. 
Would it be feasible to extend the poll to all active ONAP members?

Thanks, Frank

From: onap-tsc-boun...@lists.onap.org  On 
Behalf Of Kenny Paul
Sent: Donnerstag, 17. Mai 2018 02:43
To: onap-tsc 
Subject: [onap-tsc] ONAP TSC Survey Results



Best Regards,
-kenny

Kenny Paul, Technical Program Manager, The Linux Foundation
kp...@linuxfoundation.org, 510.766.5945
San Francisco Bay Area, Pacific Time Zone


___
ONAP-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] [Onap-usecasesub] The summary of Usecase subcommittee meeting 14/05/2017 - Casablanca use cases/functional requirements endorsement

[Stephen Terrill]

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 ; Alla Goldner 
; Vladimir Yanover (vyanover) ; 
Dhananjay Pavgi ; SHANKARANARAYANAN, N K 
; onap-usecase...@lists.onap.org
Cc: onap-disc...@lists.onap.org; onap-tsc 
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 for 
D2 ECOMP Project In-take, 2016 Release Planning, Change Management, and find 
key Release Planning Contact Information.


From: > 
on behalf of Parviz Yegani 
>
Date: Thursday, May 17, 2018 at 5:38 AM
To: Alla Goldner >, 
"Vladimir Yanover (vyanover)" >, 
Dhananjay Pavgi 
>, 
"SHANKARANARAYANAN, N K" 
>, 
"onap-usecase...@lists.onap.org" 
>
Cc: onap-discuss 
>, onap-tsc 
>
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 

Re: [onap-tsc] ONAP TSC Survey Results

[Alla Goldner]

Hi Kenny,

Thanks for your response.

@your first point: I have difficulty accepting this as is. The reason is that 
similar suggestions of granting a seat were also brought for another positions 
(not only for Release Manager) in the past, but somehow this whole topic was 
not included into the Survey. If we want to grant a seat for any position 
holder, we need to take it by a separate Survey, probably, will not have any 
issues with that

@you second point – assuming the data will be shared once we agree on 
structure, I am fine with it

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image002.png@01D3EDF8.6C0733C0]

From: Kenny Paul [mailto:kp...@linuxfoundation.org]
Sent: Thursday, May 17, 2018 3:47 PM
To: Alla Goldner ; onap-tsc 
Subject: Re: ONAP TSC Survey Results

Hi Alla,

The topic of having the Release Manage as part of the TSC has been brought up 
previously although it was not included in the survey. I added it as a 
recommendation because it is the appropriate given both the importance of a 
Release Manager to the health of the Community and the level of engagement 
required by that position.

As far as the "When" goes, as was agreed at the TSC meeting a couple weeks back 
that discussion does not happen until the TSC composition is settled. I'm not 
sharing that data until the first order of business is addressed.

Thanks!
-kenny

From: Alla Goldner >
Date: Wednesday, May 16, 2018 at 10:03 PM
To: Kenny Paul >, 
onap-tsc >
Subject: RE: ONAP TSC Survey Results

Hi Kenny,

Thanks a lot for sharing this!

I have 2 related questions:


  1.  I see one proposal for exception “*Make the job role of “Release 
Manager”, which is an elected position, a TSC seat”. Have we ever discussed 
this? I don’t remember this being part of the survey
  2.  If I remember correctly, there were also questions related to timing of 
elections – e.g. now, after Casablanca etc. I don’t see this reflected in the 
survey results.

Best regards,

Alla Goldner

Open Network Division
Amdocs Technology


[cid:image001.png@01D3EDB5.8B253010]

From: onap-tsc-boun...@lists.onap.org 
[mailto:onap-tsc-boun...@lists.onap.org] On Behalf Of Kenny Paul
Sent: Thursday, May 17, 2018 3:43 AM
To: onap-tsc >
Subject: [onap-tsc] ONAP TSC Survey Results



Best Regards,
-kenny

Kenny Paul, Technical Program Manager, The Linux Foundation
kp...@linuxfoundation.org, 510.766.5945
San Francisco Bay Area, Pacific Time Zone


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-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] [Onap-usecasesub] The summary of Usecase subcommittee meeting 14/05/2017 - Casablanca use cases/functional requirements endorsement

[TIMONEY, DAN]

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 for 
D2 ECOMP Project In-take, 2016 Release Planning, Change Management, and find 
key Release Planning Contact Information.


From:  on behalf of Parviz Yegani 

Date: Thursday, May 17, 2018 at 5:38 AM
To: Alla Goldner , "Vladimir Yanover (vyanover)" 
, Dhananjay Pavgi , 
"SHANKARANARAYANAN, N K" , 
"onap-usecase...@lists.onap.org" 
Cc: onap-discuss , onap-tsc 

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 

Re: [onap-tsc] ONAP TSC Survey Results

[Kenny Paul]

Hi Alla,

 

The topic of having the Release Manage as part of the TSC has been brought up 
previously although it was not included in the survey. I added it as a 
recommendation because it is the appropriate given both the importance of a 
Release Manager to the health of the Community and the level of engagement 
required by that position.

 

As far as the "When" goes, as was agreed at the TSC meeting a couple weeks back 
that discussion does not happen until the TSC composition is settled. I'm not 
sharing that data until the first order of business is addressed.

 

Thanks!

-kenny

 

From: Alla Goldner 
Date: Wednesday, May 16, 2018 at 10:03 PM
To: Kenny Paul , onap-tsc 
Subject: RE: ONAP TSC Survey Results

 

Hi Kenny,

 

Thanks a lot for sharing this!

 

I have 2 related questions:

 
I see one proposal for exception “*Make the job role of “Release Manager”, 
which is an elected position, a TSC seat”. Have we ever discussed this? I don’t 
remember this being part of the survey
If I remember correctly, there were also questions related to timing of 
elections – e.g. now, after Casablanca etc. I don’t see this reflected in the 
survey results.
 

Best regards, 

 

Alla Goldner

 

Open Network Division 

Amdocs Technology

 

 

 

From: onap-tsc-boun...@lists.onap.org [mailto:onap-tsc-boun...@lists.onap.org] 
On Behalf Of Kenny Paul
Sent: Thursday, May 17, 2018 3:43 AM
To: onap-tsc 
Subject: [onap-tsc] ONAP TSC Survey Results

 

 

 

Best Regards, 
-kenny

Kenny Paul, Technical Program Manager, The Linux Foundation
kp...@linuxfoundation.org, 510.766.5945
San Francisco Bay Area, Pacific Time Zone

 

 

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-TSC mailing list
ONAP-TSC@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-tsc

Re: [onap-tsc] [Onap-usecasesub] The summary of Usecase subcommittee meeting 14/05/2017 - Casablanca use cases/functional requirements endorsement

[Parviz Yegani]

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
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 into 
the ONAP framework.  Beginning in 4Q 2015, the Wireless Transport Project 
within the Open 
Transportgroup of the 
Open Networking Foundation (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 
TR-532,
 the SDN controller is based on OpenDaylight, 
and the software code for the controller is available at an 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://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



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) ; Dhananjay Pavgi 
; SHANKARANARAYANAN, N K (N K) 
; onap-usecase...@lists.onap.org
Cc: onap-disc...@lists.onap.org; onap-tsc 
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 

Re: [onap-tsc] [Onap-usecasesub] The summary of Usecase subcommittee meeting 14/05/2017 - Casablanca use cases/functional requirements endorsement

[Stephen Terrill]

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=1521120444000=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 

Re: [onap-tsc] [Onap-usecasesub] The summary of Usecase subcommittee meeting 14/05/2017 - Casablanca use cases/functional requirements endorsement

[Alla Goldner]

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@01D3EDBE.84CB1FF0]

From: Vladimir Yanover (vyanover) [mailto:vyano...@cisco.com]
Sent: Thursday, May 17, 2018 8:53 AM
To: Alla Goldner ; Dhananjay Pavgi 
; SHANKARANARAYANAN, N K (N K) 
; onap-usecase...@lists.onap.org
Cc: onap-disc...@lists.onap.org; onap-tsc 
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
 
>
 On Behalf Of Alla Goldner
Sent: Wednesday, May 16, 2018 10:28 PM
To: Dhananjay Pavgi 
>; 
SHANKARANARAYANAN, N K (N K) 
>; 
onap-usecase...@lists.onap.org
Cc: onap-disc...@lists.onap.org; onap-tsc 
>
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@01D3EDBE.84CB1FF0]

From: Dhananjay Pavgi [mailto:dp00476...@techmahindra.com]
Sent: Thursday, May 17, 2018 7:07 AM
To: SHANKARANARAYANAN, N K (N K) 
>; Alla Goldner 
>; 
onap-usecase...@lists.onap.org
Cc: onap-disc...@lists.onap.org; onap-tsc 
>
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 
> On 
Behalf Of SHANKARANARAYANAN, N K (N K)
Sent: Thursday, May 17, 2018 8:39 AM
To: Alla Goldner >; 
onap-usecase...@lists.onap.org
Cc: onap-disc...@lists.onap.org; onap-tsc 
>
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 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
 [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
Cc: onap-disc...@lists.onap.org; onap-tsc
Subject: