Open APIs

There is some inherent flexibility in the TMF Open API design to support different business models.   One area where this flexibility is clear is whether the network exposes single services and service order processing is fully a BSS responsibility.  Or the network may accept the full or partial service order and service order processing is a network responsibility. The decision would drive the usage of TMF 641 and/or 640.

Also refer to IG1164 Requirements Analysis for the Ordering and Configuration of Services and Resources: with Impacts on APIs and Information Models for further information.

Had problem with uploading Images or any attachments. Tried using different browsers but doesn't seem to help.

Thank you for all the inputs.

Am trying to summarize my understanding and also sharing some new aspects that I did like to use to differentiate between TMF-641 and TMF-640. Please share your feedback.

Architecture Options:

Option-1: TMF-641 should be the Interface for BSS to request Services using Service Orders.

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Differences:

Differences between TMF-641 and TMF-640 in terms of functional capabilities. Architecture option should be chosen based on these capabilities and not extend the capabilities of TMF-640 to make it look like TMF-641 thus defeating the purpose of two(TMF-641 and TMF-640) standard Interfaces and making them ambiguous.

TMF-641

1. Operations(CRUD) on Service Order
2. Service Order can contain multiple Services
3. Support for Composition and Decomposition to RFS(s) and Resource(s)
4. Support for Long Running Business Processes, support for Inflight changes to Service Order

5. Provider of TMF-641 works with Service Inventory using TMF-638

6. TAM Functions supported: Design Solution, Assignments, Reservation, Manage Service Dependencies, Manage Service Instance, Address Validation, Plan for Service Configuration and Activation and Service Configuration & Activation(using TMF-640)
7. Orders can result in partial success and provide control to the consumer to handle/resolve the failed aspects.

 TMF-640

1. Operations(CRUD) on Service(typically RFS, however in case of Architecture Option2 can be Service which represents both CFS and RFS)
2. Request operates on Single Service
3. Support for Decomposition to Resource Provisioning requests on a single Resource only
4. Support for short lived Business Processes, no need for Inflight changes of Service Request.

5. Provider of TMF-640 doesn't need Service Inventory

6. TAM Functions supported: Service Configuration & Activation. Infrastructure(Devices & Networks) for the Service are expected to be pre-existing.
7. Service requests are atomic, complete success or complete failure.

Had problem with uploading Images or any attachments. Tried using different browsers but doesn't seem to help.

Thank you for all the inputs.

Am trying to summarize my understanding and also sharing some new aspects that I did like to use to differentiate between TMF-641 and TMF-640. Please share your feedback.

Architecture Options:

Option-1: TMF-641 should be the Interface for BSS to request Services using Service Orders.

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Differences:

Differences between TMF-641 and TMF-640 in terms of functional capabilities. Architecture option should be chosen based on these capabilities and not extend the capabilities of TMF-640 to make it look like TMF-641 thus defeating the purpose of two(TMF-641 and TMF-640) standard Interfaces and making them ambiguous.

TMF-641

1. Operations(CRUD) on Service Order
2. Service Order can contain multiple Services
3. Support for Composition and Decomposition to RFS(s) and Resource(s)
4. Support for Long Running Business Processes, support for Inflight changes to Service Order

5. Provider of TMF-641 works with Service Inventory using TMF-638

6. TAM Functions supported: Design Solution, Assignments, Reservation, Manage Service Dependencies, Manage Service Instance, Address Validation, Plan for Service Configuration and Activation and Service Configuration & Activation(using TMF-640)
7. Orders can result in partial success and provide control to the consumer to handle/resolve the failed aspects.

 TMF-640

1. Operations(CRUD) on Service(typically RFS, however in case of Architecture Option2 can be Service which represents both CFS and RFS)
2. Request operates on Single Service
3. Support for Decomposition to Resource Provisioning requests on a single Resource only
4. Support for short lived Business Processes, no need for Inflight changes of Service Request.

5. Provider of TMF-640 doesn't need Service Inventory

6. TAM Functions supported: Service Configuration & Activation. Infrastructure(Devices & Networks) for the Service are expected to be pre-existing.
7. Service requests are atomic, complete success or complete failure.

Architecture Options:

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Scenario :- There is a SOM in the business and which is CFS and while sending down the notifications related to the service to the other RFS's in the domain ,but not in TMF640 structured way , Can we expect the CFS interface to send the payload or the data in already structured form i.e, more alike TMF 641 standard ?
What could be the impact on the SOM which is already on TMF 641 to manipulate the data to TMF 640 before sending it down to RFS nodes in topology ?

Had problem with uploading Images or any attachments. Tried using different browsers but doesn't seem to help.

Thank you for all the inputs.

Am trying to summarize my understanding and also sharing some new aspects that I did like to use to differentiate between TMF-641 and TMF-640. Please share your feedback.

Architecture Options:

Option-1: TMF-641 should be the Interface for BSS to request Services using Service Orders.

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Differences:

Differences between TMF-641 and TMF-640 in terms of functional capabilities. Architecture option should be chosen based on these capabilities and not extend the capabilities of TMF-640 to make it look like TMF-641 thus defeating the purpose of two(TMF-641 and TMF-640) standard Interfaces and making them ambiguous.

TMF-641

1. Operations(CRUD) on Service Order
2. Service Order can contain multiple Services
3. Support for Composition and Decomposition to RFS(s) and Resource(s)
4. Support for Long Running Business Processes, support for Inflight changes to Service Order

5. Provider of TMF-641 works with Service Inventory using TMF-638

6. TAM Functions supported: Design Solution, Assignments, Reservation, Manage Service Dependencies, Manage Service Instance, Address Validation, Plan for Service Configuration and Activation and Service Configuration & Activation(using TMF-640)
7. Orders can result in partial success and provide control to the consumer to handle/resolve the failed aspects.

 TMF-640

1. Operations(CRUD) on Service(typically RFS, however in case of Architecture Option2 can be Service which represents both CFS and RFS)
2. Request operates on Single Service
3. Support for Decomposition to Resource Provisioning requests on a single Resource only
4. Support for short lived Business Processes, no need for Inflight changes of Service Request.

5. Provider of TMF-640 doesn't need Service Inventory

6. TAM Functions supported: Service Configuration & Activation. Infrastructure(Devices & Networks) for the Service are expected to be pre-existing.
7. Service requests are atomic, complete success or complete failure.

Architecture Options:

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Scenario :- There is a SOM in the business and which is CFS and while sending down the notifications related to the service to the other RFS's in the domain ,but not in TMF640 structured way , Can we expect the CFS interface to send the payload or the data in already structured form i.e, more alike TMF 641 standard ?
What could be the impact on the SOM which is already on TMF 641 to manipulate the data to TMF 640 before sending it down to RFS nodes in topology ?

Had problem with uploading Images or any attachments. Tried using different browsers but doesn't seem to help.

Thank you for all the inputs.

Am trying to summarize my understanding and also sharing some new aspects that I did like to use to differentiate between TMF-641 and TMF-640. Please share your feedback.

Architecture Options:

Option-1: TMF-641 should be the Interface for BSS to request Services using Service Orders.

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Differences:

Differences between TMF-641 and TMF-640 in terms of functional capabilities. Architecture option should be chosen based on these capabilities and not extend the capabilities of TMF-640 to make it look like TMF-641 thus defeating the purpose of two(TMF-641 and TMF-640) standard Interfaces and making them ambiguous.

TMF-641

1. Operations(CRUD) on Service Order
2. Service Order can contain multiple Services
3. Support for Composition and Decomposition to RFS(s) and Resource(s)
4. Support for Long Running Business Processes, support for Inflight changes to Service Order

5. Provider of TMF-641 works with Service Inventory using TMF-638

6. TAM Functions supported: Design Solution, Assignments, Reservation, Manage Service Dependencies, Manage Service Instance, Address Validation, Plan for Service Configuration and Activation and Service Configuration & Activation(using TMF-640)
7. Orders can result in partial success and provide control to the consumer to handle/resolve the failed aspects.

 TMF-640

1. Operations(CRUD) on Service(typically RFS, however in case of Architecture Option2 can be Service which represents both CFS and RFS)
2. Request operates on Single Service
3. Support for Decomposition to Resource Provisioning requests on a single Resource only
4. Support for short lived Business Processes, no need for Inflight changes of Service Request.

5. Provider of TMF-640 doesn't need Service Inventory

6. TAM Functions supported: Service Configuration & Activation. Infrastructure(Devices & Networks) for the Service are expected to be pre-existing.
7. Service requests are atomic, complete success or complete failure.

Hi
We recently debated this on back of actual implementation for complex Enterprise segment of Tier 1 Telco. Our conclusion is that RFS Order Mgmt is of limited use and definitely should be avoided when there is already CFS Order Mgmt

RFS Order Mgmt could potentially be used for Bulk Operations of RFS for eg Migration, and that too when RFSes have no CFS for eg Backhaul Circuits for Plan & Build, when hese circuits are being upgraded etc

Even that can be avoided by extending TMF640 slightly to allow multiple RFSes in payload, and Plan & Build Workflow Manager consumes this. Please see our thoughts on the subject compiled below

It would help if the TMF 641 / TMF 640 write-ups updated for such clarification and give clear guidance by addressing the ambiguities

Architecture Options:

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Scenario :- There is a SOM in the business and which is CFS and while sending down the notifications related to the service to the other RFS's in the domain ,but not in TMF640 structured way , Can we expect the CFS interface to send the payload or the data in already structured form i.e, more alike TMF 641 standard ?
What could be the impact on the SOM which is already on TMF 641 to manipulate the data to TMF 640 before sending it down to RFS nodes in topology ?

Had problem with uploading Images or any attachments. Tried using different browsers but doesn't seem to help.

Thank you for all the inputs.

