Internet-Draft ALMO July 2024
Palmero, et al. Expires 9 January 2025 [Page]
Workgroup:
IVY Working Group
Internet-Draft:
draft-palmero-ivy-ps-almo-02
Published:
Intended Status:
Informational
Expires:
Authors:
M. Palmero
Cisco Systems
F. Brockners
Cisco Systems
S. Kumar
NC State University
C. Cardona
NTT
D. Lopez
Telefonica I+D

Asset Lifecycle Management and Operations: A Problem Statement

Abstract

This document presents a problem statement for assets lifecycle management and operations. It describes a framework, the motivation and requirements for asset-centric metrics including but not limited to, asset adoption, usability, entitlements, supported capabilities, and enabled capabilities. The document also defines an information model. The primary objective for this problem statement document is to validate and prove that the framework can measure and improve the network operators' experience along the lifecycle journey, from technical requirements and technology selection through renewal, including the end of life of an asset.

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 9 January 2025.

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].

This document aims extend and provide a snapshot of the data model draft's purpose, the issues it tackles, and the manner in which it approaches the problem, all while being concise and summarizing the key points from the more detailed future scope section.

2. Terminology

The document makes use of the following terms:

  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.

Abbreviations:

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:

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.

4.1. Entitlement Inventory and Activation

An Operator team would like to understand which entitlements are activated and which are being used, or consumed. It is also important for asset operators to understand which features might need an entitlement and how to activate them.

It is relatively straightforward to have an inventory of existing entitlements when there is only one asset developer (providing the asset) and one asset family.

But complexity grows when there are many different developers, systems and processes involved. New service offerings have introduced new attributes and datasets and require alignment with new business models (pay-per-product, subscription model, pay-as-you-go model, etc.). They might support different entitlement types and models: asset activation keys, trust-based model, systems that act as proxy from the back end owned by the asset developer to support the control of entitlements, etc.

Sometimes it is a challenge to report which entitlements have been bought by the asset user, or who in the user organization owns that entitlement because that information might rely on different asset developers; even within the same asset developer, entitlements may correspond to different types or groups of assets. Asset users often need to interact with different entitlement systems and processes.

Information on how assets are entitled could be delivered from a combination of attributes such as: sales order, purchase order, asset activation key, serial number, etc.

If there is no consistency on how to deal with those data points, complexity increases for the consumer, potentially requiring expensive manual procedures to correlate information. Automating those steps or exceptions becomes time-consuming, eventually leading to higher costs for the asset consumer.

Having a common ALMO reference eases the integration between different data sources, processes, and consolidation of the information under a common reference.

The ALMO information model and companion data models will include data to support metrics that might be required by consumption-based charging and entitlement of asset usage.

4.2. Risk Mitigation Check

Asset operators require tracking issues known by the asset developer that are causing assets to crash or perform badly so that they can act to remediate the issue quickly, or even prevent the crash if alerts are triggered on time. There are analytics tools that can process memory core dumps and crash-related files, providing the ability to the asset developers to determine the root cause.

Accordingly, asset users can remediate the problem, automate the remedy to enable incident deflection, allowing the support staff to focus on other problems.

Risk Mitigation Check (RMC) could also include the possibility to be aware of current and historical restarts allowing network and software engineers to enhance the service quality to asset users. Also RMC could run what-if scenarios to identify which assets would be impacted when a certain component is faulty.

4.3. Bug Fixes and Errata

Both hardware and software critical issues or Errata need development to automate asset user matching:

  • Hardware Errata match on product identifiers (PIDs) + serial numbers along with additional hardware attributes.

  • Software Errata match on software type and software version along with some additional device attributes.

Engineering might develop the logic to check whether any critical issue applies to a single serial number or a specific software release.

The information to be correlated includes customer identification, activated features, and asset information that the asset user might own. All this information needs to be correlated with hardware and software errata, and EOL information to show which part of the asset inventory might be affected.

