Operator/EUAG
- Do we need to consider intraoperator multi-administrative domain interaction – i.e communication across different instances of domain orchestrators (ONAP or non-ONAP) belonging to the same operator?
- Do we need to limit the scope of Interlude to Service Control, Activation, and Configuration or include Service Order Management?
- Use Cases: What use cases we should consider for the interlude specification? Generic Operational use cases (Service activation, query etc) or Specific Business use case ? (NaaS, NFaaS, Access E-Line etc) – Short term and Long Term Target?
- Consideration for interaction between ONAP and non-ONAP (Legacy) Management system across operator domains
- Strategy for closed-loop control (Assurance) – Who will manage? Partner managed or SP managed
- Resiliency requirements for inter-operator management connectivity – Failover mechanisms
- Do we need to consider interdependency of Interlude and Legato/Sonata interface? (for example contract)
- Service Impact Assessment - Need for doing a Service impact analysis before any operation over interlude
- Need for Service Change Management: Interlude operations to be initiated as work order through a Change management API (e.g. TMF 655) - Is this the practical mode of operation? Or expect a more dynamic service control operation ?
- Dynamic or Static workflows to be supported to accommodate Interlude operations (SO and beyond)
- Need for supporting ETSI Or-Or interface (ETSI SOL011) at Ext-API level or it can be supported as a component level (SO or VFC) east-west API
Architecture Subcommittee Onboarding and distribution model for SP and Partner Service Descriptors - Controlled by separate SDC instances or by common SDC instanCataloginstance - ogueCatalogue and Inventory Management – Strategy for 1) onboarding the catalog with service specification across interdomain boundaries 2) Reconciliation and aggregation of inventory at each domain – Pull vs Push model
- ONAP specific terminology: Different SDOs follow different terminology e.g. operator interoperability, domain interoperability, administrative system interoperability etc.
- Cross-layer interaction requirement and the need to accomodate this as part of interlude scope: for example OOF layer of SP need to interact with Multi-VIM of Partner for resource utilization, SDNC of partner sharing data to DCAE of SP (both not via Ext-API interlude but inter-component APIs) – Is this model valid (MLPOC as per ETSI IFA028 )
- Federation vs Delegation
- Federation actors and Roles : What type of provider roles we should consider ? Infrastructure provider, Connectivity SP, Partner SP, Master/Slave), Do we also need to consider different layers of partners – infrastructure, connectivity etc.
- Need for including the Business layer interactions within the scope of interlude (for example dependency on Service Policy), Service Creation (in the absence of Business Application)
- Separation of concerns : All external facing interactions to be managed via External-API, Should SO be Sservice Order aware ?
- Need for supporting Or-Or interface over the interlude reference point
Modeling Subcommittee - Service Model Impact: Service hierarchy in the Service model – i.e Composite or Nested Service, Constituent Service – How the service model is decomposed and distributed to operator and partner domains? Any pattern to follow? Or based on request attributes?
- Representation of Partner Service and Resources , Partner Registration data, Policy, Service associations between SP and Partner in Inventory
- Use of Allotted Network Function vs SPPartner for representing Partner Service
- Data Model Alignment for Ext-API : TMF vs MEF vs ONAP runtime model
- SPPartner and ANF have similar functionality - Are they redundant ?
Security Subcommittee - Security mechanism to be established between parties - Recommendations and guidance
- Regulatory guidance : What kind of regulatory checks to be incorporated
Project team input - SO: Plan for supporting Service configuration, Service change - What REST APIs to use PUT or PATCH of Service or a dedicated action
- Policy: Representation of confguration policies for cross operator interaction, representation of constraints for scheduling operations on Interlude
- SDC : Modelling and managing Partner services, service access points, distribution of service
- A&AI : Representation of partner resources and services
| 