Asset Lifecycle Management and Operations: A Problem Statement

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 22 April 2024.¶

Copyright Notice

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The virtualization of hardware assets and the development of applications using microservice architectures for cloud-native infrastructures triggered new utilization and licensing models. For example, a service can be deployed by composing multiple assets together; where an asset refers to hardware, software, application, system or another service. Also, services can be instantiated on-demand. As an example, cloud-native services from one vendor may be hosted on the physical server from another vendor or a combination of multiple cloud-native functions from one or more vendors can be combined to execute a composite service.¶

Such dynamicity introduces challenges for both lifecycle and adoption management of the assets. For example, an operator may need to identify the capability availability of different assets or measure the usage of each capability (or the combination thereof) from any specific asset to measure, e.g., its optimal potential. Moreover, an operator could pinpoint the reason of this non-nominal use of an asset, e.g., the software application could not be optimally deployed because is not simple to use, or the usage is not well documented, etc. The operator may then feed this information back to the support teams and the software developers, so they can focus their work effort only on features that users are adopting, or even determine when the lifecycle of the development could end.¶

This creates the need to collect and analyze asset-centric lifecycle management and operations data. This data is referred to as Asset Lifecycle Management and Operations (ALMO). Note that ALMO is not limited to virtualized or cloud environments, it covers all types of networking environments in which technology assets are deployed. No assumption is made about which technology is used to implement an asset.¶

ALMO data is the set of data required to measure asset-centric lifecycle metrics including, but not limited to, asset adoption and usability, entitlement, supported capabilities , and enabled capabilities.¶

The main challenge in collecting ALMO data, especially in a multivendor environment, is the ability to produce and consume such data in a vendor-agnostic, consistent, and synchronized way. Another challenge is to maintain/cleanup the data (e.g., update it with external data such as End of Support (EoS)).¶

This document describes the motivation for ALMO, lists sample use cases, followed by an ALMO information model. The use cases motivate the need for new functional blocks and their interactions. The current version of this document focuses on assets, entitlement information, features, and feature's usage. A more specific document will follow this reference with the specification of the YANG data model for the specific four modules [RFC7950].¶

2. Terminology

The document makes use of the following terms:¶

• Asset: refers to hardware, software, applications, or services. An asset can be physical or virtual. The granularity of what constitutes an asset is deployment and implementation specific.¶

• Consumer: refers to an entity that utilizes the ALMO data. A consumer can be an operator, an asset developer, or some other interested third party. Also, network controllers or orchestrators may be considered as consumers under some conditions.¶

• Developer: refers to the entity that creates or develops an asset or an asset component.¶

• Features: are options or functional capabilities offered by an asset.¶

• Entitlement: commonly implemented as license; it represents the rights obtained by the user, that allow them to access and utilize certain capabilities of the asset, including a feature or set of features.¶

• Event report: refers to record of details of an incident that an operator reports, e.g., a trouble ticket.¶

• Lifecycle Management and Operations (LMO) connects to:¶

1. Assets as a generalized entity subject to LCM.¶

2. Entitlements as the essential policy root for LCM.¶

3. Metrics as the evidence for LCM transitions.¶

4. Reports (no incidents) as the way of collecting input from users.¶

• Optimal Software Version (OSV): refers to the elected software version considered optimal in the consumer environment.¶

• Operator: refers to the owner or consumer of the asset. An operator belongs to an organization. Within the organization there are entities that use the assets in their operations and those who manage the assets. For example, supply chain and risk management teams will also be operators by running “what-if” scenarios to anticipate decommissioning operations or assess the impact of component exhaustion, etc. This document uses the terms "user" and "operator" interchangeably.¶

• Usage: refers to how an asset is being used (e.g., which features are used).¶

• User Experience: how a user interacts with and experiences a particular asset. It includes a user's perceptions of ease of use, efficiency, and utility of an asset.¶

Abbreviations:¶

• ALMO: Asset Lifecycle Management and Operations¶

• EoL: End of Life¶

• EoS: End of Support¶

• LCM: Lifecycle Management¶

• PID: Product Identifier¶

3. Motivation

The operator experience with a specific asset can be organized into four classes:¶

1. Asset characteristic class: covering a set of data that characterize an asset, entitlement, features, etc.¶

2. Utilization class: measuring how the assets, including the features, are used, duration of usage, uptime, etc.¶

3. Notification class: covering any security advisory, retirement, etc.¶

4. Incident class: recording and reporting problems that an operator has faced with an asset.¶

The ability to measure, produce, and consume ALMO data could benefit the operator in addressing issues such as:¶

• Entitlements may not have been obtained at the nominal level of usage for a given asset or feature, where a user might have bought entitlements that are not activated. Defining a nominal level is local to each deployment.¶

