Open APIs

Hello,

Resource order management (ROM) receives resource order request that contains multiple resource order items. Each resource order item contains one resource (an instance of resource specification). Resource activation (RA) receives a resource as request. Both of them receives resource structure. According to ig1228 uc008, ROM receives request from SOM. Then it passes the request to RA. In my opinion, one of them is enough to fulfill resource request. Why did the use case implement both?

Hello,

Resource order management (ROM) receives resource order request that contains multiple resource order items. Each resource order item contains one resource (an instance of resource specification). Resource activation (RA) receives a resource as request. Both of them receives resource structure. According to ig1228 uc008, ROM receives request from SOM. Then it passes the request to RA. In my opinion, one of them is enough to fulfill resource request. Why did the use case implement both?

Hello,

Resource order management (ROM) receives resource order request that contains multiple resource order items. Each resource order item contains one resource (an instance of resource specification). Resource activation (RA) receives a resource as request. Both of them receives resource structure. According to ig1228 uc008, ROM receives request from SOM. Then it passes the request to RA. In my opinion, one of them is enough to fulfill resource request. Why did the use case implement both?

Hi,

We recently had a similar discussion in the ODA component group. As a conclusion Resource order management is defined as an component that orchestrates dependencies and updates resource inventories. ROM doesn't interact in any non TMF protocols. It calls a resource activation component that translates TMF formated activation in a protocol/API managed by another SDO (Standards Developing Organisation) (Netconf, SNMP, ...)

I hope that clarifies the separation.

Regards

Hello,

Resource order management (ROM) receives resource order request that contains multiple resource order items. Each resource order item contains one resource (an instance of resource specification). Resource activation (RA) receives a resource as request. Both of them receives resource structure. According to ig1228 uc008, ROM receives request from SOM. Then it passes the request to RA. In my opinion, one of them is enough to fulfill resource request. Why did the use case implement both?

Hi,

We recently had a similar discussion in the ODA component group. As a conclusion Resource order management is defined as an component that orchestrates dependencies and updates resource inventories. ROM doesn't interact in any non TMF protocols. It calls a resource activation component that translates TMF formated activation in a protocol/API managed by another SDO (Standards Developing Organisation) (Netconf, SNMP, ...)

I hope that clarifies the separation.

Regards

Hello,

Resource order management (ROM) receives resource order request that contains multiple resource order items. Each resource order item contains one resource (an instance of resource specification). Resource activation (RA) receives a resource as request. Both of them receives resource structure. According to ig1228 uc008, ROM receives request from SOM. Then it passes the request to RA. In my opinion, one of them is enough to fulfill resource request. Why did the use case implement both?

Hi,

According to ig1228 v16 uc008, the ROM calls a non TMF API "SM-DP+". You wrote that ROM doesn't interact in any non TMF protocol. Select/get actions are allowed?

Hi,

We recently had a similar discussion in the ODA component group. As a conclusion Resource order management is defined as an component that orchestrates dependencies and updates resource inventories. ROM doesn't interact in any non TMF protocols. It calls a resource activation component that translates TMF formated activation in a protocol/API managed by another SDO (Standards Developing Organisation) (Netconf, SNMP, ...)

I hope that clarifies the separation.

Regards

Hello,

Resource order management (ROM) receives resource order request that contains multiple resource order items. Each resource order item contains one resource (an instance of resource specification). Resource activation (RA) receives a resource as request. Both of them receives resource structure. According to ig1228 uc008, ROM receives request from SOM. Then it passes the request to RA. In my opinion, one of them is enough to fulfill resource request. Why did the use case implement both?

Hi,

The discussion regarding ROM and Resource Activation & Configuration dates from this month. Documentation of ig1228 UC to reflect this is work in progress.

Thanks for pointing out the sequence diagram that requires correction.

Regards

Hi,

According to ig1228 v16 uc008, the ROM calls a non TMF API "SM-DP+". You wrote that ROM doesn't interact in any non TMF protocol. Select/get actions are allowed?

Hi,

We recently had a similar discussion in the ODA component group. As a conclusion Resource order management is defined as an component that orchestrates dependencies and updates resource inventories. ROM doesn't interact in any non TMF protocols. It calls a resource activation component that translates TMF formated activation in a protocol/API managed by another SDO (Standards Developing Organisation) (Netconf, SNMP, ...)

I hope that clarifies the separation.

Regards

Hello,

Resource order management (ROM) receives resource order request that contains multiple resource order items. Each resource order item contains one resource (an instance of resource specification). Resource activation (RA) receives a resource as request. Both of them receives resource structure. According to ig1228 uc008, ROM receives request from SOM. Then it passes the request to RA. In my opinion, one of them is enough to fulfill resource request. Why did the use case implement both?

Hi,

The discussion regarding ROM and Resource Activation & Configuration dates from this month. Documentation of ig1228 UC to reflect this is work in progress.

Thanks for pointing out the sequence diagram that requires correction.

Regards

Hi,

