Open APIs

 View Only

  • 1.  TMF630 service modification

    Posted Mar 09, 2020 03:47
    If the service characteristics is a composite structure for L3VPN which include list of Nodes, EPs, static routes, routing protocols etc.   
    considering service patch method, how would a user call, for example, for removing sub entity like end-point  withing a node?
    Do sub-entities can there own id?

    ------------------------------
    Erez Segev
    ECI Telecom Ltd.
    ------------------------------


  • 2.  RE: TMF630 service modification

    Posted Mar 09, 2020 05:32
    Hi Erez

    Perhaps you meant TMF638 (Service Inventory - TMF630 is the number for the guidelines document)?

    I think it unlikely that you would create a complex service characteristic for the use case you describe (although the API does allow characteristics to be any object). It is more likely that you would create a hierarchy of services, or perhaps relationships between services, and each service would have its own (simple) characteristics. So end-point could be a service, node could be a service, etc. Each service is directly addressable by its ID.

    @Ludovic Robert might want to give his perspective as well

    Hope it helps​

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



  • 3.  RE: TMF630 service modification

    Posted Mar 09, 2020 05:56

    I meant - Service Activation and Configuration API (TMF640),  I  like to use this interface for defining E2E L3BPN which include Node(VRFs) and EPs.

    Each sub element can have a unique id , but I cannot refer to it as service because all are in the context of the L3VPN service.

     

    I can call for a delete and edit for everything that have and id but the question is whether the OSS can be familiar with service sub-entities?

     

     

     


    ___________________________________________________________________________

    This e-mail message is intended for the recipient only and contains information which is
    CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
    transmission in error, please inform us by e-mail, phone or fax, and then delete the original
    and all copies thereof.
    ___________________________________________________________________________


    ------Original Message------

    Hi Erez

    Perhaps you meant TMF638 (Service Inventory - TMF630 is the number for the guidelines document)?

    I think it unlikely that you would create a complex service characteristic for the use case you describe (although the API does allow characteristics to be any object). It is more likely that you would create a hierarchy of services, or perhaps relationships between services, and each service would have its own (simple) characteristics. So end-point could be a service, node could be a service, etc. Each service is directly addressable by its ID.

    @Ludovic Robert might want to give his perspective as well

    Hope it helps​

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


  • 4.  RE: TMF630 service modification

    Posted Mar 09, 2020 11:43
    I am by no means an OSS expert, but I don't understand why the sub-entities cannot be considered as Services. It is completely legitimate for Services to contain other Services, and to specify that the contained services cannot be instantiated outside of their containing services.

    In addition to Ludovic, maybe @Kamal Maghsoudlou and @Vance Shipley want to weigh in on this topic.

    ​​

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

    Original Message


  • 5.  RE: TMF630 service modification

    Posted Mar 09, 2020 18:22
    Hi Erez,

    Depending how you model L3VPN service you may have different options of using such a service. you should define your L3VPN service in (service) catalog (TMF633), order, activate and configure it thru Ordering/configuration APIs (TMF640/TMF641) and instantiate it and manipulating the instances using Inventory APIs (TMF638/TMF639/TMF641).
    To define a L3VPN model in the service catalog you have different options:
    1. you may define L3VPN  as a customer facing service specification and define its related components as embedded composite characteristics as you mentioned. in this case you may use API extension pattern to model multi-level embedded characteristics ,
    2. you may also define it as CFSS with a list of resource facing service specifications and corresponding resource specifications for its service elements
    3. you can define L3VPN as a composite service specification with its each service component (PE-CE connectivity in case of MPLS L3VPN associated with a VRF) as a simple customer facing service specification  corresponding to one or more RFSS/Resource specifications supporting the connectivity (such as BGP, OSPF, static, RIP routing protocol, site security authentication, access vpn policy configlets)
    4. you can extend above options 2 or 3 by using feature specification and its associated characteristics to model some of L3VPN connectivity features like routing, security, redundancy, failover, multicast and address translation

    you may also think about other VPN modeling options like what you see in GB921 guidebooks ( service package, ..). However, in any case, I don't suggest to introduce resources like Node (PE or CE) as a service. if you use options 2 or 3, you can map YANG model of L3VPN as described by RFC8299 into TMF data model for TMF633/TMF640/TMF641/TMF638/TMF639. if you use option 1 as you mentioned, you have a challenge for a hierarchical model of extended characteristic pattern.

    Regards,
    Kamal

    ------------------------------
    Kamal Maghsoudlou
    Ericsson Inc.
    ------------------------------

    Original Message


  • 6.  RE: TMF630 service modification

    Posted Mar 10, 2020 00:30

    Hi Kamal,

     

    Thank you very much for the detailed response, it gives me a lot of homework to do...

    Regarding RFC8299, In the beginning RFC8299 was a very good candidate to model the service, since It describes the customer perspective (customer sites model), however breaking the customer perspective into resources/network perspective was not trivial, and requires many assumptions.

    In the last year there was another IEFT initiative called L3NM (NM is network model) which is much more suitable to my need, since it usage the network perspective , as such include nodes, VRFs , routing protocols etc.

    Assuming a provider's management system breaks RFC8299 into L3NM , my system need to accept the L3NM model and provision a service based on it.

    The question is how to treat the nodes and EPs , as sub service or resources , and should the provider management system can edit the resources as independent entities (TMF639) or only via the service API (TMF640).

     

    Thanks,

    Erez

     

     


    ___________________________________________________________________________

    This e-mail message is intended for the recipient only and contains information which is
    CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
    transmission in error, please inform us by e-mail, phone or fax, and then delete the original
    and all copies thereof.
    ___________________________________________________________________________


    ------Original Message------

    Hi Erez,

    Depending how you model L3VPN service you may have different options of using such a service. you should define your L3VPN service in (service) catalog (TMF633), order, activate and configure it thru Ordering/configuration APIs (TMF640/TMF641) and instantiate it and manipulating the instances using Inventory APIs (TMF638/TMF639/TMF641).
    To define a L3VPN model in the service catalog you have different options:
    1. you may define L3VPN  as a customer facing service specification and define its related components as embedded composite characteristics as you mentioned. in this case you may use API extension pattern to model multi-level embedded characteristics ,
    2. you may also define it as CFSS with a list of resource facing service specifications and corresponding resource specifications for its service elements
    3. you can define L3VPN as a composite service specification with its each service component (PE-CE connectivity in case of MPLS L3VPN associated with a VRF) as a simple customer facing service specification  corresponding to one or more RFSS/Resource specifications supporting the connectivity (such as BGP, OSPF, static, RIP routing protocol, site security authentication, access vpn policy configlets)
    4. you can extend above options 2 or 3 by using feature specification and its associated characteristics to model some of L3VPN connectivity features like routing, security, redundancy, failover, multicast and address translation

    you may also think about other VPN modeling options like what you see in GB921 guidebooks ( service package, ..). However, in any case, I don't suggest to introduce resources like Node (PE or CE) as a service. if you use options 2 or 3, you can map YANG model of L3VPN as described by RFC8299 into TMF data model for TMF633/TMF640/TMF641/TMF638/TMF639. if you use option 1 as you mentioned, you have a challenge for a hierarchical model of extended characteristic pattern.

    Regards,
    Kamal

    ------------------------------
    Kamal Maghsoudlou
    Ericsson Inc.
    ------------------------------


  • 7.  RE: TMF630 service modification

    Posted Mar 11, 2020 14:21
    The question is how to treat the nodes and EPs , as sub service or resources , and should the provider management system can edit the resources as independent entities (TMF639) or only via the service API (TMF640).
    Erez Segev,  Mar 10, 2020 00:29
    Erez,

    In my view the distinction between Resource and Service depends on what is being offered as a product.  Here it seems you have Resource Facing Services (RFS) described by L3NM. You may model VPN as a compound ResourceFunction and manage with TMF664 Resource Function Activation and Configuration. ResourceFunction adds configuration features, service access points and connectivity topology to LogicalResource.

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

    Original Message


  • 8.  RE: TMF630 service modification

    Posted Mar 12, 2020 02:51

    Hi Vance,

     

    Thanks for your help.

     

    The product according to my understanding in my is what RFC8299 defines – connectivity between sites,.

    L3NM entities as a whole presents service which breaks down to logical resources (or sub services) that has their own ids, which I can manage using Resource function as you suggested, but the basic assumption is that OSS has knowledge about those entities  .

     

    Our implementation, would be creation of service using service activation interface while the response is compound service (L3NM) which each sub entities has its own id. For update there going to be a PATCH request with compound  entity in which the OSS can , update attributes , add/remove EP/Nodes on the same request using the EPs/Nodes ids.

     

    Regards,

    Erez

     


    ___________________________________________________________________________

    This e-mail message is intended for the recipient only and contains information which is
    CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
    transmission in error, please inform us by e-mail, phone or fax, and then delete the original
    and all copies thereof.
    ___________________________________________________________________________


    ------Original Message------

    The question is how to treat the nodes and EPs , as sub service or resources , and should the provider management system can edit the resources as independent entities (TMF639) or only via the service API (TMF640).
    Erez Segev,  Mar 10, 2020 00:29
    Erez,

    In my view the distinction between Resource and Service depends on what is being offered as a product.  Here it seems you have Resource Facing Services (RFS) described by L3NM. You may model VPN as a compound ResourceFunction and manage with TMF664 Resource Function Activation and Configuration. ResourceFunction adds configuration features, service access points and connectivity topology to LogicalResource.

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


Related Content