Am trying to summarize my understanding and also sharing some new aspects that I did like to use to differentiate between TMF-641 and TMF-640. Please share your feedback.

Architecture Options:

Option-1: TMF-641 should be the Interface for BSS to request Services using Service Orders.

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Differences:

Differences between TMF-641 and TMF-640 in terms of functional capabilities. Architecture option should be chosen based on these capabilities and not extend the capabilities of TMF-640 to make it look like TMF-641 thus defeating the purpose of two(TMF-641 and TMF-640) standard Interfaces and making them ambiguous.

TMF-641

1. Operations(CRUD) on Service Order
2. Service Order can contain multiple Services
3. Support for Composition and Decomposition to RFS(s) and Resource(s)
4. Support for Long Running Business Processes, support for Inflight changes to Service Order

5. Provider of TMF-641 works with Service Inventory using TMF-638

6. TAM Functions supported: Design Solution, Assignments, Reservation, Manage Service Dependencies, Manage Service Instance, Address Validation, Plan for Service Configuration and Activation and Service Configuration & Activation(using TMF-640)
7. Orders can result in partial success and provide control to the consumer to handle/resolve the failed aspects.

 TMF-640

1. Operations(CRUD) on Service(typically RFS, however in case of Architecture Option2 can be Service which represents both CFS and RFS)
2. Request operates on Single Service
3. Support for Decomposition to Resource Provisioning requests on a single Resource only
4. Support for short lived Business Processes, no need for Inflight changes of Service Request.

5. Provider of TMF-640 doesn't need Service Inventory

6. TAM Functions supported: Service Configuration & Activation. Infrastructure(Devices & Networks) for the Service are expected to be pre-existing.
7. Service requests are atomic, complete success or complete failure.

Architecture Options:

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Scenario :- There is a SOM in the business and which is CFS and while sending down the notifications related to the service to the other RFS's in the domain ,but not in TMF640 structured way , Can we expect the CFS interface to send the payload or the data in already structured form i.e, more alike TMF 641 standard ?
What could be the impact on the SOM which is already on TMF 641 to manipulate the data to TMF 640 before sending it down to RFS nodes in topology ?

Had problem with uploading Images or any attachments. Tried using different browsers but doesn't seem to help.

Thank you for all the inputs.

Am trying to summarize my understanding and also sharing some new aspects that I did like to use to differentiate between TMF-641 and TMF-640. Please share your feedback.

Architecture Options:

Option-1: TMF-641 should be the Interface for BSS to request Services using Service Orders.

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Differences:

Differences between TMF-641 and TMF-640 in terms of functional capabilities. Architecture option should be chosen based on these capabilities and not extend the capabilities of TMF-640 to make it look like TMF-641 thus defeating the purpose of two(TMF-641 and TMF-640) standard Interfaces and making them ambiguous.

TMF-641

1. Operations(CRUD) on Service Order
2. Service Order can contain multiple Services
3. Support for Composition and Decomposition to RFS(s) and Resource(s)
4. Support for Long Running Business Processes, support for Inflight changes to Service Order

5. Provider of TMF-641 works with Service Inventory using TMF-638

6. TAM Functions supported: Design Solution, Assignments, Reservation, Manage Service Dependencies, Manage Service Instance, Address Validation, Plan for Service Configuration and Activation and Service Configuration & Activation(using TMF-640)
7. Orders can result in partial success and provide control to the consumer to handle/resolve the failed aspects.

 TMF-640

1. Operations(CRUD) on Service(typically RFS, however in case of Architecture Option2 can be Service which represents both CFS and RFS)
2. Request operates on Single Service
3. Support for Decomposition to Resource Provisioning requests on a single Resource only
4. Support for short lived Business Processes, no need for Inflight changes of Service Request.

5. Provider of TMF-640 doesn't need Service Inventory

6. TAM Functions supported: Service Configuration & Activation. Infrastructure(Devices & Networks) for the Service are expected to be pre-existing.
7. Service requests are atomic, complete success or complete failure.

Interested by the above post here @Srinivasa Vellanki. Would i be correct in suggesting that your belief is that a service should be able to have its state transitioned (TMF640) without a service order (TMF641). My view on this was that a service would only transition state via an order however long or short running that might be?

My thinking was quite closely aligned with @Koen Peeters , Is my below understanding incorrect?

Architecture Options:

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Scenario :- There is a SOM in the business and which is CFS and while sending down the notifications related to the service to the other RFS's in the domain ,but not in TMF640 structured way , Can we expect the CFS interface to send the payload or the data in already structured form i.e, more alike TMF 641 standard ?
What could be the impact on the SOM which is already on TMF 641 to manipulate the data to TMF 640 before sending it down to RFS nodes in topology ?

Had problem with uploading Images or any attachments. Tried using different browsers but doesn't seem to help.

Thank you for all the inputs.

Am trying to summarize my understanding and also sharing some new aspects that I did like to use to differentiate between TMF-641 and TMF-640. Please share your feedback.

Architecture Options:

Option-1: TMF-641 should be the Interface for BSS to request Services using Service Orders.

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Differences:

Differences between TMF-641 and TMF-640 in terms of functional capabilities. Architecture option should be chosen based on these capabilities and not extend the capabilities of TMF-640 to make it look like TMF-641 thus defeating the purpose of two(TMF-641 and TMF-640) standard Interfaces and making them ambiguous.

TMF-641

1. Operations(CRUD) on Service Order
2. Service Order can contain multiple Services
3. Support for Composition and Decomposition to RFS(s) and Resource(s)
4. Support for Long Running Business Processes, support for Inflight changes to Service Order

5. Provider of TMF-641 works with Service Inventory using TMF-638

6. TAM Functions supported: Design Solution, Assignments, Reservation, Manage Service Dependencies, Manage Service Instance, Address Validation, Plan for Service Configuration and Activation and Service Configuration & Activation(using TMF-640)
7. Orders can result in partial success and provide control to the consumer to handle/resolve the failed aspects.

 TMF-640

1. Operations(CRUD) on Service(typically RFS, however in case of Architecture Option2 can be Service which represents both CFS and RFS)
2. Request operates on Single Service
3. Support for Decomposition to Resource Provisioning requests on a single Resource only
4. Support for short lived Business Processes, no need for Inflight changes of Service Request.

5. Provider of TMF-640 doesn't need Service Inventory

6. TAM Functions supported: Service Configuration & Activation. Infrastructure(Devices & Networks) for the Service are expected to be pre-existing.
7. Service requests are atomic, complete success or complete failure.

Interested by the above post here @Srinivasa Vellanki. Would i be correct in suggesting that your belief is that a service should be able to have its state transitioned (TMF640) without a service order (TMF641). My view on this was that a service would only transition state via an order however long or short running that might be?

My thinking was quite closely aligned with @Koen Peeters , Is my below understanding incorrect?

Architecture Options:

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Scenario :- There is a SOM in the business and which is CFS and while sending down the notifications related to the service to the other RFS's in the domain ,but not in TMF640 structured way , Can we expect the CFS interface to send the payload or the data in already structured form i.e, more alike TMF 641 standard ?
What could be the impact on the SOM which is already on TMF 641 to manipulate the data to TMF 640 before sending it down to RFS nodes in topology ?

Had problem with uploading Images or any attachments. Tried using different browsers but doesn't seem to help.

Thank you for all the inputs.

Am trying to summarize my understanding and also sharing some new aspects that I did like to use to differentiate between TMF-641 and TMF-640. Please share your feedback.

Architecture Options:

Option-1: TMF-641 should be the Interface for BSS to request Services using Service Orders.

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Differences:

Differences between TMF-641 and TMF-640 in terms of functional capabilities. Architecture option should be chosen based on these capabilities and not extend the capabilities of TMF-640 to make it look like TMF-641 thus defeating the purpose of two(TMF-641 and TMF-640) standard Interfaces and making them ambiguous.

TMF-641

1. Operations(CRUD) on Service Order
2. Service Order can contain multiple Services
3. Support for Composition and Decomposition to RFS(s) and Resource(s)
4. Support for Long Running Business Processes, support for Inflight changes to Service Order

5. Provider of TMF-641 works with Service Inventory using TMF-638

6. TAM Functions supported: Design Solution, Assignments, Reservation, Manage Service Dependencies, Manage Service Instance, Address Validation, Plan for Service Configuration and Activation and Service Configuration & Activation(using TMF-640)
7. Orders can result in partial success and provide control to the consumer to handle/resolve the failed aspects.

 TMF-640

1. Operations(CRUD) on Service(typically RFS, however in case of Architecture Option2 can be Service which represents both CFS and RFS)
2. Request operates on Single Service
3. Support for Decomposition to Resource Provisioning requests on a single Resource only
4. Support for short lived Business Processes, no need for Inflight changes of Service Request.

5. Provider of TMF-640 doesn't need Service Inventory

6. TAM Functions supported: Service Configuration & Activation. Infrastructure(Devices & Networks) for the Service are expected to be pre-existing.
7. Service requests are atomic, complete success or complete failure.

Interested by the above post here @Srinivasa Vellanki. Would i be correct in suggesting that your belief is that a service should be able to have its state transitioned (TMF640) without a service order (TMF641). My view on this was that a service would only transition state via an order however long or short running that might be?

My thinking was quite closely aligned with @Koen Peeters , Is my below understanding incorrect?

Architecture Options:

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Scenario :- There is a SOM in the business and which is CFS and while sending down the notifications related to the service to the other RFS's in the domain ,but not in TMF640 structured way , Can we expect the CFS interface to send the payload or the data in already structured form i.e, more alike TMF 641 standard ?
What could be the impact on the SOM which is already on TMF 641 to manipulate the data to TMF 640 before sending it down to RFS nodes in topology ?

Had problem with uploading Images or any attachments. Tried using different browsers but doesn't seem to help.