According to ig1228 v16 uc008, the ROM calls a non TMF API "SM-DP+". You wrote that ROM doesn't interact in any non TMF protocol. Select/get actions are allowed?

Hi,

We recently had a similar discussion in the ODA component group. As a conclusion Resource order management is defined as an component that orchestrates dependencies and updates resource inventories. ROM doesn't interact in any non TMF protocols. It calls a resource activation component that translates TMF formated activation in a protocol/API managed by another SDO (Standards Developing Organisation) (Netconf, SNMP, ...)

I hope that clarifies the separation.

Regards

Hello,

Resource order management (ROM) receives resource order request that contains multiple resource order items. Each resource order item contains one resource (an instance of resource specification). Resource activation (RA) receives a resource as request. Both of them receives resource structure. According to ig1228 uc008, ROM receives request from SOM. Then it passes the request to RA. In my opinion, one of them is enough to fulfill resource request. Why did the use case implement both?

Hello,

The demand for having ROM and Resource Configuration/ Activation components separately was discussed in the previous Accelerate . We considered the traditional use cases with physical network elements. One of the motivations for having ROM and Resource Configuration components separately is regulator requirements in some countries. The current list of available ROM APIs is presented in TMFC011:Resource Order Management

UC008 was created before this proposal and doesn't have yet this component, so will be updated. TMF NaaS architecture implies having TMF ODA E2E Service Management Domain and different ODMs which was depicted in IG1224 noted by Dave.

Thank you for your comments.

Hi,

The discussion regarding ROM and Resource Activation & Configuration dates from this month. Documentation of ig1228 UC to reflect this is work in progress.

Thanks for pointing out the sequence diagram that requires correction.

Regards

Hi,

According to ig1228 v16 uc008, the ROM calls a non TMF API "SM-DP+". You wrote that ROM doesn't interact in any non TMF protocol. Select/get actions are allowed?

Hi,

We recently had a similar discussion in the ODA component group. As a conclusion Resource order management is defined as an component that orchestrates dependencies and updates resource inventories. ROM doesn't interact in any non TMF protocols. It calls a resource activation component that translates TMF formated activation in a protocol/API managed by another SDO (Standards Developing Organisation) (Netconf, SNMP, ...)

I hope that clarifies the separation.

Regards

Hello,

Resource order management (ROM) receives resource order request that contains multiple resource order items. Each resource order item contains one resource (an instance of resource specification). Resource activation (RA) receives a resource as request. Both of them receives resource structure. According to ig1228 uc008, ROM receives request from SOM. Then it passes the request to RA. In my opinion, one of them is enough to fulfill resource request. Why did the use case implement both?

Confused, Koen is suggesting a separate component (ODA-C) for the TMF702 Resource Activation & Configuration provider (which I agree with), yet others are still suggesting that resource provisioning is part of the ROM.  Should the ROM ODA-C then be renamed Resource Provisioning and the SOM ODA-C renamed Service Orchestration (to incorporate both SOM and SA-TMF640)?

------------------------------
Dan d'Albuquerque
Individual

Original Message:
Sent: Feb 19, 2024 09:53
From: Dmytro Gassanov
Subject: Resource order management vs resource activation

Hello,

The demand for having ROM and Resource Configuration/ Activation components separately was discussed in the previous Accelerate . We considered the traditional use cases with physical network elements. One of the motivations for having ROM and Resource Configuration components separately is regulator requirements in some countries. The current list of available ROM APIs is presented in TMFC011:Resource Order Management

UC008 was created before this proposal and doesn't have yet this component, so will be updated. TMF NaaS architecture implies having TMF ODA E2E Service Management Domain and different ODMs which was depicted in IG1224 noted by Dave.

Thank you for your comments.

------------------------------
Dmytro Gassanov
TM Forum

Original Message:
Sent: Feb 19, 2024 09:27
From: Koen Peeters
Subject: Resource order management vs resource activation

Hi,

The discussion regarding ROM and Resource Activation & Configuration dates from this month. Documentation of ig1228 UC to reflect this is work in progress.

Thanks for pointing out the sequence diagram that requires correction.

Regards

------------------------------
Koen Peeters
OryxGateway FZ LLC

Original Message:
Sent: Feb 19, 2024 09:20
From: Myagaa Nm
Subject: Resource order management vs resource activation

Hi,

According to ig1228 v16 uc008, the ROM calls a non TMF API "SM-DP+". You wrote that ROM doesn't interact in any non TMF protocol. Select/get actions are allowed?

------------------------------
Myagaa Nm
Mobicom Corporation

Original Message:
Sent: Feb 19, 2024 07:23
From: Koen Peeters
Subject: Resource order management vs resource activation

Hi,

We recently had a similar discussion in the ODA component group. As a conclusion Resource order management is defined as an component that orchestrates dependencies and updates resource inventories. ROM doesn't interact in any non TMF protocols. It calls a resource activation component that translates TMF formated activation in a protocol/API managed by another SDO (Standards Developing Organisation) (Netconf, SNMP, ...)

I hope that clarifies the separation.

Regards

------------------------------
Koen Peeters
OryxGateway FZ LLC

