Hi Kinshuk,
Indeed, if the EVC End Point is modelled as a service and not as a set of attributes of the EVC, we can follow that approach.
However, if we look to today's OVC service from MEF model, the end-points are being modelled as a sub-set of characteristics. I've understood they plan to change it and have the end-points as separate service that should be ordered as additional item. In this case, the example I've gave will not be applicable.
Forgetting MEF models for a moment, I think the challenge I raise can still occur in many other modelling use-cases. For example, if we want to model a VPN as a Service that rely on multiple Site Connectivity Services, we could imagine that this VPN Service will have its relationships being constantly updated to reach more or less connectivity sites. There are always many ways to model this but, taking this one, I think the current TMF641 model will not be sufficient to update VPN service relationships by just adding a new relationship or ceasing a specific one.
If we are looking to have a TMF641 API definition that can support any kind of modelling choice and use-case, it would be great that the API offers the capability to remove or add a specific relationship of a service. I am currently seeing this need more and more with OTT-based models.
In order to have the TMF641 flexible enough for these cases, I would suggest it to have an additional attribute being "relationshipAction" under the "ServiceOrderItemRelationship" sub-resource to fix such challenge.
@Ludovic Robert, is this suggestion something that can be discussed on the API team meetings?
------------------------------
Carlos Portela
Prodapt Solutions
------------------------------
Original Message:
Sent: Jul 05, 2021 09:42
From: Kinshuk Kulshreshtha
Subject: TMF641 - change service relationship (also TMF622)
Hi Carlos,
Thanks for the clarification. I think the order that this customer is submitting is removing the EVC Endpoint and not really removing a UNI altogether. I would assume that you already has EVC Endpoint Product and CFS as well.
In such case, the Order that is sent should have 2 Order Lines
1. EVC (Modify) - Because when an EVC Endpoint is removed, the EVC also needs to be updated
2. EVC Endpoint (Delete)
I think we may not need a line item for UNI, because the UNI is unchanged. Only the VLAN assignments on the UNI are changing, which I believe are part of EVC Endpoint CFS.
As part of your Service Design & Assign, whenever you receive Delete on EVC Endpoint, you identify which UNI it is utilizing and remove that relationship in the Service Inventory. So, the relationship between UNI and EVC should be the based on the availability of EVC Endpoints and should be mastered in Service Inventory.
------------------------------
Kinshuk Kulshreshtha
Oracle Corporation
Original Message:
Sent: Jul 05, 2021 09:05
From: Carlos Portela
Subject: TMF641 - change service relationship (also TMF622)
Kinshuk,
Indeed you are right. In the UNI characteristics, as per defined by MEF, you can set its global bandwidth and the maximum of EVC/OVC end-points you want to support on this product. When a new EVC/OVC is created for a UNI, we need to validate that the requested VLAN or VLAN range (in EVC/OVC characteristics) is available on this specific UNI and can be used for such L2 connectivity.
Regards
------------------------------
Carlos Portela
Prodapt Solutions
Original Message:
Sent: Jul 05, 2021 08:29
From: Kinshuk Kulshreshtha
Subject: TMF641 - change service relationship (also TMF622)
Hi Carlos,
Thanks for your reply. In your case, since UNI B is part of 3 Services (2EVCs and 1 OVC), I assume that each of these EVCs and OVC will be consuming a portion of the UNI based on the bandwidth of the provisioned EVC/OVC at that endpoint. Is that correct? Are you assigning different VLANs in the UNI for each EVC/OVC?
Regards,
Kinshuk
------------------------------
Kinshuk Kulshreshtha
Oracle Corporation
Original Message:
Sent: Jul 05, 2021 06:29
From: Carlos Portela
Subject: TMF641 - change service relationship (also TMF622)
Hello Kinshuk,
Thanks for your reply. In fact, if we look to MEF definition, and to many CSP use-cases, we should be able to support multiple connectivity services on top of a single phyisical line. Note that the relationship is the other way around, EVC/OVC reliesOn UNI, and we need to delete this relationship on the EVC/OVC product.
In MEF, the use case could be the following:
- EVC 1 with 300 UNI's, being UNI B one of them
- EVC 2 with 100 UNI's, being UNI B one of them
- OVC 3 with 1 UNI, being UNI B one of them
It means that the three products (EVC 1, 2 AND OVC 3) would rely on the same UNI B product.
Now, the customer/partner is interested to remove EVC 1 connectivity only from UNI B product but still keep the other two connectivity products up & running (EVC 2 and OVC 3) on this UNI. To make it clear, the EVC 1 would keep only 299 UNI's after such request.
The question is: how could we do it without sending the "full install-base setup" in the order to avoid such complexity?
------------------------------
Carlos Portela
Prodapt Solutions
Original Message:
Sent: Jul 05, 2021 05:25
From: Kinshuk Kulshreshtha
Subject: TMF641 - change service relationship (also TMF622)
Hi Carlos,
I believe in your case, the customer is trying to disconnect one of its sites (fully or partially) when they are sending the Delete UNI Order. In such cases, do you just want to delete the relationship of the UNI CFS with the EVC CFS or you would want to disconnect the UNI CFS as well? Even if the underlying connectivity that is enabling the UNI CFS may be maintained from CSP perspective, the actual UNI CFS would need to be disconnected in my opinion. What is the use case where you would just want to remove the relationship between UNI CFS and EVC CFS but keep the UNI CFS intact?
Regards
------------------------------
Kinshuk Kulshreshtha
Oracle Corporation
Original Message:
Sent: Jul 04, 2021 18:02
From: Carlos Portela
Subject: TMF641 - change service relationship (also TMF622)
Hi Jonathan,
Indeed, that's in fact what I was thinking. Note that the relationship classes "serviceOrderItemRelationship" and "productOrderItemRelationship" do not belong to the inventories class model but only to the order ones. I think it would be best that we play with this class and re-use the same attribute action there.
We could imagine an order mockup like this:
- orderItem 1
- action: modify
- serviceId: (vpnConnectivity instance id)
- orderItemRelationship
- orderItem 2
- action: noChange
- serviceId: (access instance id)
Look forward to hearing some feedback from the collaborators you mention.
Thanks for your help
------------------------------
Carlos Portela
Prodapt Solutions
Original Message:
Sent: Jul 04, 2021 01:32
From: Jonathan Goldberg
Subject: TMF641 - change service relationship (also TMF622)
Hi Carlos
I understand the challenge you are describing.
We have an action attribute at the OrderItem level, which could be used, perhaps, to say that the embedded Product or Service payload implies adding/changing/removing a relationship.
I would be reluctant to add the action attribute at the Product (or Service) level (e.g. the Relationship classes), since these classes model the state of the inventory, and action is out of context there. But the whole topic needs more thought, let's see if @Ludovic Robert or @Kamal Maghsoudlou or @Johanne Mayer have any thoughts on this.
------------------------------
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:
Sent: Jul 02, 2021 13:17
From: Carlos Portela
Subject: TMF641 - change service relationship (also TMF622)
Hi all,
I don't find any topic on this from the past so I could imagine this situation it is not that common. Let's dive into the point.
We are working on a TMF compliant SOM layer where TMF641 is our main entry door for CFS ordering. The API definition is quite clear when we talk about handling a service (add/modify/delete) but I am seeing some challenges when dealing with changes on a service relationship. The same occurs at Product level with TMF622.
The current question I have is about how could we modify a specific CFS to remove a specific relationship to other service that is no longer applicable. I will give two examples.
In a first instance, imagine a VPN Connectivity CFS that relates (reliesOn) with multiple Access CFS. Later after activation, we wanted to update the VPN Connectivity CFS to remove one of the relationships that it has with a specific Access CFS. How could this be done via TMF641 POST with the given VPN Connectivity CFS with action MODIFY? Note that it is expected to not send a full desired picture of a service when the action is MODIFY but just specify what really is requested for change.
When we look to TMF622, the same issue can occur. We could take a look on the E-Tree service from MEF and how it is expected to be ordered at Product level. There would be an EVC Product Item that can rely in innumerous UNI's Product Items. Later on, I could imagine the customer to call TMF622 to remove one of the UNI's. Of course that, if a Product/Service Order MODIFY action includes always all the needed relationships, we would have a solution but, there should be a simpler way to manage this.
Wouldn't be acceptable that we include in the TMF641 API an Action attribute at itemRelationship or serviceRelationship? I think it would solve this issue.
Regards
------------------------------
Carlos Portela
Prodapt Solutions
------------------------------