If "Service Orchestrator" were an ODA Component your question could be answered authoritatively, however it is not, although it has been proposed.
Your question becomes one of whether to model and manage entities of the Service or Resource domains.
When viewed from an ODA Core Commerce block perspective a Customer Facing Service (CFS) is required to be put into a Product. Activating a CFS is done with TMF640.
When viewed from an ODA Production block perspective, holistically, an IP MPLS network is in the Resource domain and a Resource Function (RF) is the correct choice for representing a Network Service (NS), such as an IETF service chain (VPN). Activating an RF is done with TMF664.
You mention NMS, which includes functions for configuration, fault and performance management (CM. FM. PM). Where an NMS is managing Resource domain network elements you should use TMF664 and TMF702 for CM, TMF642 for FM and TMF628 for PM.
Between a CFS and an RF you have a Resource Facing Function (RFS) which is an entity of the Service domain. The original purpose of an RFS was to encapsulate technology specifics so that RFSs may change without necessitating a CFS change. RF was a more recent addition and, if done correctly, should be reusable as you switch out network vendors, for example. This leaves less of a role for RFS.
Many have a Service domain centric view, managing CFS/RFS with ODA and Open APIs and leaving the Resource domain as an integration exercise using whatever protocols vendors support. This is essentially the NaaS view (Network-as-a-Service).
If I were a vendor of network solutions I might want to support both TMF640 and TMF664 so that the choice of a Resource or Service domain centric solution could be left to the CSPs. Those APIs are quite similar so it isn't much of a burden.
------------------------------
Vance Shipley
SigScale
------------------------------
Original Message:
Sent: Jun 13, 2024 01:05
From: Wan Ahmad Rahimi Nik
Subject: Query on IPVPN service order / activation scenario
Hi Jonathan,
Same scenario for IPVPN service activation, what is the suitable TMF API to be used between Service Orchestrator and the NMS? The NMS is managing traditional ip mpls network.
I'm baffled either to use TMF640, TMF664, TMF702 or others?
Could you enlighten me?
------------------------------
Wan Ahmad Rahimi Nik
TM Technology Services Sdn Bhd
Original Message:
Sent: May 13, 2024 00:52
From: Jonathan Goldberg
Subject: Query on IPVPN service order / activation scenario
How about TMF640 - Service Activation and Configuration?
The request body of POST in this API is a Service, as is the response body. So your network element (or adapter) can enrich the service characteristics in the response body.
Hope it helps
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
Original Message:
Sent: May 12, 2024 22:54
From: Tajul Fakhar Fahirurazi
Subject: Query on IPVPN service order / activation scenario
We have a scenario on IPVPN service order/activation whereby it requires response parameters such as port number, ip address and subnet mask/prefix-length.
Which TM Forum Open API is suitable to address above scenario?
------------------------------
Tajul Fakhar Fahirurazi
TM Technology Services Sdn Bhd
------------------------------