Open APIs

 View Only
  • 1.  Product Activation and Configuration in Open API (TMF640?)

    Posted Aug 12, 2021 09:20
    Edited by Marlon Almazan Aug 19, 2021 12:04
    Hi,

    Please help me to clarify two topics

    1) SID defines several related entities (section 3.8 of GB922 Common):
    • Configuration/ConfigurationSpecification
    • ProductConfiguration/ProductConfigSpec
    • ServiceConfiguration/ServiceConfigSpec
    • ResourceConfiguration/ResourceConfigSpec
    ​Here is the picture from SID:


    It does not look like any Open API's use it. These entities are internal for Customer/Service/Resource Order Management, aren't they? Why would TMForum bothers for such internal implementation details?

    2) In some simple cases (digital or "virtual" products) it makes sence to "activate" ordered product directly on a paltform (SDP) from BSS. In this case standard path (product -> CFS -> RFS -> Resource) looks too overloaded. Standard path implies using Product/Service Catalogs and Customer/Service/Resource Order Management systems. I would like to call Platform directly from Customer Order Management (at Product Order level). However Service Activation and Configuration API (TMF640) works only at Service level. Would it be an issue? From the other hand for non-telecom (digital or "virtual") products it makes sence using other industries specific standards like OSB and etc... What the community recommends for product activation?

    p.s. Also SID gives reference to document "Configuration and Profiling Business Agreement, Version 1.1.2.", but I did not find it. I would appreciate if somebody gives a link to it.​​​​

    ------------------------------
    Maxim Sedov
    Mobile TeleSystems OJSC
    ------------------------------


  • 2.  RE: Product Activation and Configuration in Open API (TMF640?)

    TM Forum Member
    Posted Aug 18, 2021 11:16
    Hi Maxim

    Regarding 1) - I honestly don't know what the xxxConfiguration entities mean in the SID, and what they add over the entity and entity characteristic. Perhaps there's a write-up in one of the GB922 addendums. @Cecile Ludwichowski can you elaborate?

    Regarding 2) - There is an API also for resource activation and configuration, TMF702, the "twin" (if you like) of TMF640 for Service. Not all the assets are published yet, so you'll find it in the early access table. You can get directly from Product to Resource in the Open API model, both at catalog and inventory level. And so your COM would invoke operations from TMF702 or TMF640accordingly.
    I think that TMF best practice would indicate that these products are implemented on the SDP as resources or services. @Vance Shipley do you want to step in here?​

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------



  • 3.  RE: Product Activation and Configuration in Open API (TMF640?)

    TM Forum Member
    Posted Aug 18, 2021 19:20
    Maxim,

    Your two topics raise very good questions. 

    1)  The motivation is provided in section GB922 Common section 3.81. Configuration complexity can be reduced through reuse of common patterns. These are modeled within the Configuration and Profiling ABE. The controversial statement here is:
    It is envisioned that SID implementers will begin to use the Service Configuration ABE as an alternative to Resource Facing Service Specification and Resource Facing Service ABEs.
    I support the requirement for ConfigurationSpecification/Configuration as first class (addressable) entities in order to fully realize Configuration Management (CM).  The capabilities defined here provide not only configurations which are reusable across instances but introduce Declarative configuration. Another important concept here is that Entity instances may play the role of ConfigurationSpecification which allows dynamically assigned values to be used to configure other Entities.

    In IG1174 Model-Driven Design of Management Interfaces for ODA Components these concepts are described in the context of ODA Components (software). See section 5.2.1 for a description of intent-based configuration management.

    I raised just this issue last week in a discussion about Intent Management in Autonomous Networks (IG1253). My assertion is that we have a progression of configuration capabilities:  Explicit -> Declarative -> Intent.  We never realized in Open APIs the ZOOM and SID work on Declarative configuration. Now we are gung-ho to get an Intent Management API (TMF921). My assumption is that Intent is a superset of Declarative so we should really have that first. I've had it on my TODO list for almost two years now to work on (Resource,Service,Product?) Configuration Management APIs, it seems it's high time. Want to help?

    2)  As far as I see it we should have a Product Activation API to apply the pattern uniformly.


    ------------------------------
    Vance Shipley
    SigScale
    ------------------------------



  • 4.  RE: Product Activation and Configuration in Open API (TMF640?)

    Posted Aug 20, 2021 04:48
    @Vance Shipley, thanks for clarifications. But it is still confusing, especially for Product level (ProductConfiguration/ProductConfigSpec)​. Could you give some examples. Is there already vendor solutions with implementation this concept (declarative configuration & intent-based configuration)? When you mentioned Configuration Management, did you mean CMDB (ITIL) solution?

    Some sources of confusion:
    • Document GB922_Product_v21.0.0.pdf  gives example for resource level (Equipment instance), rather than for product
    • Document GB922_Common_v21.0.0.pdf gives motivation for Configuration as "common re-usable patterns", however the diagram shows that configiration cannot be reused in different specs or instances 
    I'm talking about scenario like both Internet CFS and IPTV CFS depend on the same Port RFS from the specifications and instances point of view.


    Is it possible to consider two ways of managing products
    • For complex and classical telecom products (like Internet access, voice and etc...) to go with the long path Product -> CFS -> RFS > Resource
    • For some simple cases (cloud-nature products and etc...) to go with short path product -> product configuration or even withoud product configuration at all
    ?
    This is not explicitly mention in the document above
    ​​​​

    ------------------------------
    Maxim Sedov
    Mobile TeleSystems OJSC
    ------------------------------



  • 5.  RE: Product Activation and Configuration in Open API (TMF640?)

    TM Forum Member
    Posted Aug 21, 2021 05:10

    On Aug 20, 2021 04:48 @Maxim Sedov wrote:
    } Is there already vendor solutions with implementation this concept (declarative configuration & intent-based configuration)?

    Conceptually yes, there are many tools in the Infrastructure-as-Code space.

    } When you mentioned Configuration Management, did you mean CMDB (ITIL) solution?

    Not specifically, but yes.  In the TM Forum Application Framework (TAM) you'll find:

    7.1.1 Resource Commissioning & Configuration Management.

    } Document GB922_Common_v21.0.0.pdf gives motivation for Configuration as "common re-usable patterns", however the diagram shows that configiration cannot be reused in different specs or instances

    Sure, your set-top-box (STB) configuration is yours, not mine. It is the Configuration Specifications which are reused. But the interesting thing about the Configuration and Profiling ABE is that your STB Configuration instance may play the role of a Configuration Specification for my STB:

    Entities Serve as Configuration Specification3.8.7. Figure CP.03a - Entities Serve as Configuration Specifications

    This would allow cloning the STB for another room.  More importantly however it allows components of a composite ResourceFunction to be instantiated and the dynamically assigned values (e.g. IP address, port) to be used in configuring other components.


    ------------------------------
    Vance Shipley
    SigScale
    ------------------------------