Thank you for all the inputs.

Am trying to summarize my understanding and also sharing some new aspects that I did like to use to differentiate between TMF-641 and TMF-640. Please share your feedback.

Architecture Options:

Option-1: TMF-641 should be the Interface for BSS to request Services using Service Orders.

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Differences:

Differences between TMF-641 and TMF-640 in terms of functional capabilities. Architecture option should be chosen based on these capabilities and not extend the capabilities of TMF-640 to make it look like TMF-641 thus defeating the purpose of two(TMF-641 and TMF-640) standard Interfaces and making them ambiguous.

TMF-641

1. Operations(CRUD) on Service Order
2. Service Order can contain multiple Services
3. Support for Composition and Decomposition to RFS(s) and Resource(s)
4. Support for Long Running Business Processes, support for Inflight changes to Service Order

5. Provider of TMF-641 works with Service Inventory using TMF-638

6. TAM Functions supported: Design Solution, Assignments, Reservation, Manage Service Dependencies, Manage Service Instance, Address Validation, Plan for Service Configuration and Activation and Service Configuration & Activation(using TMF-640)
7. Orders can result in partial success and provide control to the consumer to handle/resolve the failed aspects.

 TMF-640

1. Operations(CRUD) on Service(typically RFS, however in case of Architecture Option2 can be Service which represents both CFS and RFS)
2. Request operates on Single Service
3. Support for Decomposition to Resource Provisioning requests on a single Resource only
4. Support for short lived Business Processes, no need for Inflight changes of Service Request.

5. Provider of TMF-640 doesn't need Service Inventory

6. TAM Functions supported: Service Configuration & Activation. Infrastructure(Devices & Networks) for the Service are expected to be pre-existing.
7. Service requests are atomic, complete success or complete failure.

Interested by the above post here @Srinivasa Vellanki. Would i be correct in suggesting that your belief is that a service should be able to have its state transitioned (TMF640) without a service order (TMF641). My view on this was that a service would only transition state via an order however long or short running that might be?

My thinking was quite closely aligned with @Koen Peeters , Is my below understanding incorrect?

Architecture Options:

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Scenario :- There is a SOM in the business and which is CFS and while sending down the notifications related to the service to the other RFS's in the domain ,but not in TMF640 structured way , Can we expect the CFS interface to send the payload or the data in already structured form i.e, more alike TMF 641 standard ?
What could be the impact on the SOM which is already on TMF 641 to manipulate the data to TMF 640 before sending it down to RFS nodes in topology ?

Had problem with uploading Images or any attachments. Tried using different browsers but doesn't seem to help.

Thank you for all the inputs.

Am trying to summarize my understanding and also sharing some new aspects that I did like to use to differentiate between TMF-641 and TMF-640. Please share your feedback.

Architecture Options:

Option-1: TMF-641 should be the Interface for BSS to request Services using Service Orders.

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Differences:

Differences between TMF-641 and TMF-640 in terms of functional capabilities. Architecture option should be chosen based on these capabilities and not extend the capabilities of TMF-640 to make it look like TMF-641 thus defeating the purpose of two(TMF-641 and TMF-640) standard Interfaces and making them ambiguous.

TMF-641

1. Operations(CRUD) on Service Order
2. Service Order can contain multiple Services
3. Support for Composition and Decomposition to RFS(s) and Resource(s)
4. Support for Long Running Business Processes, support for Inflight changes to Service Order

5. Provider of TMF-641 works with Service Inventory using TMF-638

6. TAM Functions supported: Design Solution, Assignments, Reservation, Manage Service Dependencies, Manage Service Instance, Address Validation, Plan for Service Configuration and Activation and Service Configuration & Activation(using TMF-640)
7. Orders can result in partial success and provide control to the consumer to handle/resolve the failed aspects.

 TMF-640

1. Operations(CRUD) on Service(typically RFS, however in case of Architecture Option2 can be Service which represents both CFS and RFS)
2. Request operates on Single Service
3. Support for Decomposition to Resource Provisioning requests on a single Resource only
4. Support for short lived Business Processes, no need for Inflight changes of Service Request.

5. Provider of TMF-640 doesn't need Service Inventory

6. TAM Functions supported: Service Configuration & Activation. Infrastructure(Devices & Networks) for the Service are expected to be pre-existing.
7. Service requests are atomic, complete success or complete failure.

Hi,

IG1224 captures considerations that a Service Designer has to undertake while selecting Service Fulfillment API (TMF640 v/s TMF61) for the service. IG1224 is an evolving document, please feel free to join us in the "ODA NaaS Service Fulfilment User Guide (ODA1)" call for discussion around this topic or if you want to contribute towards its evolution.

Jist from IG1224 below

• Type 1: Physical infrastructure deployment required for the provisioning of service. This involves a complex orchestration process with a long lead time.  This provisioning may require manual tasks, integration with a third party via order management process, including email, calls, etc. TMF641 is better suited to support this type of provisioning.
• Type 2: Existing Infrastructure will be used for provisioning the service. There are two variations identified in Type 2.
• Type 2a:  Rapid activation: The provisioning is performed by zero-touch orchestration. This may also include seamless integration with third-party providers. Provisioning these services can be performed with a shorter lead time (both synchronous & asynchronous).  TMF640 is found best suited to support this type of provisioning.
• Type 2b: Complex activation: The provisioning may include complex orchestration with a long lead time. This type may include composite services which span across multiple domains with different types of provisioning patterns and complex activation dependencies.  This provisioning may also require manual tasks and integration with a third party via order management process, including email, calls, etc.  TMF641 is found best suited to support this type of provisioning.

------------------------------
Abdul Majid Hussain
Telstra Corporation
------------------------------


Original Message:
Sent: Jun 22, 2021 21:04
From: Srinivasa Vellanki
Subject: TMF-641 vs TMF-640

@Dave Whitfield ​
Agree that TMF-640 should not result in Service State change. It was my mistake to think that TMF-640 might also enable some level of Service State change. Thank you for the picture this is very helpful.

Regards
Srinivas

------------------------------
Srinivasa Vellanki
Amdocs Management Limited


Original Message:
Sent: Jun 21, 2021 07:23
From: David Whitfield
Subject: TMF-641 vs TMF-640

Interested by the above post here @Srinivasa Vellanki. Would i be correct in suggesting that your belief is that a service should be able to have its state transitioned (TMF640) without a service order (TMF641). My view on this was that a service would only transition state via an order however long or short running that might be?

My thinking was quite closely aligned with @Koen Peeters , Is my below understanding incorrect?

Architecture Options:

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Scenario :- There is a SOM in the business and which is CFS and while sending down the notifications related to the service to the other RFS's in the domain ,but not in TMF640 structured way , Can we expect the CFS interface to send the payload or the data in already structured form i.e, more alike TMF 641 standard ?
What could be the impact on the SOM which is already on TMF 641 to manipulate the data to TMF 640 before sending it down to RFS nodes in topology ?

Had problem with uploading Images or any attachments. Tried using different browsers but doesn't seem to help.

Thank you for all the inputs.

Am trying to summarize my understanding and also sharing some new aspects that I did like to use to differentiate between TMF-641 and TMF-640. Please share your feedback.

Architecture Options:

Option-1: TMF-641 should be the Interface for BSS to request Services using Service Orders.

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Differences:

Differences between TMF-641 and TMF-640 in terms of functional capabilities. Architecture option should be chosen based on these capabilities and not extend the capabilities of TMF-640 to make it look like TMF-641 thus defeating the purpose of two(TMF-641 and TMF-640) standard Interfaces and making them ambiguous.

TMF-641

1. Operations(CRUD) on Service Order
2. Service Order can contain multiple Services
3. Support for Composition and Decomposition to RFS(s) and Resource(s)
4. Support for Long Running Business Processes, support for Inflight changes to Service Order

5. Provider of TMF-641 works with Service Inventory using TMF-638

6. TAM Functions supported: Design Solution, Assignments, Reservation, Manage Service Dependencies, Manage Service Instance, Address Validation, Plan for Service Configuration and Activation and Service Configuration & Activation(using TMF-640)
7. Orders can result in partial success and provide control to the consumer to handle/resolve the failed aspects.

 TMF-640

1. Operations(CRUD) on Service(typically RFS, however in case of Architecture Option2 can be Service which represents both CFS and RFS)
2. Request operates on Single Service
3. Support for Decomposition to Resource Provisioning requests on a single Resource only
4. Support for short lived Business Processes, no need for Inflight changes of Service Request.

5. Provider of TMF-640 doesn't need Service Inventory

6. TAM Functions supported: Service Configuration & Activation. Infrastructure(Devices & Networks) for the Service are expected to be pre-existing.
7. Service requests are atomic, complete success or complete failure.

Hi,

IG1224 captures considerations that a Service Designer has to undertake while selecting Service Fulfillment API (TMF640 v/s TMF61) for the service. IG1224 is an evolving document, please feel free to join us in the "ODA NaaS Service Fulfilment User Guide (ODA1)" call for discussion around this topic or if you want to contribute towards its evolution.

Jist from IG1224 below

• Type 1: Physical infrastructure deployment required for the provisioning of service. This involves a complex orchestration process with a long lead time.  This provisioning may require manual tasks, integration with a third party via order management process, including email, calls, etc. TMF641 is better suited to support this type of provisioning.
• Type 2: Existing Infrastructure will be used for provisioning the service. There are two variations identified in Type 2.
• Type 2a:  Rapid activation: The provisioning is performed by zero-touch orchestration. This may also include seamless integration with third-party providers. Provisioning these services can be performed with a shorter lead time (both synchronous & asynchronous).  TMF640 is found best suited to support this type of provisioning.
• Type 2b: Complex activation: The provisioning may include complex orchestration with a long lead time. This type may include composite services which span across multiple domains with different types of provisioning patterns and complex activation dependencies.  This provisioning may also require manual tasks and integration with a third party via order management process, including email, calls, etc.  TMF641 is found best suited to support this type of provisioning.

