--- /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
+# 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
+# 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