--- /dev/null
+# Support of Physical Deployment Units in a VNF #
+
+## Proposer ##
+- Gerardo Garcia (Telefonica)
+- Alfonso Tierno (Telefonica)
+- Francisco Javier Ramon (Telefonica)
+
+## Type ##
+**Feature**
+
+## Target MDG/TF ##
+SO, RO
+
+## Description ##
+**This feature obsoletes feature #641: https://osm.etsi.org/gerrit/#/c/641/**
+
+This feature aims to enable the use of Network Functions where some of their
+Deployment Units are physical (Physical Deployment Units - PDUs), so both pure
+VNFs, pure PNFs and hybrid network functions can be seamlessly supported in an
+interchangeable manner in a NS.
+
+This feature is also expected to require a specific procedure to add PDUs to a
+catalog per datacenter, where details of their type (so that they can be
+pooled. e.g. GPU model), location (datacenter), reachability (e.g. IP
+address), physical connections to the site (e.g. switches and ports where the
+PDU is connected), etc. can be provided.
+
+In this phase, it will be assumed that, on time of instantiation, these PDUs
+would map 1-to-1 to VDU instances (or equivalent). In this phase, the same PDU
+cannot be used twice (in the future we might review this approach).
+
+## Demo or definition of done ##
+- Successful onboarding of a (V)NF that has 1 VDU and 1 PDU. For instance, in
+the (V)NF, the VDU could be an SDN controller and the PDU a small physical
+switch.
+- Addition a PDUs in datacenter A of a given type.
+- Successful deployment of a NS with the (V)NF in datacenter A.
+- Unsuccessful deployment of a second instance of the same NS in the datacenter
+A (not enough resources available of that PDU type).
+- Unsuccessful deployment of the same NS in another datacenter (no PDUs of that
+type available).
\ No newline at end of file
--- /dev/null
+# Fault and Performance Management of OSM Modules #
+
+## Proposer ##
+Jose Manuel Palacios (Minsait)
+Alexis Romero (Minsait)
+
+## Type ##
+**Feature**
+
+## Target MDG/TF ##
+**DevOps**,
+**Service Assurance**
+
+## Description ##
+Currently, OSM provides mechanisms for the Fault and Performance monitoring of the deployed Network Functions, by retrieving metrics from the VIM and directly from the VNFs. The monitoring of the OSM modules is done via the optional ELK stack that retrieves some metrics that are not OSM specific, but common to any kind of software, such as CPU and memory usage. Logs may also collected and stored in the ELK stack, but those are mostly unstructured and it is difficult to distill useful information using them.
+
+In a production environment is crucial to have information about the health status and performance of the OSM modules. For that purpose those should be properly instrumented, exporting the relevant metrics.
+
+There are several reasonable choices for the instrumentation mechanism, the venerable SNMP still being the default option in telco environments. Nevertheless, since OSM already includes a Prometheus module as the repository for VNF metrics, it makes sense to leverage it also for this function.
+
+The implementation would involve:
+
+- Adding functionality to each one of the OSM modules so that it natively exports Prometheus metrics in a standard http "/metrics" endpoint. *The list of metrics for each module should be defined in an activity prior to the start of the implementation.*
+- Including, in the OSM distribution, the appropriate Prometheus adapters for the third party software, namely Mongodb, Kafka and MariaDB/MySql.
+- Creating a set of standard alarms based on the exported metrics, which may be later extended and customized based on specific operator needs. *The list of standard alarms for each module should be defined in an activity prior to the start of the implementation*.
+
+This approach makes particular sense in a Kubernetes based OSM deployment using [Prometheus Operator](https://github.com/coreos/prometheus-operator), which will facilitate the dynamic discovery of the OSM module instances and the reaction to node failures, thus achieving almost Zero touch operations in this regard.
+
+Points for additional discussion:
+
+- Whether this should be an optional component.
+- Usage of the same Prometheus instance as for VNF monitoring, or a dedicated one.
+- How to restrict access based on user roles (this is also relevant for the current VNF metrics)
+- Definition of the metrics and alerts to be created for each module.
+
+
+## Demo or definition of done ##
+
+As part of the installation of the OSM distribution, the metrics for all the OSM modules (including third party software) should be available in Prometheus and may be visualized using a general purpose tool such as Grafana.
\ No newline at end of file
--- /dev/null
+# MongoDB as a Filesystem #
+
+## Proposer ##
+Adam Israel (Canonical)
+David Garcia (Canonical)
+Eduardo Sousa (Canonical)
+
+## Type ##
+**Feature**
+
+## Target MDG/TF ##
+NBI, LCM
+
+## Description ##
+Kubernetes orchestration of OSM Services has shortcomings since NBI and LCM require a
+shared volume to pass VNFD packages between them. This allows them to share the files
+between them without a major hassle. In order for this to be possible, Kubernetes needs
+to be deployed with a storage provider that supports read-write-many volumes so that
+both components can use the shared files. This puts the burden in the Kubernetes deployment.
+
+This feature aims to reduce this dependency of the Kubernetes deployment to provide a
+shared volume by using MongoDB to share the files between the two components. The MongoDB
+as a Filesystem can be achieved by using MongoDB in conjunction with GridFS and storing
+the files as documents in MongoDB.
+
+## Demo or definition of done ##
+* The files are written to MongoDB.
+* OSM is capable to instantiate a NS and make use of VNF configuration primitives.
--- /dev/null
+# Re-enable NS primitives #
+
+## Proposer ##
+Adam Israel
+Gerardo Garcia
+
+## Type ##
+**Feature**
+
+## Target MDG/TF ##
+IM, LCM, N2VC, NBI, osmclient
+
+## Description ##
+With the new OSM internal architecture, support of NS primitives based on
+scripts, offered in the past by the SO, has disappeared. Enabling again NS
+primitives is required to allow day-1 and day-2 operations over NS.
+
+Due to the need to implement it from scratch, it is better to follow an approach
+for NS primitives similar to VNF so that the same procedures and code could
+be used. Moreover, similar constructs for VNF and NS primitives enable a
+natural path for nesting NS, where a NS can be considered as a VNF building
+block to construct other NS. In this regard, the IM changes for NS primitives
+(primitives, charms, relations) should be as similar as possible to the ones
+currently present in the VNFD and VNFR IM.
+
+## Demo or definition of done ##
+To be added.
--- /dev/null
+# Support of high level primitives in SDN plugin model for SDN assist #
+
+## Proposer ##
+- Gerardo Garcia (Telefonica)
+- Alfonso Tierno (Telefonica)
+- Francisco Javier Ramon (Telefonica)
+
+## Type ##
+**Feature**
+
+## Target MDG/TF ##
+RO
+
+## Description ##
+The SDN plugin model in OSM assumes the existence of a set of calls in the
+plugin that allow RO to interact with different but equivalent primitives from
+various SDN controllers in an homogeneous fashion.
+
+The current set of calls assumes the availability of a number of basic
+flow-level provided by the SDN Controller, letting the RO assume the logic to
+create the various kinds of underlay networks supported by OSM, namely E-Line
+and E-LAN types.
+
+While this model of use might be a reasonable approach for many cases, it might
+be suboptimal for modern SDN controllers, which can be already capable of
+providing high level API operations to set up E-LAN and/or E-Line connections
+(and even prevent the use of flow-level operations.
+
+This feature proposes to augment the current SDN plugin model to support also
+CRUD operations for complete networks, leveraging on existing API calls of
+modern SDN controllers.
+
+## Demo or definition of done ##
+Show that it is possible to create, read, update and delete underlay
+connections of E-LAN and E-line types with, at least, one of the supported
+types of SDN controllers.
\ No newline at end of file
--- /dev/null
+# Support for network creation based on provider network attributes #
+
+## Proposer ##
+
+- Vanessa Little (VMware)
+- Mark Beierl (VMware)
+- Matt Harper (RIFT)
+- Ravi Chamarty (RIFT)
+
+## Type ##
+*Feature**
+
+## Target MDG/TF ##
+NBI, LCM, RO
+
+## Description ##
+The OSM instantiation parameters needs enhancement to support the following VIM specific per-VL attributes supports
+
+provider-network:
+ physical-network: string
+ segmentation-id: uint32
+
+NBI module shall validate the new OSM instantiation parameters. LCM module shalle pass the above parameters to RO during NS instantiation. OSM RO should support creation of VL based on provider-network.
+
+In the case of VMware VCD, this allows creation of VL based on a specific VDC external network.
+In the case of Openstack, this allows creation of VL based on a specific physical network.
+
+
+## Demo or definition of done ##
+Instantiate NS VL based on provider network attributes
--- /dev/null
+# Support for VMware VCD 9.5 #
+
+## Proposer ##
+
+- Vanessa Little (VMware)
+- Matt Harper (RIFT)
+- Ravi Chamarty (RIFT)
+
+## Type ##
+**Feature**
+
+## Target MDG/TF ##
+RO
+
+## Description ##
+This is primarily a test effort. We will test VMware VCD VIMConnector against VCD 9.5
+
+## Demo or definition of done ##
+Verify OSM R5 descriptor packages using VCD 9.5
projects / osm / Features.git / commitdiff