------------------------------
Abdul Majid Hussain
Telstra Corporation
------------------------------


Original Message:
Sent: Jun 22, 2021 21:04
From: Srinivasa Vellanki
Subject: TMF-641 vs TMF-640

@Dave Whitfield ​
Agree that TMF-640 should not result in Service State change. It was my mistake to think that TMF-640 might also enable some level of Service State change. Thank you for the picture this is very helpful.

Regards
Srinivas

------------------------------
Srinivasa Vellanki
Amdocs Management Limited


Original Message:
Sent: Jun 21, 2021 07:23
From: David Whitfield
Subject: TMF-641 vs TMF-640

Interested by the above post here @Srinivasa Vellanki. Would i be correct in suggesting that your belief is that a service should be able to have its state transitioned (TMF640) without a service order (TMF641). My view on this was that a service would only transition state via an order however long or short running that might be?

My thinking was quite closely aligned with @Koen Peeters , Is my below understanding incorrect?

Architecture Options:

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Scenario :- There is a SOM in the business and which is CFS and while sending down the notifications related to the service to the other RFS's in the domain ,but not in TMF640 structured way , Can we expect the CFS interface to send the payload or the data in already structured form i.e, more alike TMF 641 standard ?
What could be the impact on the SOM which is already on TMF 641 to manipulate the data to TMF 640 before sending it down to RFS nodes in topology ?

Had problem with uploading Images or any attachments. Tried using different browsers but doesn't seem to help.

Thank you for all the inputs.

Am trying to summarize my understanding and also sharing some new aspects that I did like to use to differentiate between TMF-641 and TMF-640. Please share your feedback.

Architecture Options:

Option-1: TMF-641 should be the Interface for BSS to request Services using Service Orders.

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Differences:

Differences between TMF-641 and TMF-640 in terms of functional capabilities. Architecture option should be chosen based on these capabilities and not extend the capabilities of TMF-640 to make it look like TMF-641 thus defeating the purpose of two(TMF-641 and TMF-640) standard Interfaces and making them ambiguous.

TMF-641

1. Operations(CRUD) on Service Order
2. Service Order can contain multiple Services
3. Support for Composition and Decomposition to RFS(s) and Resource(s)
4. Support for Long Running Business Processes, support for Inflight changes to Service Order

5. Provider of TMF-641 works with Service Inventory using TMF-638

6. TAM Functions supported: Design Solution, Assignments, Reservation, Manage Service Dependencies, Manage Service Instance, Address Validation, Plan for Service Configuration and Activation and Service Configuration & Activation(using TMF-640)
7. Orders can result in partial success and provide control to the consumer to handle/resolve the failed aspects.

 TMF-640

1. Operations(CRUD) on Service(typically RFS, however in case of Architecture Option2 can be Service which represents both CFS and RFS)
2. Request operates on Single Service
3. Support for Decomposition to Resource Provisioning requests on a single Resource only
4. Support for short lived Business Processes, no need for Inflight changes of Service Request.

5. Provider of TMF-640 doesn't need Service Inventory

6. TAM Functions supported: Service Configuration & Activation. Infrastructure(Devices & Networks) for the Service are expected to be pre-existing.
7. Service requests are atomic, complete success or complete failure.

Hi,

IG1224 captures considerations that a Service Designer has to undertake while selecting Service Fulfillment API (TMF640 v/s TMF61) for the service. IG1224 is an evolving document, please feel free to join us in the "ODA NaaS Service Fulfilment User Guide (ODA1)" call for discussion around this topic or if you want to contribute towards its evolution.

Jist from IG1224 below

• Type 1: Physical infrastructure deployment required for the provisioning of service. This involves a complex orchestration process with a long lead time.  This provisioning may require manual tasks, integration with a third party via order management process, including email, calls, etc. TMF641 is better suited to support this type of provisioning.
• Type 2: Existing Infrastructure will be used for provisioning the service. There are two variations identified in Type 2.
• Type 2a:  Rapid activation: The provisioning is performed by zero-touch orchestration. This may also include seamless integration with third-party providers. Provisioning these services can be performed with a shorter lead time (both synchronous & asynchronous).  TMF640 is found best suited to support this type of provisioning.
• Type 2b: Complex activation: The provisioning may include complex orchestration with a long lead time. This type may include composite services which span across multiple domains with different types of provisioning patterns and complex activation dependencies.  This provisioning may also require manual tasks and integration with a third party via order management process, including email, calls, etc.  TMF641 is found best suited to support this type of provisioning.

------------------------------
Abdul Majid Hussain
Telstra Corporation


Original Message:
Sent: Jun 22, 2021 21:04
From: Srinivasa Vellanki
Subject: TMF-641 vs TMF-640

@Dave Whitfield ​
Agree that TMF-640 should not result in Service State change. It was my mistake to think that TMF-640 might also enable some level of Service State change. Thank you for the picture this is very helpful.

Regards
Srinivas

------------------------------
Srinivasa Vellanki
Amdocs Management Limited


Original Message:
Sent: Jun 21, 2021 07:23
From: David Whitfield
Subject: TMF-641 vs TMF-640

Interested by the above post here @Srinivasa Vellanki. Would i be correct in suggesting that your belief is that a service should be able to have its state transitioned (TMF640) without a service order (TMF641). My view on this was that a service would only transition state via an order however long or short running that might be?

My thinking was quite closely aligned with @Koen Peeters , Is my below understanding incorrect?

Architecture Options:

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Scenario :- There is a SOM in the business and which is CFS and while sending down the notifications related to the service to the other RFS's in the domain ,but not in TMF640 structured way , Can we expect the CFS interface to send the payload or the data in already structured form i.e, more alike TMF 641 standard ?
What could be the impact on the SOM which is already on TMF 641 to manipulate the data to TMF 640 before sending it down to RFS nodes in topology ?

Had problem with uploading Images or any attachments. Tried using different browsers but doesn't seem to help.

Thank you for all the inputs.

Am trying to summarize my understanding and also sharing some new aspects that I did like to use to differentiate between TMF-641 and TMF-640. Please share your feedback.

Architecture Options:

Option-1: TMF-641 should be the Interface for BSS to request Services using Service Orders.

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Differences:

Differences between TMF-641 and TMF-640 in terms of functional capabilities. Architecture option should be chosen based on these capabilities and not extend the capabilities of TMF-640 to make it look like TMF-641 thus defeating the purpose of two(TMF-641 and TMF-640) standard Interfaces and making them ambiguous.

TMF-641

1. Operations(CRUD) on Service Order
2. Service Order can contain multiple Services
3. Support for Composition and Decomposition to RFS(s) and Resource(s)
4. Support for Long Running Business Processes, support for Inflight changes to Service Order

5. Provider of TMF-641 works with Service Inventory using TMF-638

6. TAM Functions supported: Design Solution, Assignments, Reservation, Manage Service Dependencies, Manage Service Instance, Address Validation, Plan for Service Configuration and Activation and Service Configuration & Activation(using TMF-640)
7. Orders can result in partial success and provide control to the consumer to handle/resolve the failed aspects.

 TMF-640

1. Operations(CRUD) on Service(typically RFS, however in case of Architecture Option2 can be Service which represents both CFS and RFS)
2. Request operates on Single Service
3. Support for Decomposition to Resource Provisioning requests on a single Resource only
4. Support for short lived Business Processes, no need for Inflight changes of Service Request.

5. Provider of TMF-640 doesn't need Service Inventory

6. TAM Functions supported: Service Configuration & Activation. Infrastructure(Devices & Networks) for the Service are expected to be pre-existing.
7. Service requests are atomic, complete success or complete failure.

ODA NaaS Service Fulfilment User Guide (ODA1)



Tue 6/29/2021 8:00 AM - 9:00 AM View series



https://us02web.zoom.us/j/89097568744?pwd=eWgreE5UVE9haGlVS0lCbXpwREcvUT09



ODA NaaS Service Fulfilment User Guide (ODA1)

Meeting rescheduled to accommodate US and Australian participants.

Join Zoom Meeting

https://us02web.zoom.us/j/89097568744?pwd=eWgreE5UVE9haGlVS0lCbXpwREcvUT09

Meeting ID: 890 9756 8744

Passcode: 056043

OR

Dial by your location

Find your local number: https://us02web.zoom.us/u/kdKP4r774b

Hi,

IG1224 captures considerations that a Service Designer has to undertake while selecting Service Fulfillment API (TMF640 v/s TMF61) for the service. IG1224 is an evolving document, please feel free to join us in the "ODA NaaS Service Fulfilment User Guide (ODA1)" call for discussion around this topic or if you want to contribute towards its evolution.

Jist from IG1224 below

• Type 1: Physical infrastructure deployment required for the provisioning of service. This involves a complex orchestration process with a long lead time.  This provisioning may require manual tasks, integration with a third party via order management process, including email, calls, etc. TMF641 is better suited to support this type of provisioning.
• Type 2: Existing Infrastructure will be used for provisioning the service. There are two variations identified in Type 2.
• Type 2a:  Rapid activation: The provisioning is performed by zero-touch orchestration. This may also include seamless integration with third-party providers. Provisioning these services can be performed with a shorter lead time (both synchronous & asynchronous).  TMF640 is found best suited to support this type of provisioning.
• Type 2b: Complex activation: The provisioning may include complex orchestration with a long lead time. This type may include composite services which span across multiple domains with different types of provisioning patterns and complex activation dependencies.  This provisioning may also require manual tasks and integration with a third party via order management process, including email, calls, etc.  TMF641 is found best suited to support this type of provisioning.

