...
- Though in theory both Options may be supported in a single deployment, it will create a lot of complexities and confusions in practice (and additional side-effects and implementation overheads which have to be handled) as E2E network slicing functionality evolves. So, in a single ONAP deployment, Option 1 OR Option 2 shall be supported but NOT BOTH.
- SO (TN NSSMF) does not support call to OOF for NSSI selection. This means, when a new NSI is created, TN NSSI (FH, BH and MH) have to be created newly.
- SO (TN NSSMF) does not support call to OOF for determining if an NSSI shall be terminated or not. So based on the API (deallocate or modify), SO (TN NSSMF) shall decide to terminate the TN NSSI (FH, BH or MH) or not.
- For FH and MH, we take some assumptions for the short-term: for e.g., pre-provisioned endpoint info for RU, CU and DU. If feasible, endpoints should be a list, to enable multipoint to multipoint connectivity in future. Open points for future consideration:
- How should we specify which RU(s) should be connected to which DU(s)? This will become relevant when we consider multipoint to multipoint connectivity in future.
- How will endpoints be specified - will it be by topology discovery or ???
...