I believe the current Lifecycle states for TMF639 leave room for improvement.
One single entity should have only one lifecyle state. The mapping to ITU M.3701 needs to be done in a different way using states of additional entities.
In the implementations I am involved with we are still using the old style lifecycle from TMF639_R17.(
planning, installing, operating, retiring).
This state also maps to the lifecycleState of ITU M.3701, although ITU left out the operating state (I wonder how that can even work). In my experience this lifecycle nicely fits for both logical and physical resources 8active and passive.
The administrative state of ITU M.3701 can be reflected by a Reservation entity that is linked to the Resource. When a Reservation exists the Resource is locked otherwise it is unlocked.
The operational state of ITU M.3701 can be reflected by a ResourceFeature that can be enabled or disabled (e.g. Port admin up/down). This state typically only applies to active devices, Logical resources and even passive physical resources (e.g. cables) typically don't have these types of features.
The usage state of ITU M.3701 can be reflected by an RFS that uses the resource.
The ITU M.3701 alarmState is not covered by TMF639 it can however be covered easily by linking TMF642 Alarms via the alarmedObject relationship.
The ITU M.3701 availabilityState can potentially be covered TMF656 Serviceproblem via the root CauseResource or affectedResource relationships. The mapping of this state will require some work to make the mapping work.
The ITU M.3701 standbyStatus and powerConsumingState also seem to be suitable to be mapped to ResourceFeatures.
Further to this subject I also believe that further work is needed to some of the details of the installing and retiring states. In these states, I believe there is a need for linking ProjectActivities to the Resource via a projectResource relationship. This is described very well in SID Project ABE but hasn't resulted in any OpenAPI yet.
In the planned state there could be a link to forthcoming Shipment TMF711.
Maybe this is a suggestion for a use case guide around Resources and a next version of TMF639.
------------------------------
Koen Peeters
OryxGateway
------------------------------
Original Message:
Sent: Jul 08, 2022 05:01
From: Paul Stanek
Subject: TMF639 Resource Inventory - Add Lifecycle states
Hello @Ludovic Robert
I have a question regarding this topic.
Which of these attributes should be used to represent a "planned" state?
------------------------------
Paul Stanek
Suntech S.A.
Original Message:
Sent: Jul 07, 2022 04:02
From: Ludovic Robert
Subject: TMF639 Resource Inventory - Add Lifecycle states
Hello Arko
We're following ITU guidance (M.3701 : Common management services - State management - Requirements and analysis - Protocol neutral (itu.int)
You have in the API following attribute to manage distinct state/status for your resource:administrativeState
resourceStatus
operationalState
usageState
------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF
Original Message:
Sent: Jul 06, 2022 13:28
From: Arko Chakravarty
Subject: TMF639 Resource Inventory - Add Lifecycle states
Hi Team,
I'm analyzing TMF639 Resource Inventory Management API but I don't lifecycleState attribute in tmf639 or how to manage it. Can any one please tell me how to implement lifecycle state in resource inventory
------------------------------
Arko Chakravarty
VCT International
------------------------------