NSI/NSSI Allocation enhancements

Note: This is a draft proposal and will be taken up for discussion. This is a stretch goal for Istanbul.

	Option 1	Option 2

	Option 1	Option 2
Instantiation of new (shareable) NSI (and its constituent NSSIs)	Instantiate the NSI (and constituent NSSI) so that it can cater to some additional dimensions, e.g., allow for 20% buffer (the 20% may come from Policy or be pre-configured). Impacts: SO (NSMF and NSSMF), SDN-R/C ??? Note: This could also come from NST (and OOF shall determine appropriate NST considering dimension attribute values in Service Profile), but it will result in many NSTs needed to be created. Alternatively, we could also have T-shirt size policies (small, medium, large) for every NST. This could be used by SO/OOF.	Instantiate it only with the required dimensions as required by the Service Profile.
Reuse of existing NSI	Consider (static) spare capacity based on allocated resources and ability to cater to the new Service Profile. Good short-term solution. Impacts: OOF (logic) - the (example) 20% configuration should be accessible to both SO and OOF (OR) Consider (predicted) dynamic spare capacity (considering also peaks) (and minimum guarantees for existing Service Profiles), and ability to cater to the new Service Profile. This will be a good long-term solution if implemented properly. Impacts: DCAE (Slice Analysis MS - data analysis, API/interface for querying by OOF), OOF (query DCAE, logic) (Possibly also KPI Computation MS) (Also Slice Analysis MS or KPI Computation MS has to invoke DES API for historical PM/KPI data) This solution could work with Option 1 and Option 2.	Consider (predicted) dynamic spare capacity (considering also peaks) (and minimum guarantees for existing Service Profiles), and ability to cater to the new Service Profile. This will be a good long-term solution if implemented properly. Impacts: DCAE (Slice Analysis MS - data analysis, API/interface for querying by OOF), OOF (query DCAE, logic) (Possibly also KPI Computation MS) (Also Slice Analysis MS or KPI Computation MS has to invoke DES API for historical PM/KPI data). To start with, we can only consider if there is dynamic spare capacity. Subsequently, feasibility (and cost) to scale can also be assessed and OOF recommendation can be based on this also. This will also help to cover slice "modification" scenario to some extent.
Reuse of existing NSSI	Similar approach as for NSI.	Similar approach as for NSI.
Closed Loop	If SLAs of one or more services mapped to a shared NSI/NSSI are impacted adversely, scaling or re-mapping (including slice splitting/creating a new NSI/NSSI) should be considered.	If SLAs of one or more services mapped to a shared NSI/NSSI are impacted adversely, scaling or re-mapping (including slice splitting/creating a new NSI/NSSI) should be considered.
Points to consider	Which dimension attributes to consider - maxNumberofUEs, bandwidth, throughput, ??? What minimum guarantee should we ensure such that the existing services are not disrupted unnecessarily? What about attributes such as endpoints and coverageArea? Perhaps they will be a second step.	Which dimension attributes to consider - maxNumberofUEs, bandwidth, throughput, ??? What minimum guarantee should we ensure such that the existing services are not disrupted unnecessarily? What about attributes such as endpoints and coverageArea? Perhaps they will be a second step.