4.4. Security Advisory

The Security Advisory use case automates the matching of asset user data to security bulletins published by asset developers.
Security Advisory logic implemented by developers could apply to a specific software release.

This is a specific use case of Section 4.3.

4.5. Optimal Software Version

The objective of the Optimal Software Version (OSV) use case is that consumers can mark software images as OSV for their assets; based on this, it is easier for them to control and align their hardware and software assets to the set of OSVs.

Based on the logic of OSV, use cases like software compliance, risk trend analysis, acknowledge bugs, security advisories, errata, what-if analysis, etc., could be realized.

4.5.1. Software Conformance

All the assets should normally be running at their latest recommended software version; notably in case of a required security update for a specific feature. The recommended version may be a decision of the vendor or the operator.

The Software Conformance use case provides a view to the asset users and informs the users whether the assets that belong to a specific group conforms to the OSV. It can provide the users with a report, including a representation of software compliance for the entire network and software applications. This report could include the current software version running on the asset and the recommended software version. The report could enable users to quickly highlight which group of assets might need the most attention to inspire appropriate actions.

The Software Conformance use case uses data that might not be provided by the asset itself. Data needs to be provided and maintained also by the asset developers, through e.g., asset catalog information. Similar logic applies to a feature catalog, where the asset developer maintains the data and updates it adequately based on existing bugs, security advisories, etc.

The Software Conformance process needs to correlate the software catalog information with the software version running on the asset.

4.5.2. What-if Analysis

The What-if Analysis use case allows asset users to plan for new hardware or software, giving them the possibility to change the configuration parameters or model how new hardware or software might change the software suggestions generated by OSV.

OSV and the associated use cases involve dependencies on attributes that might need to be collected from assets directly, including related inventory information (serial numbers, asset identifiers, software versions, etc.), but also dynamic information could be required, like:

  • Information on features that might be enabled on the particular asset.

  • Catalogs, that might include information related to release notes. For example, consider a feature catalog. This catalog could include software versions that support a specific feature; the software releases that a feature is supported in; or the latest version that a feature is supported in, in case the feature is EOL.

  • Data sources to correlate information coming from reports on critical issues or errata, security advisory, End of Life, etc.

Those catalogs and data sources with errata information, EOL, etc. need to be maintained and updated by asset developers, making sure, that the software running on the assets is safe to run and up to date.

4.6. Asset Retirement - End of Life

Hardware EOL reports need to map Hardware EOL PIDs, focusing on base PIDs so that bundles, spares, non-base PIDs, etc., do not provide false EOL reporting to asset users.

Software EOL reports are used to automate the matching of user software type and software version to software EOL bulletins.

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  |
                +---------------+
Figure 1: ALMO Information Model

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 02

version 01

version 00

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.

Informative References

[I-D.draft-palmero-opsawg-dmlmo-10]
Palmero, M., Brockners, F., Kumar, S., Bhandari, S., Cardona, C., and D. Lopez, "Data Model for Lifecycle Management and Operations", Work in Progress, Internet-Draft, draft-palmero-opsawg-dmlmo-10, , <https://datatracker.ietf.org/doc/html/draft-palmero-opsawg-dmlmo-10>.
[I-D.draft-palmero-opsawg-ps-almo-00]
Palmero, M., Brockners, F., Kumar, S., Cardona, C., and D. Lopez, "Asset Lifecycle Management and Operations, Problem Statement", Work in Progress, Internet-Draft, draft-palmero-opsawg-ps-almo-00, , <https://datatracker.ietf.org/doc/html/draft-palmero-opsawg-ps-almo-00>.
[RFC7950]
Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, , <https://www.rfc-editor.org/rfc/rfc7950>.

Authors' Addresses

Marisol Palmero
Cisco Systems
Frank Brockners
Cisco Systems
Sudhendu Kumar
NC State University
Camilo Cardona
NTT
Diego Lopez
Telefonica I+D