Description:

Architectural considerations of ONAP having an E2E service using resources in another domain.

ARchCom 2019-09-03

Follow-up representation.

• Clarification updates to the design part (the CSAR can be a service without a resource).
• Presented an example of the payload example.
• There is a discussion of assumptions in terms of connectivity betweeen the 3rd party domain, who assigns IP addresses, how the connectivity works etc.
• It was commented that some operators may not allow the step for the 3rd party domain to insert definitions into their catalogue.  It was suggested to show the options (or capture in the text) that the 1. (slide 7) may came from the operator itself (and the definition received out of bound).
• There was a discussion about whether it should be possble to allow the "3rd party" service definition to be distributed enough as it is; or whether it has to be wrapped up in another service in order to allow for decomposition and homing.
• Need consistency
• There is a need for another service/resource definition (taken seperately though).

ArchCom 2019-08-27

• Re-representation.
• The "5a" on the design time is the pull request after the notificatin.
• The Get request from SDC doesn't change, but there is change in the logic in SDC.
• Number "3" (response to 3rd party domain) will happen after 5b.
• There is a request for the example of the 3rd party domain; it will only have the "reference" to the service as an abstraction to the service in the underlying domain.  it is similar to CCVPN.
• There is commonality in the requirements with service resolver.
• We need to have a look at an example model of the RFS/CFS
  • Relate the hierarchical structure of the relation between the service.
  • Then choose nested service.
  • How much is seen inside ONAP and what is seen outside of ONAP.

ArchCom 2019-07-02

• Does SO interwork with southbound systems using the ExtAPI? Needs to be revisited - possible to define external system in ESR and invoke directly
• Focus is on the onboarding in Frankfurt

ArchCom 2019-06-25

Atif/Nisha presented: https://wiki.onap.org/download/attachments/50202249/ONAP%20usecase%20-%20Third%20Party%20ODM_v8.pdf?api=

It has been presented in the EUAG and at the DDF in Stockholm.

Managing 3rd party domains is a scenario that is seen as important.

• The interface between ONAP and the 3rd party domains is: TMF OPEN APIs and Domain specific APIs (this is southbound of ONAP)
• Proposes enhancements in SDC
• It was commented that ONAP covers the NaaS capabilities as well as well as the operational domain manager, however Telstra has already implemented the NaaS layer so they focus on the operational domain manager.
• It was clarified that the VNF LCM is handled in the 3rd party domain. (on slide 3)
• The full scope may not be in release F. 
• There was a request to: define the complete flow.  Before that it would be good to define the responsibilities.
• The 3rd party domain has RFSs that it owns.  ONAP has the CFSs ontop of the service
• The role of the orchestrators can be included.  How does it relate to SO - DO and SO - SO.
• What are the workflows in 4 and 8 doing.
• There are touch points between this and the service selector presentation from Orange last week should be continued.
• How is it handled if there the service traverses more than one 3rd party domain.
• It was requested that the parts of 641 that are relivant to ONAP.
• If there are CSAR distributed without the VNF artifacts, does this have any impact on the other ONAP components.  The response was that this was the motivation for the separate category.  Also there is distribution today for services without VNFs.

Good discussion and appreciation for the idea, as this was the first round it is needed to represent with further details on the run time so its can be seen how it all fits together.  it was also added that there is a video for a PoC on the designtime available.