------------------------------
Abdul Majid Hussain
Telstra Corporation


Original Message:
Sent: Jun 22, 2021 21:04
From: Srinivasa Vellanki
Subject: TMF-641 vs TMF-640

@Dave Whitfield ​
Agree that TMF-640 should not result in Service State change. It was my mistake to think that TMF-640 might also enable some level of Service State change. Thank you for the picture this is very helpful.

Regards
Srinivas

------------------------------
Srinivasa Vellanki
Amdocs Management Limited


Original Message:
Sent: Jun 21, 2021 07:23
From: David Whitfield
Subject: TMF-641 vs TMF-640

Interested by the above post here @Srinivasa Vellanki. Would i be correct in suggesting that your belief is that a service should be able to have its state transitioned (TMF640) without a service order (TMF641). My view on this was that a service would only transition state via an order however long or short running that might be?

My thinking was quite closely aligned with @Koen Peeters , Is my below understanding incorrect?

Architecture Options:

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Scenario :- There is a SOM in the business and which is CFS and while sending down the notifications related to the service to the other RFS's in the domain ,but not in TMF640 structured way , Can we expect the CFS interface to send the payload or the data in already structured form i.e, more alike TMF 641 standard ?
What could be the impact on the SOM which is already on TMF 641 to manipulate the data to TMF 640 before sending it down to RFS nodes in topology ?

Had problem with uploading Images or any attachments. Tried using different browsers but doesn't seem to help.

Thank you for all the inputs.

Am trying to summarize my understanding and also sharing some new aspects that I did like to use to differentiate between TMF-641 and TMF-640. Please share your feedback.

Architecture Options:

Option-1: TMF-641 should be the Interface for BSS to request Services using Service Orders.

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Differences:

Differences between TMF-641 and TMF-640 in terms of functional capabilities. Architecture option should be chosen based on these capabilities and not extend the capabilities of TMF-640 to make it look like TMF-641 thus defeating the purpose of two(TMF-641 and TMF-640) standard Interfaces and making them ambiguous.

TMF-641

1. Operations(CRUD) on Service Order
2. Service Order can contain multiple Services
3. Support for Composition and Decomposition to RFS(s) and Resource(s)
4. Support for Long Running Business Processes, support for Inflight changes to Service Order

5. Provider of TMF-641 works with Service Inventory using TMF-638

6. TAM Functions supported: Design Solution, Assignments, Reservation, Manage Service Dependencies, Manage Service Instance, Address Validation, Plan for Service Configuration and Activation and Service Configuration & Activation(using TMF-640)
7. Orders can result in partial success and provide control to the consumer to handle/resolve the failed aspects.

 TMF-640

1. Operations(CRUD) on Service(typically RFS, however in case of Architecture Option2 can be Service which represents both CFS and RFS)
2. Request operates on Single Service
3. Support for Decomposition to Resource Provisioning requests on a single Resource only
4. Support for short lived Business Processes, no need for Inflight changes of Service Request.

5. Provider of TMF-640 doesn't need Service Inventory

6. TAM Functions supported: Service Configuration & Activation. Infrastructure(Devices & Networks) for the Service are expected to be pre-existing.
7. Service requests are atomic, complete success or complete failure.

Hi,

IG1224 captures considerations that a Service Designer has to undertake while selecting Service Fulfillment API (TMF640 v/s TMF61) for the service. IG1224 is an evolving document, please feel free to join us in the "ODA NaaS Service Fulfilment User Guide (ODA1)" call for discussion around this topic or if you want to contribute towards its evolution.

Jist from IG1224 below

• Type 1: Physical infrastructure deployment required for the provisioning of service. This involves a complex orchestration process with a long lead time.  This provisioning may require manual tasks, integration with a third party via order management process, including email, calls, etc. TMF641 is better suited to support this type of provisioning.
• Type 2: Existing Infrastructure will be used for provisioning the service. There are two variations identified in Type 2.
• Type 2a:  Rapid activation: The provisioning is performed by zero-touch orchestration. This may also include seamless integration with third-party providers. Provisioning these services can be performed with a shorter lead time (both synchronous & asynchronous).  TMF640 is found best suited to support this type of provisioning.
• Type 2b: Complex activation: The provisioning may include complex orchestration with a long lead time. This type may include composite services which span across multiple domains with different types of provisioning patterns and complex activation dependencies.  This provisioning may also require manual tasks and integration with a third party via order management process, including email, calls, etc.  TMF641 is found best suited to support this type of provisioning.

------------------------------
Abdul Majid Hussain
Telstra Corporation
------------------------------


Original Message:
Sent: Jun 22, 2021 21:04
From: Srinivasa Vellanki
Subject: TMF-641 vs TMF-640

@Dave Whitfield ​
Agree that TMF-640 should not result in Service State change. It was my mistake to think that TMF-640 might also enable some level of Service State change. Thank you for the picture this is very helpful.

Regards
Srinivas

------------------------------
Srinivasa Vellanki
Amdocs Management Limited


Original Message:
Sent: Jun 21, 2021 07:23
From: David Whitfield
Subject: TMF-641 vs TMF-640

Interested by the above post here @Srinivasa Vellanki. Would i be correct in suggesting that your belief is that a service should be able to have its state transitioned (TMF640) without a service order (TMF641). My view on this was that a service would only transition state via an order however long or short running that might be?

My thinking was quite closely aligned with @Koen Peeters , Is my below understanding incorrect?

Architecture Options:

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Scenario :- There is a SOM in the business and which is CFS and while sending down the notifications related to the service to the other RFS's in the domain ,but not in TMF640 structured way , Can we expect the CFS interface to send the payload or the data in already structured form i.e, more alike TMF 641 standard ?
What could be the impact on the SOM which is already on TMF 641 to manipulate the data to TMF 640 before sending it down to RFS nodes in topology ?

Had problem with uploading Images or any attachments. Tried using different browsers but doesn't seem to help.

Thank you for all the inputs.

Am trying to summarize my understanding and also sharing some new aspects that I did like to use to differentiate between TMF-641 and TMF-640. Please share your feedback.

Architecture Options:

Option-1: TMF-641 should be the Interface for BSS to request Services using Service Orders.

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Differences:

Differences between TMF-641 and TMF-640 in terms of functional capabilities. Architecture option should be chosen based on these capabilities and not extend the capabilities of TMF-640 to make it look like TMF-641 thus defeating the purpose of two(TMF-641 and TMF-640) standard Interfaces and making them ambiguous.

TMF-641

1. Operations(CRUD) on Service Order
2. Service Order can contain multiple Services
3. Support for Composition and Decomposition to RFS(s) and Resource(s)
4. Support for Long Running Business Processes, support for Inflight changes to Service Order

5. Provider of TMF-641 works with Service Inventory using TMF-638

6. TAM Functions supported: Design Solution, Assignments, Reservation, Manage Service Dependencies, Manage Service Instance, Address Validation, Plan for Service Configuration and Activation and Service Configuration & Activation(using TMF-640)
7. Orders can result in partial success and provide control to the consumer to handle/resolve the failed aspects.

 TMF-640

1. Operations(CRUD) on Service(typically RFS, however in case of Architecture Option2 can be Service which represents both CFS and RFS)
2. Request operates on Single Service
3. Support for Decomposition to Resource Provisioning requests on a single Resource only
4. Support for short lived Business Processes, no need for Inflight changes of Service Request.

5. Provider of TMF-640 doesn't need Service Inventory

6. TAM Functions supported: Service Configuration & Activation. Infrastructure(Devices & Networks) for the Service are expected to be pre-existing.
7. Service requests are atomic, complete success or complete failure.

Hi,

IG1224 captures considerations that a Service Designer has to undertake while selecting Service Fulfillment API (TMF640 v/s TMF61) for the service. IG1224 is an evolving document, please feel free to join us in the "ODA NaaS Service Fulfilment User Guide (ODA1)" call for discussion around this topic or if you want to contribute towards its evolution.

Jist from IG1224 below

• Type 1: Physical infrastructure deployment required for the provisioning of service. This involves a complex orchestration process with a long lead time.  This provisioning may require manual tasks, integration with a third party via order management process, including email, calls, etc. TMF641 is better suited to support this type of provisioning.
• Type 2: Existing Infrastructure will be used for provisioning the service. There are two variations identified in Type 2.
• Type 2a:  Rapid activation: The provisioning is performed by zero-touch orchestration. This may also include seamless integration with third-party providers. Provisioning these services can be performed with a shorter lead time (both synchronous & asynchronous).  TMF640 is found best suited to support this type of provisioning.
• Type 2b: Complex activation: The provisioning may include complex orchestration with a long lead time. This type may include composite services which span across multiple domains with different types of provisioning patterns and complex activation dependencies.  This provisioning may also require manual tasks and integration with a third party via order management process, including email, calls, etc.  TMF641 is found best suited to support this type of provisioning.

------------------------------
Abdul Majid Hussain
Telstra Corporation
------------------------------


Original Message:
Sent: Jun 22, 2021 21:04
From: Srinivasa Vellanki
Subject: TMF-641 vs TMF-640

@Dave Whitfield ​
Agree that TMF-640 should not result in Service State change. It was my mistake to think that TMF-640 might also enable some level of Service State change. Thank you for the picture this is very helpful.

Regards
Srinivas

------------------------------
Srinivasa Vellanki
Amdocs Management Limited


Original Message:
Sent: Jun 21, 2021 07:23
From: David Whitfield
Subject: TMF-641 vs TMF-640

Interested by the above post here @Srinivasa Vellanki. Would i be correct in suggesting that your belief is that a service should be able to have its state transitioned (TMF640) without a service order (TMF641). My view on this was that a service would only transition state via an order however long or short running that might be?

My thinking was quite closely aligned with @Koen Peeters , Is my below understanding incorrect?

