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.