Since the service lifecycle states are extensible, we added as "Suspended" state. The standard isn't very clear but the state values are defined as "such as" meaning they are examples and not a defined, fixed list. (I've opened Jira tickets on the wording so hopefully its clearer in the future).
The reason for a new state versus overloading "inactive" was to keep the definition of inactive as ready to activate (all resources allocated and ready*). Depending on the reason and/or length of a suspension, some resources may be allocated to the suspended service (e.g., phone number) and other freed (reserved capacity).
There's always a trade off between adding a state and overloading existing ones. We tried to have a clear status of the resources for each of the states and that drove creating a new state.
*Our definition of "ready" would include things like VNFs that could be spun up when the service was made active, they didn't have to be running in the inactive state but all resources have to be able to be active in a short time frame (minutes or less).
------------------------------
Corey Clinger
Network as a Service Architect
Telstra
------------------------------
Original Message:
Sent: May 15, 2019 11:02
From: Stephane AH-KO
Subject: TMF641 - How to Suspend a Service?
We are looking into way to Suspend a Service (either because it's customer initiated, like seasonal suspension, or for non-payment)
What we've noticed so far:
- ServiceOrderItem.action enumeration are: add, modify, delete, noChange.
- In our current implementation, we are following 2 behaviours:
- In some cases, we use ServiceOrderItem. action like a "Suspend" or "Resume", in addition to "add", "modify", "delete"...
- In other cases, because we need to keep track of the suspension reason, we use ServiceOrderItem.action "modify", and Add a Suspension "Configuration" under the Service. the Suspension Configuration contains a SuspensionReason chraracteristic where we carry values like "Seasonal" or "Non-Payment"
- We concluded that suspension/resume are not handled via the ServiceOrderItem.action
- ServiceRestriction.state enumeration are: feasibilityChecked, designed, reserved, inactive, active, terminated.
- We assume that the suspend action would be a PATCH operation where service.state = 'inactive'
- Similarly, the resume action would be a PATCH operation where service.state = 'active'
Is our understanding of handling Suspension correct?
------------------------------
Stephane AH-KO
CGI
------------------------------