Original Message:
Sent: Feb 16, 2024 01:52
From: Myagaa Nm
Subject: Resource order management vs resource activation

Hello,

Resource order management (ROM) receives resource order request that contains multiple resource order items. Each resource order item contains one resource (an instance of resource specification). Resource activation (RA) receives a resource as request. Both of them receives resource structure. According to ig1228 uc008, ROM receives request from SOM. Then it passes the request to RA. In my opinion, one of them is enough to fulfill resource request. Why did the use case implement both?

------------------------------
Myagaa Nm
Mobicom Corporation
------------------------------

I would suggest this discussion would be best continued as comment on the live team discusions

1. See Production: Components & Interactions - Components and Canvas - TM Forum Confluence 

updated 15 Feb 2024 by @Anastasios Sarantis    to decribe  ODA production Components asn their interaction based on discussion at Accelerate

As Dmytro mentioned at Accelerate  there was agreement to introduce a new component called Resource configurator simile to the Product configurator. Rationale was that the profile and configuration templates need to be under the control of Network departments to meet emerging regulations on securing critical infrastructure.

Anastasios will be creating an ODA  Component specification for this new component. 

2. The diagrams in IG1228 UC0008 will need to be updated to reflect the Accelerator discussion agreements It would be good to add you comment about the diagram as a contribution to the team which meets Thursday at 13;00 GMT ( under e2e ODA ) or as a feedback on on TMFS008 Use Case: Service and Resource Order Management for Postpaid Mobile Subscribers v3.0.1 – TM Forum

Confused, Koen is suggesting a separate component (ODA-C) for the TMF702 Resource Activation & Configuration provider (which I agree with), yet others are still suggesting that resource provisioning is part of the ROM.  Should the ROM ODA-C then be renamed Resource Provisioning and the SOM ODA-C renamed Service Orchestration (to incorporate both SOM and SA-TMF640)?

Hello,

The demand for having ROM and Resource Configuration/ Activation components separately was discussed in the previous Accelerate . We considered the traditional use cases with physical network elements. One of the motivations for having ROM and Resource Configuration components separately is regulator requirements in some countries. The current list of available ROM APIs is presented in TMFC011:Resource Order Management

UC008 was created before this proposal and doesn't have yet this component, so will be updated. TMF NaaS architecture implies having TMF ODA E2E Service Management Domain and different ODMs which was depicted in IG1224 noted by Dave.

Thank you for your comments.

Hi,

The discussion regarding ROM and Resource Activation & Configuration dates from this month. Documentation of ig1228 UC to reflect this is work in progress.

Thanks for pointing out the sequence diagram that requires correction.

Regards

Hi,

According to ig1228 v16 uc008, the ROM calls a non TMF API "SM-DP+". You wrote that ROM doesn't interact in any non TMF protocol. Select/get actions are allowed?

Hi,

We recently had a similar discussion in the ODA component group. As a conclusion Resource order management is defined as an component that orchestrates dependencies and updates resource inventories. ROM doesn't interact in any non TMF protocols. It calls a resource activation component that translates TMF formated activation in a protocol/API managed by another SDO (Standards Developing Organisation) (Netconf, SNMP, ...)

I hope that clarifies the separation.

Regards

Hello,

Resource order management (ROM) receives resource order request that contains multiple resource order items. Each resource order item contains one resource (an instance of resource specification). Resource activation (RA) receives a resource as request. Both of them receives resource structure. According to ig1228 uc008, ROM receives request from SOM. Then it passes the request to RA. In my opinion, one of them is enough to fulfill resource request. Why did the use case implement both?

Hello,

Resource order management (ROM) receives resource order request that contains multiple resource order items. Each resource order item contains one resource (an instance of resource specification). Resource activation (RA) receives a resource as request. Both of them receives resource structure. According to ig1228 uc008, ROM receives request from SOM. Then it passes the request to RA. In my opinion, one of them is enough to fulfill resource request. Why did the use case implement both?

I understand ROM shouldn't interact with non TMF APIs. Resource activation receives resource. It calls non TMF APIs. It should translate resource to the api request. According to ig1228 uc008, API spec is resource spec. Then resource inventory stores api records that is instance of api spec. Tmf730 document contains api spec and api resource description. But it is not enough to translate resource to the api request. I didn't understand well that how the use case implements the specs in resource catalog. Because api doesn't contain enough informationin tmf730, I couldn't get well. In my opinion, I need some hard coded translation between the resource and non tmf api. I am interested in how can I implement the translation with no hardcoded solution? Because I need to define request body and response body template in the api spec. Then I can check response of api comparing it with response body template if it is successful.@Vance Shipley@Dave Milham@Koen Peeters

Hello,

Resource order management (ROM) receives resource order request that contains multiple resource order items. Each resource order item contains one resource (an instance of resource specification). Resource activation (RA) receives a resource as request. Both of them receives resource structure. According to ig1228 uc008, ROM receives request from SOM. Then it passes the request to RA. In my opinion, one of them is enough to fulfill resource request. Why did the use case implement both?