​

------------------------------
David Whitfield
TalkTalk Group


Original Message:
Sent: Nov 22, 2020 05:59
From: Srinivasa Vellanki
Subject: TMF-641 vs TMF-640

Hi Manisha,

Am not very sure I follow the question..

If the question is if there is a SOM managing the CFS Service Order, what would it need to do to send a RFS Service Order to another SOM?
Typically SOM has ability to decompose a CFS Service Order to RFS Service Orders and delegate the RFS Service Order to other SOM using TMF-641.

Please note the options listed were about two years ago and my thinking/opinion has evolved since then based on new learnings.

TMF-640 - Used to transition a Service (CFS or RFS) from one state to anther.
TMF-641 - Used to fulfill a CFS Service using other RFS Service by delegating a RFS Service Order as supported by other SOM.

Note CFS & RFS are to be modelled properly, they don't represent systems or organizations in Service Provider setup. CFS & RFS are based on actual Telco Services.

------------------------------
Srinivasa Vellanki
Amdocs Management Limited


Original Message:
Sent: Nov 10, 2020 22:04
From: MANISHA MALLA
Subject: TMF-641 vs TMF-640

Hi Srinivasa,et al,

Regarding the 2nd  Option here:-

Architecture Options:

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Scenario :- There is a SOM in the business and which is CFS and while sending down the notifications related to the service to the other RFS's in the domain ,but not in TMF640 structured way , Can we expect the CFS interface to send the payload or the data in already structured form i.e, more alike TMF 641 standard ?
What could be the impact on the SOM which is already on TMF 641 to manipulate the data to TMF 640 before sending it down to RFS nodes in topology ?

Regards
Manisha

------------------------------
MANISHA MALLA
Telstra Corporation


Original Message:
Sent: Dec 05, 2018 12:53
From: Srinivasa Vellanki
Subject: TMF-641 vs TMF-640

Had problem with uploading Images or any attachments. Tried using different browsers but doesn't seem to help.

Thank you for all the inputs.

Am trying to summarize my understanding and also sharing some new aspects that I did like to use to differentiate between TMF-641 and TMF-640. Please share your feedback.

Architecture Options:

Option-1: TMF-641 should be the Interface for BSS to request Services using Service Orders.

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Differences:

Differences between TMF-641 and TMF-640 in terms of functional capabilities. Architecture option should be chosen based on these capabilities and not extend the capabilities of TMF-640 to make it look like TMF-641 thus defeating the purpose of two(TMF-641 and TMF-640) standard Interfaces and making them ambiguous.

TMF-641

1. Operations(CRUD) on Service Order
2. Service Order can contain multiple Services
3. Support for Composition and Decomposition to RFS(s) and Resource(s)
4. Support for Long Running Business Processes, support for Inflight changes to Service Order

5. Provider of TMF-641 works with Service Inventory using TMF-638

6. TAM Functions supported: Design Solution, Assignments, Reservation, Manage Service Dependencies, Manage Service Instance, Address Validation, Plan for Service Configuration and Activation and Service Configuration & Activation(using TMF-640)
7. Orders can result in partial success and provide control to the consumer to handle/resolve the failed aspects.

 TMF-640

1. Operations(CRUD) on Service(typically RFS, however in case of Architecture Option2 can be Service which represents both CFS and RFS)
2. Request operates on Single Service
3. Support for Decomposition to Resource Provisioning requests on a single Resource only
4. Support for short lived Business Processes, no need for Inflight changes of Service Request.

5. Provider of TMF-640 doesn't need Service Inventory

6. TAM Functions supported: Service Configuration & Activation. Infrastructure(Devices & Networks) for the Service are expected to be pre-existing.
7. Service requests are atomic, complete success or complete failure.

------------------------------
Srinivasa Vellanki
Amdocs Management Limited

Interested by the above post here @Srinivasa Vellanki. Would i be correct in suggesting that your belief is that a service should be able to have its state transitioned (TMF640) without a service order (TMF641). My view on this was that a service would only transition state via an order however long or short running that might be?

My thinking was quite closely aligned with @Koen Peeters , Is my below understanding incorrect?

Architecture Options:

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Scenario :- There is a SOM in the business and which is CFS and while sending down the notifications related to the service to the other RFS's in the domain ,but not in TMF640 structured way , Can we expect the CFS interface to send the payload or the data in already structured form i.e, more alike TMF 641 standard ?
What could be the impact on the SOM which is already on TMF 641 to manipulate the data to TMF 640 before sending it down to RFS nodes in topology ?

Had problem with uploading Images or any attachments. Tried using different browsers but doesn't seem to help.

Thank you for all the inputs.

Am trying to summarize my understanding and also sharing some new aspects that I did like to use to differentiate between TMF-641 and TMF-640. Please share your feedback.

Architecture Options:

Option-1: TMF-641 should be the Interface for BSS to request Services using Service Orders.

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Differences:

Differences between TMF-641 and TMF-640 in terms of functional capabilities. Architecture option should be chosen based on these capabilities and not extend the capabilities of TMF-640 to make it look like TMF-641 thus defeating the purpose of two(TMF-641 and TMF-640) standard Interfaces and making them ambiguous.

TMF-641

1. Operations(CRUD) on Service Order
2. Service Order can contain multiple Services
3. Support for Composition and Decomposition to RFS(s) and Resource(s)
4. Support for Long Running Business Processes, support for Inflight changes to Service Order

5. Provider of TMF-641 works with Service Inventory using TMF-638

6. TAM Functions supported: Design Solution, Assignments, Reservation, Manage Service Dependencies, Manage Service Instance, Address Validation, Plan for Service Configuration and Activation and Service Configuration & Activation(using TMF-640)
7. Orders can result in partial success and provide control to the consumer to handle/resolve the failed aspects.

 TMF-640

1. Operations(CRUD) on Service(typically RFS, however in case of Architecture Option2 can be Service which represents both CFS and RFS)
2. Request operates on Single Service
3. Support for Decomposition to Resource Provisioning requests on a single Resource only
4. Support for short lived Business Processes, no need for Inflight changes of Service Request.

5. Provider of TMF-640 doesn't need Service Inventory

6. TAM Functions supported: Service Configuration & Activation. Infrastructure(Devices & Networks) for the Service are expected to be pre-existing.
7. Service requests are atomic, complete success or complete failure.

Interested by the above post here @Srinivasa Vellanki. Would i be correct in suggesting that your belief is that a service should be able to have its state transitioned (TMF640) without a service order (TMF641). My view on this was that a service would only transition state via an order however long or short running that might be?

My thinking was quite closely aligned with @Koen Peeters , Is my below understanding incorrect?

Architecture Options:

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Scenario :- There is a SOM in the business and which is CFS and while sending down the notifications related to the service to the other RFS's in the domain ,but not in TMF640 structured way , Can we expect the CFS interface to send the payload or the data in already structured form i.e, more alike TMF 641 standard ?
What could be the impact on the SOM which is already on TMF 641 to manipulate the data to TMF 640 before sending it down to RFS nodes in topology ?

Had problem with uploading Images or any attachments. Tried using different browsers but doesn't seem to help.

Thank you for all the inputs.

Am trying to summarize my understanding and also sharing some new aspects that I did like to use to differentiate between TMF-641 and TMF-640. Please share your feedback.

Architecture Options:

Option-1: TMF-641 should be the Interface for BSS to request Services using Service Orders.

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Differences:

Differences between TMF-641 and TMF-640 in terms of functional capabilities. Architecture option should be chosen based on these capabilities and not extend the capabilities of TMF-640 to make it look like TMF-641 thus defeating the purpose of two(TMF-641 and TMF-640) standard Interfaces and making them ambiguous.

TMF-641

1. Operations(CRUD) on Service Order
2. Service Order can contain multiple Services
3. Support for Composition and Decomposition to RFS(s) and Resource(s)
4. Support for Long Running Business Processes, support for Inflight changes to Service Order

5. Provider of TMF-641 works with Service Inventory using TMF-638

6. TAM Functions supported: Design Solution, Assignments, Reservation, Manage Service Dependencies, Manage Service Instance, Address Validation, Plan for Service Configuration and Activation and Service Configuration & Activation(using TMF-640)
7. Orders can result in partial success and provide control to the consumer to handle/resolve the failed aspects.

 TMF-640

1. Operations(CRUD) on Service(typically RFS, however in case of Architecture Option2 can be Service which represents both CFS and RFS)
2. Request operates on Single Service
3. Support for Decomposition to Resource Provisioning requests on a single Resource only
4. Support for short lived Business Processes, no need for Inflight changes of Service Request.

5. Provider of TMF-640 doesn't need Service Inventory

6. TAM Functions supported: Service Configuration & Activation. Infrastructure(Devices & Networks) for the Service are expected to be pre-existing.
7. Service requests are atomic, complete success or complete failure.

Interested by the above post here @Srinivasa Vellanki. Would i be correct in suggesting that your belief is that a service should be able to have its state transitioned (TMF640) without a service order (TMF641). My view on this was that a service would only transition state via an order however long or short running that might be?

My thinking was quite closely aligned with @Koen Peeters , Is my below understanding incorrect?

Architecture Options:

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Scenario :- There is a SOM in the business and which is CFS and while sending down the notifications related to the service to the other RFS's in the domain ,but not in TMF640 structured way , Can we expect the CFS interface to send the payload or the data in already structured form i.e, more alike TMF 641 standard ?
What could be the impact on the SOM which is already on TMF 641 to manipulate the data to TMF 640 before sending it down to RFS nodes in topology ?

Had problem with uploading Images or any attachments. Tried using different browsers but doesn't seem to help.

Thank you for all the inputs.

Am trying to summarize my understanding and also sharing some new aspects that I did like to use to differentiate between TMF-641 and TMF-640. Please share your feedback.

