Open APIs

Hello, We have a hierarchy with SOM working as CFS and IP controller working as RFS as shown in diagram.  The IP controller is responsible for provisioning of services like  L2 VPN, IP VPN, DIA etc and directly faces the network ( routers).  The CFS has direct access to the inventory of the IP domain. 

So the process is like this: The CFS sends service request to RFS to configure a service like layer 2 VPN  using TMF 641 with all resource details as parameters like NE, Card, BW info, VLAN. Once the RFS receives the API , it decomposes it and configures different resources 

Question:

1. The RFS is not involved in any resource selection as it depends on the CFS to send that info. Is it fine to use  TMF 641 between CFS and RFS  to have some abstraction and make integration simple  ? So for example the CFS will send  one API to Activate L2 VPN and pass on parameters like NE, Card, port, BW, VLAN etc, the RFS will then decompose and configure the network.

 2. Some might argue on using TMF 702 ( Resource activation) APIs but that would mean sending multiple APIs to configure each resource separately.  Isn't use of TMF 641 a better and simple approach here?

FaIsal this topic of modelling controllers  in ODA Production is being disussed in two teams

• The NaaS transformation team  Tuesdays 19:30 GMT
• The  ODA production team Thursday 10:30GMT

Whilst the discussion is not finish the observation is that RFS are about resources whereas the emergence of Controller and orchestrator seem to be incorporate functionality that used to be in Element Managers ( a concept that seem to be being replaces  by virtualisation and cloudification see ITU  M3041 and M3080). Emerging opinion is that Controller and orchestrator are exposing Service ( CFS) .. So use of NaaS API Suite TMF909 supports both TMF640 and TMF 641 ,of which TMF641 is the most appropriate . Note also that where virtualisation and software defined solution are being uses that the use of Resource Function within a Service based API can be an appropriate approach see GB922 Resource v23.0.0 – TM Forum  Specifically section

Specifically section 4.4.11 pg 51 thru 4.4.20   which has examples including support concept of Feature - note the paragraph numbering has some issues as this is done automatically 

Hello, We have a hierarchy with SOM working as CFS and IP controller working as RFS as shown in diagram.  The IP controller is responsible for provisioning of services like  L2 VPN, IP VPN, DIA etc and directly faces the network ( routers).  The CFS has direct access to the inventory of the IP domain. 

So the process is like this: The CFS sends service request to RFS to configure a service like layer 2 VPN  using TMF 641 with all resource details as parameters like NE, Card, BW info, VLAN. Once the RFS receives the API , it decomposes it and configures different resources 

Question:

1. The RFS is not involved in any resource selection as it depends on the CFS to send that info. Is it fine to use  TMF 641 between CFS and RFS  to have some abstraction and make integration simple  ? So for example the CFS will send  one API to Activate L2 VPN and pass on parameters like NE, Card, port, BW, VLAN etc, the RFS will then decompose and configure the network.

 2. Some might argue on using TMF 702 ( Resource activation) APIs but that would mean sending multiple APIs to configure each resource separately.  Isn't use of TMF 641 a better and simple approach here?