• Features of an asset might not be used as needed in all deployments within the organization and for various reasons.¶

• Resolution of incidents involving an asset and the developer of a technology used within the asset.¶

• Optimal and correct form of entitlements have not been purchased for virtualized asset lifecycle events, such as scaling or migration.¶

• Softwares versions go out of conformance; ALMO data can help in facilitating DevOps deployment, including automated testing, validation, pre-production, production, and certification¶

• Supply chain disruption; ALMO data can help with a link to supply chain management and/or connect it with the provenance information.¶

ALMO could help developer organizations to optimize their features. For example, they could consider deprecating features that are used infrequently, focus on introducing more features for the assets that are widely deployed in various infrastructures, or adjust the design to better ease usability or ease integration, etc.¶

ALMO provides a structured approach for users to provide feedback about an asset (e.g., potential deficiency of a feature, feature enhancement request, inadequacy of a usage-based license model). An administrator in the user organization may define and thus include specific metrics that identify a potential problem of a specific asset feature . A developer can determine the impact of the potential deficiency from the number of users providing feedback or the amount/periodicity of feedback (e.g., enrollment, updates). Note that this channel is different from a "call to a Technical Assistance Center" in which the user may request help in resolving specific operational issues with the asset.¶

4. Sample Use Cases

This section presents some use cases where ALMO is useful.¶

5. ALMO Information Model

The broad metric classes defined in Section 3 that quantify user experience can be modeled as shown in Figure 1. There is a reference to the assets that the user possesses. Each asset may be entitled to one or more entitlements; an entitlement may contain one or more sub-entitlements. The level of usage for each feature and entitlement associated with the asset is measured.¶

For example, a user needs to measure the utilization of a specific entitlement for a specific type of asset. The information about the entitlement may reside in an entitlement server. The state (activated or not) of the entitlement may reside with the asset itself or a proxy. They can be aggregated/correlated as per the information model shown in Figure 1 to give information to the user regarding the utilization of the entitlements. The user experience is thus enhanced by having accurate knowledge about the utility of the given entitlement.¶

    +------entitled_by/entitles------+
    |                                |
    V                                V
+-------------+               +------------+    +-------------+
| Entitlement |               |   Feature  |<-->|    Usage    |
|             |<----+   +---->+            |    +-------------+
+-------------+     |   |     +------------+    |             |
| Entitlement |     |   |     |   Feature  |    |    Usage    |
| attributes  |     |   |     | attributes |    |  attributes |
+-------------+     |   |     +------------+    +-------------+
                    |   |
        entitled_by/|   |
          entitles  |   | tracked_by/
                    |   |   tracks
                +---v---v-------+              +---------------+
                |     Asset     +<------------>|     Future    |
                +---------------+    future_   |    Expansion  |
                |     Asset     |  association +---------------+
                |   attributes  |
                +---------------+

To simplify the information model diagram, it has not been included a representation that considers assets, to be defined by other assets; as well as entitlements and features. Entitlements could be considered as a composition of one of more entitlements, and a feature could also be part of other features. The model allows for future expansion by new metrics that will quantify user experience. Notice that future association relationship and future expansion might be linked to asset or to one of the other datasets: Feature, Feature Usage or Entitlements.¶

6. Security Considerations

ALMO will bring several security and privacy implications because of the various components and attributes when defining the YANG modules of the information model. For example, each functional component can be tampered with to give manipulated data. ALMO when used alone or with other relevant data, can identify an individual, revealing personal data. Misconfigurations can lead to data being accessed by unauthorized entities.¶

The transport entity of the functional model must implement methods for secure transport. This document also contains an Information model in which some of the objects defined are writable. If the objects are deemed sensitive in a particular environment, access to them must be restricted using appropriately configured security and access control rights. Appropriate authentication and audit procedures must be in place for all the consumers of ALMO.¶

Change log

RFC Editor Note: This section is to be removed during the final publication of the document.¶

version 00¶

• Reference to [I-D.draft-palmero-opsawg-dmlmo-10] draft and [I-D.draft-palmero-opsawg-ps-almo-00], looking to simplify the objective and understanding of it, with focus on the framework and the main functional models, reducing scope to assets, features, usage and entitlements; with special highlight to the interrelation between them.¶

• Work moved to IVY working group.¶

Acknowledgments

The authors wish to thank Martin Beverley, Mohamed Boucadair, Ignacio Dominguez Martinez-Casanueva, and Gonzalo Salgueiro (by alphabetical order) for their helpful comments and suggestions.¶

Contributors

This document was created by meaningful contributions (by alphabetical order) from Shwetha Bhandari, Yenu Gobena, Nagendra Kumar Nainar, Jan Lindblad, Josh Suhr, Dhiren Tailor, Yannis Viniotis, and Éric Vyncke.¶

Authors' Addresses