Architecture Options:

Option-1: TMF-641 should be the Interface for BSS to request Services using Service Orders.

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Differences:

Differences between TMF-641 and TMF-640 in terms of functional capabilities. Architecture option should be chosen based on these capabilities and not extend the capabilities of TMF-640 to make it look like TMF-641 thus defeating the purpose of two(TMF-641 and TMF-640) standard Interfaces and making them ambiguous.

TMF-641

1. Operations(CRUD) on Service Order
2. Service Order can contain multiple Services
3. Support for Composition and Decomposition to RFS(s) and Resource(s)
4. Support for Long Running Business Processes, support for Inflight changes to Service Order

5. Provider of TMF-641 works with Service Inventory using TMF-638

6. TAM Functions supported: Design Solution, Assignments, Reservation, Manage Service Dependencies, Manage Service Instance, Address Validation, Plan for Service Configuration and Activation and Service Configuration & Activation(using TMF-640)
7. Orders can result in partial success and provide control to the consumer to handle/resolve the failed aspects.

 TMF-640

1. Operations(CRUD) on Service(typically RFS, however in case of Architecture Option2 can be Service which represents both CFS and RFS)
2. Request operates on Single Service
3. Support for Decomposition to Resource Provisioning requests on a single Resource only
4. Support for short lived Business Processes, no need for Inflight changes of Service Request.

5. Provider of TMF-640 doesn't need Service Inventory

6. TAM Functions supported: Service Configuration & Activation. Infrastructure(Devices & Networks) for the Service are expected to be pre-existing.
7. Service requests are atomic, complete success or complete failure.

Interested by the above post here @Srinivasa Vellanki. Would i be correct in suggesting that your belief is that a service should be able to have its state transitioned (TMF640) without a service order (TMF641). My view on this was that a service would only transition state via an order however long or short running that might be?

My thinking was quite closely aligned with @Koen Peeters , Is my below understanding incorrect?

Architecture Options:

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Scenario :- There is a SOM in the business and which is CFS and while sending down the notifications related to the service to the other RFS's in the domain ,but not in TMF640 structured way , Can we expect the CFS interface to send the payload or the data in already structured form i.e, more alike TMF 641 standard ?
What could be the impact on the SOM which is already on TMF 641 to manipulate the data to TMF 640 before sending it down to RFS nodes in topology ?

Had problem with uploading Images or any attachments. Tried using different browsers but doesn't seem to help.

Thank you for all the inputs.

Am trying to summarize my understanding and also sharing some new aspects that I did like to use to differentiate between TMF-641 and TMF-640. Please share your feedback.

Architecture Options:

Option-1: TMF-641 should be the Interface for BSS to request Services using Service Orders.

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Differences:

Differences between TMF-641 and TMF-640 in terms of functional capabilities. Architecture option should be chosen based on these capabilities and not extend the capabilities of TMF-640 to make it look like TMF-641 thus defeating the purpose of two(TMF-641 and TMF-640) standard Interfaces and making them ambiguous.

TMF-641

1. Operations(CRUD) on Service Order
2. Service Order can contain multiple Services
3. Support for Composition and Decomposition to RFS(s) and Resource(s)
4. Support for Long Running Business Processes, support for Inflight changes to Service Order

5. Provider of TMF-641 works with Service Inventory using TMF-638

6. TAM Functions supported: Design Solution, Assignments, Reservation, Manage Service Dependencies, Manage Service Instance, Address Validation, Plan for Service Configuration and Activation and Service Configuration & Activation(using TMF-640)
7. Orders can result in partial success and provide control to the consumer to handle/resolve the failed aspects.

 TMF-640

1. Operations(CRUD) on Service(typically RFS, however in case of Architecture Option2 can be Service which represents both CFS and RFS)
2. Request operates on Single Service
3. Support for Decomposition to Resource Provisioning requests on a single Resource only
4. Support for short lived Business Processes, no need for Inflight changes of Service Request.

5. Provider of TMF-640 doesn't need Service Inventory

6. TAM Functions supported: Service Configuration & Activation. Infrastructure(Devices & Networks) for the Service are expected to be pre-existing.
7. Service requests are atomic, complete success or complete failure.

Interested by the above post here @Srinivasa Vellanki. Would i be correct in suggesting that your belief is that a service should be able to have its state transitioned (TMF640) without a service order (TMF641). My view on this was that a service would only transition state via an order however long or short running that might be?

My thinking was quite closely aligned with @Koen Peeters , Is my below understanding incorrect?

Architecture Options:

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Scenario :- There is a SOM in the business and which is CFS and while sending down the notifications related to the service to the other RFS's in the domain ,but not in TMF640 structured way , Can we expect the CFS interface to send the payload or the data in already structured form i.e, more alike TMF 641 standard ?
What could be the impact on the SOM which is already on TMF 641 to manipulate the data to TMF 640 before sending it down to RFS nodes in topology ?

Had problem with uploading Images or any attachments. Tried using different browsers but doesn't seem to help.

Thank you for all the inputs.

Am trying to summarize my understanding and also sharing some new aspects that I did like to use to differentiate between TMF-641 and TMF-640. Please share your feedback.

Architecture Options:

Option-1: TMF-641 should be the Interface for BSS to request Services using Service Orders.

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Differences:

Differences between TMF-641 and TMF-640 in terms of functional capabilities. Architecture option should be chosen based on these capabilities and not extend the capabilities of TMF-640 to make it look like TMF-641 thus defeating the purpose of two(TMF-641 and TMF-640) standard Interfaces and making them ambiguous.

TMF-641

1. Operations(CRUD) on Service Order
2. Service Order can contain multiple Services
3. Support for Composition and Decomposition to RFS(s) and Resource(s)
4. Support for Long Running Business Processes, support for Inflight changes to Service Order

5. Provider of TMF-641 works with Service Inventory using TMF-638

6. TAM Functions supported: Design Solution, Assignments, Reservation, Manage Service Dependencies, Manage Service Instance, Address Validation, Plan for Service Configuration and Activation and Service Configuration & Activation(using TMF-640)
7. Orders can result in partial success and provide control to the consumer to handle/resolve the failed aspects.

 TMF-640

1. Operations(CRUD) on Service(typically RFS, however in case of Architecture Option2 can be Service which represents both CFS and RFS)
2. Request operates on Single Service
3. Support for Decomposition to Resource Provisioning requests on a single Resource only
4. Support for short lived Business Processes, no need for Inflight changes of Service Request.

5. Provider of TMF-640 doesn't need Service Inventory

6. TAM Functions supported: Service Configuration & Activation. Infrastructure(Devices & Networks) for the Service are expected to be pre-existing.
7. Service requests are atomic, complete success or complete failure.

Interested by the above post here @Srinivasa Vellanki. Would i be correct in suggesting that your belief is that a service should be able to have its state transitioned (TMF640) without a service order (TMF641). My view on this was that a service would only transition state via an order however long or short running that might be?

My thinking was quite closely aligned with @Koen Peeters , Is my below understanding incorrect?

Architecture Options:

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Scenario :- There is a SOM in the business and which is CFS and while sending down the notifications related to the service to the other RFS's in the domain ,but not in TMF640 structured way , Can we expect the CFS interface to send the payload or the data in already structured form i.e, more alike TMF 641 standard ?
What could be the impact on the SOM which is already on TMF 641 to manipulate the data to TMF 640 before sending it down to RFS nodes in topology ?

Had problem with uploading Images or any attachments. Tried using different browsers but doesn't seem to help.

Thank you for all the inputs.

Am trying to summarize my understanding and also sharing some new aspects that I did like to use to differentiate between TMF-641 and TMF-640. Please share your feedback.

Architecture Options:

Option-1: TMF-641 should be the Interface for BSS to request Services using Service Orders.

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Differences:

Differences between TMF-641 and TMF-640 in terms of functional capabilities. Architecture option should be chosen based on these capabilities and not extend the capabilities of TMF-640 to make it look like TMF-641 thus defeating the purpose of two(TMF-641 and TMF-640) standard Interfaces and making them ambiguous.

TMF-641

1. Operations(CRUD) on Service Order
2. Service Order can contain multiple Services
3. Support for Composition and Decomposition to RFS(s) and Resource(s)
4. Support for Long Running Business Processes, support for Inflight changes to Service Order

5. Provider of TMF-641 works with Service Inventory using TMF-638

6. TAM Functions supported: Design Solution, Assignments, Reservation, Manage Service Dependencies, Manage Service Instance, Address Validation, Plan for Service Configuration and Activation and Service Configuration & Activation(using TMF-640)
7. Orders can result in partial success and provide control to the consumer to handle/resolve the failed aspects.

 TMF-640

1. Operations(CRUD) on Service(typically RFS, however in case of Architecture Option2 can be Service which represents both CFS and RFS)
2. Request operates on Single Service
3. Support for Decomposition to Resource Provisioning requests on a single Resource only
4. Support for short lived Business Processes, no need for Inflight changes of Service Request.

5. Provider of TMF-640 doesn't need Service Inventory

6. TAM Functions supported: Service Configuration & Activation. Infrastructure(Devices & Networks) for the Service are expected to be pre-existing.
7. Service requests are atomic, complete success or complete failure.

Interested by the above post here @Srinivasa Vellanki. Would i be correct in suggesting that your belief is that a service should be able to have its state transitioned (TMF640) without a service order (TMF641). My view on this was that a service would only transition state via an order however long or short running that might be?

My thinking was quite closely aligned with @Koen Peeters , Is my below understanding incorrect?

Architecture Options:

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Scenario :- There is a SOM in the business and which is CFS and while sending down the notifications related to the service to the other RFS's in the domain ,but not in TMF640 structured way , Can we expect the CFS interface to send the payload or the data in already structured form i.e, more alike TMF 641 standard ?
What could be the impact on the SOM which is already on TMF 641 to manipulate the data to TMF 640 before sending it down to RFS nodes in topology ?

