Merge "New Feature Request: CLI for SO"
diff --git a/Release2/NS_scaling.md b/Release2/NS_scaling.md
new file mode 100644
index 0000000..4b09a76
--- /dev/null
+++ b/Release2/NS_scaling.md
@@ -0,0 +1,41 @@
+# NS Scaling #
+
+## Proposer ##
+- Gerardo Garcia (Telefonica)
+
+## Type ##
+**Feature**
+
+## Target MDG/TF ##
+UI, SO, RO, VCA
+
+## Description ##
+This feature captures the need of NS scaling use case, as discussed in
+different TSC+MDL calls. The description below is a first idea to be
+elaborated and discussed further.
+
+A NS will have defined, as part of the descriptor, different ordered scale
+steps, starting from number 1. For each step different groups of VNFs and VLDs
+will be required.
+
+For simplicity, the feature will assume that the trigger will be manual by
+the network operator, using the UI. The trigger will specify to which scale step
+the NS will move.
+
+The action will reach the SO, which will identify the incremental additions
+required in the RO and in the VCA. First, the actions to be done in the RO will be
+executed, and later, the ones in the VCA.
+
+Rollback mechanisms should be implemented E2E accross mechanisms.
+
+Regarding the interaction between SO and RO, the following mechanism is proposed:
+- The SO will turn scaling-up of a single NS events into new RO Network Scenarios
+and will orchestrate them in RO.
+- The SO will turn scaling-down events into Network Scenario terminations in RO.
+- The SO will keep control of the different RO Network Scenarios that belong to
+a NS in the SO.
+
+## Demo or definition of done ##
+N/A
+
+
diff --git a/Release2/composer_ref_list.md b/Release2/composer_ref_list.md
new file mode 100644
index 0000000..b1df25d
--- /dev/null
+++ b/Release2/composer_ref_list.md
@@ -0,0 +1,29 @@
+# Composer Reference Lists #
+
+## Proposer ##
+- Rajesh Velandy
+
+
+## Type ##
+**Feature**
+
+## Target MDG/TF ##
+UI, SO
+
+## Description ##
+
+NSD and VNFD have many cross-references, For example,
+ - NSD has constituent VNFD id references
+ - VLD has VNFD connection point references
+
+Composer presents references as inputs, forcing the user to copy/paste id references.
+
+Composer should present these references as dropdown lists.
+
+Reference lists should update dynamically in composer as the model is modified.
+
+The types on some model attributes need to be changed from string to leafref in the model.
+
+
+## Demo or definition of done ##
+Demonstrate the resolution of leafrefs in the GUI.
diff --git a/Release2/euag_deployment_of_OSM_in_reduced_environments.md b/Release2/euag_deployment_of_OSM_in_reduced_environments.md
new file mode 100644
index 0000000..1b7947f
--- /dev/null
+++ b/Release2/euag_deployment_of_OSM_in_reduced_environments.md
@@ -0,0 +1,31 @@
+# Deployment of OSM in reduced environments #
+
+## Proposer ##
+**EUAG**
+
+## Type ##
+**Feature**
+
+## Target MDG/TF ##
+UI, SO, RO, VCA
+
+## Description ##
+Currently OSM requires 8 CPUs and 16GB RAM to run. This makes really complicated
+for observers and initial testers to use OSM for the first time. Being able to
+run OSM in a reduced environment with less required resources would ease the
+first time use.
+
+As a reference, the target should be 2CPUs and 4GB RAM for running the whole OSM
+(RO, VCA, SO, UI). In that way, OSM could run in a laptop or in a Virtualbox VM
+without problems.
+
+In addition, in order to test the deployment of the NS, it would be required to
+run a VIM and compute nodes in a reduced setup. The use of LXD containers as
+compute nodes fits well with this idea. A single host with LXD containers and
+Linux bridges could be used as datacenter for this testing purpose, being able
+to deploy simple NS on that single host. The reference target of CPU and memory
+resources for this single host running LXD containers could be 2CPUs and 4 GB
+RAM.
+
+## Demo or definition of done ##
+N/A
diff --git a/Release2/euag_interoperability_with_public_clouds.md b/Release2/euag_interoperability_with_public_clouds.md
new file mode 100644
index 0000000..f048c41
--- /dev/null
+++ b/Release2/euag_interoperability_with_public_clouds.md
@@ -0,0 +1,26 @@
+# Interoperability with public clouds #
+
+## Proposer ##
+**EUAG**
+
+## Type ##
+**Feature**
+
+## Target MDG/TF ##
+RO
+
+## Description ##
+Currently OSM can deploy VNFs in sites controlled by VIMs of the following
+types: Openstack, Openvim and VMware vCloud Director. In practice, this is
+forcing the user to have access to a VIM of one of those types, which might not
+be simple for a general user that just wants to test OSM.
+
+Being able to interact with public clouds such as AWS and Google Cloud would
+allow a general user to test OSM without the need to deploy a VIM. Moreover,
+those public clouds could be part of multi-site deployments in production.
+
+In practice, this feature would require interacting with AWS APIs and Google
+Cloud APIs as a minimum, in a similar way as it is done with other VIMs.
+
+## Demo or definition of done ##
+N/A
diff --git a/Release2/openvim_logs_and_exception_handling_following_OSM_framework.md b/Release2/openvim_logs_and_exception_handling_following_OSM_framework.md
new file mode 100644
index 0000000..b94fccc
--- /dev/null
+++ b/Release2/openvim_logs_and_exception_handling_following_OSM_framework.md
@@ -0,0 +1,20 @@
+# Adoption in openvim of OSM framework for logging and exception handling #
+
+## Proposer ##
+- Alfonso Tierno (Telefonica)
+- Gerardo Garcia (Telefonica)
+
+## Type ##
+**Feature**
+
+## Target MDG/TF ##
+RO
+
+## Description ##
+OpenVIM was recently incorporated into OSM and still has some discrepancies with respect to the
+common agreed framework for logging and exception handling. This featureproposes adopting the model
+agreed in OSM for logging and exception handling.
+
+## Demo or definition of done ##
+N/A
+
diff --git a/Release2/ovs_in_openvim.md b/Release2/ovs_in_openvim.md
new file mode 100644
index 0000000..4767a61
--- /dev/null
+++ b/Release2/ovs_in_openvim.md
@@ -0,0 +1,33 @@
+# Overlay network connectivity in Openvim with OVS instead of Linux Bridges #
+
+## Proposer ##
+- Alfonso Tierno (Telefonica)
+- Gerardo Garcia (Telefonica)
+
+## Type ##
+**Feature**
+
+## Target MDG/TF ##
+RO
+
+## Description ##
+OpenVIM currently uses pre-provisioned Linux bridges to create the overlay
+networks used to interconnect the VMs. Those Linux bridges are built on a host
+interface and are associated with a VLAN tag, which is used to transport frames
+between VMs located in different hosts across a switching infrastructure.
+
+Linux bridges, while working well in practice, have limitations (e.g. VLAN as
+the only mechanism for achieving isolation). It also lacks some advanced
+capabilities (L3 filtering, IP tunneling, support of Openflow rules, etc.).
+
+Open vSwitch (OVS) (http://www.openvswitch.org/) provides those advanced
+capabilities and would be better aligned with future OSM needs and use cases.
+
+This feature proposes the support of OVS in openvim as an alternative to Linux
+Bridges. Openvim installer and configuration files should provide options to
+use either Linux Bridges or OVS. Scripts for automatic configuration of hosts
+should also provide that option.
+
+
+## Demo or definition of done ##
+N/A
diff --git a/Release2/package_management.md b/Release2/package_management.md
new file mode 100644
index 0000000..c485a09
--- /dev/null
+++ b/Release2/package_management.md
@@ -0,0 +1,26 @@
+# Package Management #
+
+## Proposer ##
+- Rajesh Velandy
+
+
+## Type ##
+**Feature**
+
+## Target MDG/TF ##
+SO, UI
+
+## Description ##
+
+The package management functionality will be add the ability to do full package management
+capabilities through the composer UI.
+Specifically the UI composer will support the following capabilities in addition to the existing
+gui based composition,
+# Creation of VNF/NS Packages
+# CRUD operations on the various files within the package
+# Export of VNF/NS packages.
+
+## Demo or definition of done ##
+Using the UI demonstrate the capability to create descriptors and VNF packages with additional
+artifacsts(icons, charms etc ...)
+
diff --git a/Release2/unfiltered_virtual_interfaces_in_VNFs.md b/Release2/unfiltered_virtual_interfaces_in_VNFs.md
new file mode 100644
index 0000000..b92866c
--- /dev/null
+++ b/Release2/unfiltered_virtual_interfaces_in_VNFs.md
@@ -0,0 +1,36 @@
+# Unfiltered virtual interfaces in VNFs #
+
+## Proposer ##
+- Gerardo Garcia (Telefonica)
+- Alfonso Tierno (Telefonica)
+- Francisco Javier Ramon (Telefonica)
+
+## Type ##
+**Feature**
+
+## Target MDG/TF ##
+UI, SO, RO
+
+## Description ##
+When VLDs are created as overlay networks on an NFVI, some VIMs like Openstack
+implement some security policies that apply L2-L4 filtering rules to the frames
+in those networks. By default, when creating VLDs (networks in VIMs) and when
+attaching VDUs to the VLDs (attaching a VM to a network in a VIM), those
+security policies are created in the VIM.
+
+Those security policies (e.g. port security in Openstack) can be disabled at a
+network level or at port level in the VIM. However, this ability to disable those
+security policies has not been implemented as an end-to-end option in OSM.
+
+This feature proposes the addition of a parameter to enable or disable that port
+security per VDU/VM interface. This will affect the data model for the VDU
+managed by the SO, will affect the UI, which should offer the option to enable or
+disable it, and will affect the RO, which should specify that capability down to
+the VIMs that support it.
+
+## Demo or definition of done ##
+An end-to-end use case is required, where the user creates a VNF in the UI and
+disables the filtering policy on a VM interface. Once the VNF is instantiated as
+part of a NS instance, it should be checked in the VIM that the filtering policy
+has been disabled in that interface/port, while in the network should be enabled.
+
diff --git a/Release2/vnf_multi_disk.md b/Release2/vnf_multi_disk.md
new file mode 100644
index 0000000..f25591b
--- /dev/null
+++ b/Release2/vnf_multi_disk.md
@@ -0,0 +1,23 @@
+# VNF Multi-Disk Support #
+
+## Proposer ##
+- Rajesh Velandy
+
+
+## Type ##
+**Feature**
+
+## Target MDG/TF ##
+SO, RO
+
+## Description ##
+
+Add support for multiple volumes associated with a VDU.
+The volume sources can be,
+ - ephermal empty disk
+ - new volume based on existing cloud image
+ - Reference to pre-existing volume in VIM
+
+
+## Demo or definition of done ##
+Demonstrate the ability on on-board and instantiate a VNF with multiple disks.