Had problem with uploading Images or any attachments. Tried using different browsers but doesn't seem to help.

Thank you for all the inputs.

Am trying to summarize my understanding and also sharing some new aspects that I did like to use to differentiate between TMF-641 and TMF-640. Please share your feedback.

Architecture Options:

Option-1: TMF-641 should be the Interface for BSS to request Services using Service Orders.

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Differences:

Differences between TMF-641 and TMF-640 in terms of functional capabilities. Architecture option should be chosen based on these capabilities and not extend the capabilities of TMF-640 to make it look like TMF-641 thus defeating the purpose of two(TMF-641 and TMF-640) standard Interfaces and making them ambiguous.

TMF-641

1. Operations(CRUD) on Service Order
2. Service Order can contain multiple Services
3. Support for Composition and Decomposition to RFS(s) and Resource(s)
4. Support for Long Running Business Processes, support for Inflight changes to Service Order

5. Provider of TMF-641 works with Service Inventory using TMF-638

6. TAM Functions supported: Design Solution, Assignments, Reservation, Manage Service Dependencies, Manage Service Instance, Address Validation, Plan for Service Configuration and Activation and Service Configuration & Activation(using TMF-640)
7. Orders can result in partial success and provide control to the consumer to handle/resolve the failed aspects.

 TMF-640

1. Operations(CRUD) on Service(typically RFS, however in case of Architecture Option2 can be Service which represents both CFS and RFS)
2. Request operates on Single Service
3. Support for Decomposition to Resource Provisioning requests on a single Resource only
4. Support for short lived Business Processes, no need for Inflight changes of Service Request.

5. Provider of TMF-640 doesn't need Service Inventory

6. TAM Functions supported: Service Configuration & Activation. Infrastructure(Devices & Networks) for the Service are expected to be pre-existing.
7. Service requests are atomic, complete success or complete failure.

Interested by the above post here @Srinivasa Vellanki. Would i be correct in suggesting that your belief is that a service should be able to have its state transitioned (TMF640) without a service order (TMF641). My view on this was that a service would only transition state via an order however long or short running that might be?

My thinking was quite closely aligned with @Koen Peeters , Is my below understanding incorrect?

Architecture Options:

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Scenario :- There is a SOM in the business and which is CFS and while sending down the notifications related to the service to the other RFS's in the domain ,but not in TMF640 structured way , Can we expect the CFS interface to send the payload or the data in already structured form i.e, more alike TMF 641 standard ?
What could be the impact on the SOM which is already on TMF 641 to manipulate the data to TMF 640 before sending it down to RFS nodes in topology ?

Had problem with uploading Images or any attachments. Tried using different browsers but doesn't seem to help.

Thank you for all the inputs.

Am trying to summarize my understanding and also sharing some new aspects that I did like to use to differentiate between TMF-641 and TMF-640. Please share your feedback.

Architecture Options:

Option-1: TMF-641 should be the Interface for BSS to request Services using Service Orders.

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Differences:

Differences between TMF-641 and TMF-640 in terms of functional capabilities. Architecture option should be chosen based on these capabilities and not extend the capabilities of TMF-640 to make it look like TMF-641 thus defeating the purpose of two(TMF-641 and TMF-640) standard Interfaces and making them ambiguous.

TMF-641

1. Operations(CRUD) on Service Order
2. Service Order can contain multiple Services
3. Support for Composition and Decomposition to RFS(s) and Resource(s)
4. Support for Long Running Business Processes, support for Inflight changes to Service Order

5. Provider of TMF-641 works with Service Inventory using TMF-638

6. TAM Functions supported: Design Solution, Assignments, Reservation, Manage Service Dependencies, Manage Service Instance, Address Validation, Plan for Service Configuration and Activation and Service Configuration & Activation(using TMF-640)
7. Orders can result in partial success and provide control to the consumer to handle/resolve the failed aspects.

 TMF-640

1. Operations(CRUD) on Service(typically RFS, however in case of Architecture Option2 can be Service which represents both CFS and RFS)
2. Request operates on Single Service
3. Support for Decomposition to Resource Provisioning requests on a single Resource only
4. Support for short lived Business Processes, no need for Inflight changes of Service Request.

5. Provider of TMF-640 doesn't need Service Inventory

6. TAM Functions supported: Service Configuration & Activation. Infrastructure(Devices & Networks) for the Service are expected to be pre-existing.
7. Service requests are atomic, complete success or complete failure.

Interested by the above post here @Srinivasa Vellanki. Would i be correct in suggesting that your belief is that a service should be able to have its state transitioned (TMF640) without a service order (TMF641). My view on this was that a service would only transition state via an order however long or short running that might be?

My thinking was quite closely aligned with @Koen Peeters , Is my below understanding incorrect?

Architecture Options:

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Scenario :- There is a SOM in the business and which is CFS and while sending down the notifications related to the service to the other RFS's in the domain ,but not in TMF640 structured way , Can we expect the CFS interface to send the payload or the data in already structured form i.e, more alike TMF 641 standard ?
What could be the impact on the SOM which is already on TMF 641 to manipulate the data to TMF 640 before sending it down to RFS nodes in topology ?

Had problem with uploading Images or any attachments. Tried using different browsers but doesn't seem to help.

Thank you for all the inputs.

Am trying to summarize my understanding and also sharing some new aspects that I did like to use to differentiate between TMF-641 and TMF-640. Please share your feedback.

Architecture Options:

Option-1: TMF-641 should be the Interface for BSS to request Services using Service Orders.

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Differences:

Differences between TMF-641 and TMF-640 in terms of functional capabilities. Architecture option should be chosen based on these capabilities and not extend the capabilities of TMF-640 to make it look like TMF-641 thus defeating the purpose of two(TMF-641 and TMF-640) standard Interfaces and making them ambiguous.

TMF-641

1. Operations(CRUD) on Service Order
2. Service Order can contain multiple Services
3. Support for Composition and Decomposition to RFS(s) and Resource(s)
4. Support for Long Running Business Processes, support for Inflight changes to Service Order

5. Provider of TMF-641 works with Service Inventory using TMF-638

6. TAM Functions supported: Design Solution, Assignments, Reservation, Manage Service Dependencies, Manage Service Instance, Address Validation, Plan for Service Configuration and Activation and Service Configuration & Activation(using TMF-640)
7. Orders can result in partial success and provide control to the consumer to handle/resolve the failed aspects.

 TMF-640

1. Operations(CRUD) on Service(typically RFS, however in case of Architecture Option2 can be Service which represents both CFS and RFS)
2. Request operates on Single Service
3. Support for Decomposition to Resource Provisioning requests on a single Resource only
4. Support for short lived Business Processes, no need for Inflight changes of Service Request.

5. Provider of TMF-640 doesn't need Service Inventory

6. TAM Functions supported: Service Configuration & Activation. Infrastructure(Devices & Networks) for the Service are expected to be pre-existing.
7. Service requests are atomic, complete success or complete failure.

Interested by the above post here @Srinivasa Vellanki. Would i be correct in suggesting that your belief is that a service should be able to have its state transitioned (TMF640) without a service order (TMF641). My view on this was that a service would only transition state via an order however long or short running that might be?

My thinking was quite closely aligned with @Koen Peeters , Is my below understanding incorrect?

Architecture Options:

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Scenario :- There is a SOM in the business and which is CFS and while sending down the notifications related to the service to the other RFS's in the domain ,but not in TMF640 structured way , Can we expect the CFS interface to send the payload or the data in already structured form i.e, more alike TMF 641 standard ?
What could be the impact on the SOM which is already on TMF 641 to manipulate the data to TMF 640 before sending it down to RFS nodes in topology ?

Had problem with uploading Images or any attachments. Tried using different browsers but doesn't seem to help.

Thank you for all the inputs.

Am trying to summarize my understanding and also sharing some new aspects that I did like to use to differentiate between TMF-641 and TMF-640. Please share your feedback.

Architecture Options:

Option-1: TMF-641 should be the Interface for BSS to request Services using Service Orders.

Option-2: However in some scenarios where the Service is very simple and doesn't require the overhead of Order Management in which case Architecture can be simplified by BSS using TMF-640.

Differences:

Differences between TMF-641 and TMF-640 in terms of functional capabilities. Architecture option should be chosen based on these capabilities and not extend the capabilities of TMF-640 to make it look like TMF-641 thus defeating the purpose of two(TMF-641 and TMF-640) standard Interfaces and making them ambiguous.

TMF-641

1. Operations(CRUD) on Service Order
2. Service Order can contain multiple Services
3. Support for Composition and Decomposition to RFS(s) and Resource(s)
4. Support for Long Running Business Processes, support for Inflight changes to Service Order

5. Provider of TMF-641 works with Service Inventory using TMF-638

6. TAM Functions supported: Design Solution, Assignments, Reservation, Manage Service Dependencies, Manage Service Instance, Address Validation, Plan for Service Configuration and Activation and Service Configuration & Activation(using TMF-640)
7. Orders can result in partial success and provide control to the consumer to handle/resolve the failed aspects.

 TMF-640

1. Operations(CRUD) on Service(typically RFS, however in case of Architecture Option2 can be Service which represents both CFS and RFS)
2. Request operates on Single Service
3. Support for Decomposition to Resource Provisioning requests on a single Resource only
4. Support for short lived Business Processes, no need for Inflight changes of Service Request.

5. Provider of TMF-640 doesn't need Service Inventory

6. TAM Functions supported: Service Configuration & Activation. Infrastructure(Devices & Networks) for the Service are expected to be pre-existing.
7. Service requests are atomic, complete success or complete failure.