Data Model for Lifecycle Management and Operations

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 8 September 2022.¶

Copyright Notice

Copyright (c) 2022 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 architecture for cloud-native infrastructure created new consumption and licensing models. Any service can be deployed by composing multiple assets together where an asset refers to hardware, software, application, system or service. For example, cloud-native infrastructure 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 any service.¶

This introduces challenges for both lifecycle and adoption management of the assets. For example, a user may need to identify the capability availability of different assets or measure the usage of each capability (or the combination) from any specific asset to measure its optimal potential. Moreover, the user could pinpoint the reason: the software application could not be optimally deployed, or is not simple to use, or is not well documented, etc. The user may use feed such measurements and analysis metrics back to the support engineers and the 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. From now on this data will be referred as Lifecycle Management and Operations (LMO); where LMO is not limited to virtualized or cloud environments, it covers all types of networking environments in which technology assets are deployed.¶

LMO data constitutes data needed to measure asset-centric lifecycle metrics including but not limited to asset adoption and usability, licensing, supported features and capabilities, enabled features and capabilities, etc. The primary objective is to facilitate the asset lifecycle management from the initial asset selection and positioning, licensing, feature enablement and usage, and beyond renewal to improve the overall user experience.¶

The main challenge in collecting LMO-related data, especially in a multi-vendor environment, relies on the ability to produce and consume such data in a vendor-agnostic, consistent and synchronized manner. APIs or telemetry are meant to collect and relay this data to receiving equipment for storing, analysis and/or visualization.¶

This document describes the motivation behind LMO, lists use cases, followed by the information model and data model of LMO. The list of use cases describes the need for new functional blocks and their interactions. The current version of this draft is focused on asset inventory, licenses information, feature usage and incident management. This draft specifies four YANG modules [RFC7950] focused on LMO, including:¶

* Licenses,
* Assets,
* Usage level of Asset features, and
* Incident Management.

This document is organized as follows. Section 2 establishes the terminology and abbreviations. In Section 3, the goals and motivation of LMO are discussed. In Section 4, use cases are introduced. Section 5 specifies the information model and the data models for LMO.¶

2. Terminology

Terminology and abbreviations used in this document:¶

• Asset: refers to hardware, software, applications, or services. An asset can be physical or virtual.¶
• Consumer: refers to an entity that utilizes the outcomes of LMO. A consumer can be a user, a developer or some other interested third party.¶
• Developer: refers to the entity that creates or develops the entire asset or the part of the asset.¶
• EOL: End of Life.¶
• Features: are options or functional capabilities available in an asset.¶
• License: is issued by an entity such as the developer or the Open Source community and allows the user to operate the asset. Licenses determine how the asset can be leveraged and what is required in cases the asset is changed.¶
• LMO: Lifecycle Management and Operations.¶
• Optimal Software Version(OSV): refers to the elected software version considered optimal in the user environment.¶
• PID: Product Identifier.¶
• Usage: refers to how features of the asset are used.¶
• User: refers to the organization that owns or consumes the asset. Within the organization there are entities that: a) use the assets in their operations, b) manage the assets.¶
• 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.¶

3. Motivation

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

1. Asset characteristic class, covering anything related to asset, license, features, etc.¶
2. Utilization class, to measure how the assets and features are used, duration of usage, uptime, etc.¶
3. Notification class, covering any security advisory, retirement, etc.¶
4. Incident class, to record and report any problem the user has faced with the asset.¶

The ability to measure, produce and consume LMO could benefit the user organization in addressing issues such as:¶

• Licenses may not have been obtained at the optimum level for a given feature, where a user might have bought licenses that are not activated.¶
• Features of an asset might not be used as needed in all deployments within the organization.¶
• Resolution of incidents involving the asset and the developer of the technology used within the asset.¶

In addition to the resolution of incidents, LMO could allow developer organizations to optimize the features they offer. For example, they could consider deprecating features that are used infrequently or focus on introducing more features for the assets that are widely deployed in various infrastructures.¶

LMO also covers the need of communication between users and the developer. LMO can provide the capability for users to provide feedback about any asset (e.g., potential deficiency of a feature, feature enhancement request). An administrator in the user organization may include specific metrics that identify a potential problem of that specific feature or a capability of the asset. An engineer in the developer organization can determine the impact of the potential deficiency from the number of users providing feedback. Note that this channel is different from a "call to a Technical Assistance Center" in which the user may request help in resolving operational issues with the asset.¶

4. Use Cases

5. Information Model

The broad metric classes defined in section 3 that quantify user experience can be modeled as shown in Figure 1. There is an inventory of all assets that the user possesses. Each asset in the inventory may be entitled to one or more licenses; a license may contain one or more sub-licenses. The level of usage for each feature and license associated with the asset is measured. For every asset, a list of incidents could be created.¶

For example, a user needs to measure the utilization of a specific license for a specific type of asset. The information about the license may reside in a license server. The state (activated or not) of the license 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 licenses. The user experience is thus enhanced by having accurate knowledge about the utility of the given license.¶

 may_be_part_of                                    may_be_part_of
   +------+                                            +-------+
   |      |                                            |       |
   |      v                                            v       |
+------------+  entitled_by            tracked_by   +------------+
|  Licenses  |<------------+          +-------------|   Usage    |
+------------+-----------+ | may_be_  | +---------->+------------+
|  License   | entitles  | | part_of  | | tracks    |   Asset    |
| attributes |           | | +------+ | |           |  Features  |
+------------+           | | |      | | |           | and usage  |
                         v | |      v v |           | attributes |
                        +----------------+          +------------+
                        |     Asset      |
          future_       +----------------+    generated_by
          association   |     Asset      |<----------------+
            +---------->|   attributes   |---------------+ |
            |           +----------------+    generates  | |
            v                                            v |
      +-----------+                                 +------------+
      |  Future   |                                 |  Incident  |
      | Expansion |                                 +------------+
      +-----------+                                 |  Incident  |
                                                    | attributes |
                                                    +------------+

                 Figure 1: Information Model

The model allows for future expansion by new metrics that will quantify user experience. Notice that future asociation relationship and future expansion might be linked to asset or to one of the other datasets: incident, feature usage or licenses.¶

6. Data Models

<CODE BEGINS> file "ietf-lmo@2022-03-01.yang"

module ietf-lmo {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-lmo";
  prefix ietf-lmo;
  import ietf-lmo-common {
    prefix ietf-lmo-common;
  }
  import ietf-yang-types {
    prefix yang;
  }
  organization
    "IETF OPSA (Operations and Management Area) Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/opsawg/>
     WG List:  <mailto:opsawg@ietf.org>
     Editor:  Jan Lindblad
              <mailto:jlindbla@cisco.com>
     Editor:  Marisol Palmero
              <mailto:mpalmero@cisco.com>";
  description
    "This YANG module add the flexibility to define its own
     and extensible set of lmo classes.

     Copyright (c) 2021 IETF Trust and the persons identified as
     authors of the code. All rights reserved.

     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject to
     the license terms contained in, the Simplified BSD License set
     forth in Section 4.c of the IETF Trust's Legal Provisions

     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX
     (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
     for full legal notices.";
  revision 2022-03-01 {
    description
      "Initial revision for LMO Module as part of the
       LMO YANG Model";
    reference
      "RFC XXXX: LMO YANG Model";
  }

  container lmos {
    //config false; //temporarily commented out for easy testing
    list lmo {
      key lmo-class;
      leaf lmo-class {
        type identityref {
          base ietf-lmo-common:lmo-class;
        }
      }
      list inst {
        key id;
        leaf id {
          type string;
        }
        container parent {
          leaf lmo-class {
            type leafref {
              path /lmos/lmo/lmo-class;
            }
          }
          leaf id {
            type leafref {
              path deref(../lmo-class)/../inst/id;
            }
          }
        }
        container capture-info {
          // Moved capture-info to the instance level, as
          // asset/... data will generally be collected
          // from one source at one time.
          description
            "Capture information for this data";
          leaf collected-on {
            type yang:date-and-time;
            description
              "Time at which this data was collected";
          }
          leaf collected-from {
            type string;
            description
              "Identifier for original source of this data";
          }
        }
      }
    }
  }

<CODE ENDS>

7. Deployment Considerations

LMO Data Models defines the data schemas for LMO data. LMO Data Models are based on YANG. YANG data models can be used independent of the transport and can be converted into any encoding format supported by the network configuration protocol. YANG is a protocol independent.¶

To enable the exchange of LMO data among all interested parties, deployment considerations that are out of the scope of this document, will need to include:¶

• The data structure to describe all metrics and quantify relevant data consistently, i.e. specific formats like XML or JSON encoded message would be deemed valid or invalid based on LMO models.¶
• The process to share and collect LMO data across the consumers consistently, including the transport mechanism. The LMO YANG models can be used with network management protocols such as NETCONF [RFC6241], RESTCONF [RFC8040], streaming telemetry, etc. OpenAPI specification might also help to consume LMO metrics.¶
• How the configuration of assets should be done.¶

8. Security Considerations

The security considerations mentioned in section 17 of [RFC7950] apply.¶

LMO brings several security and privacy implications because of the various components and attributes of the information model. For example, each functional component can be tampered with to give manipulated data. LMO when used alone or with other relevant data, can identify an individual, revealing Personal Identifiable Information (PII). Misconfigurations can lead to data being accessed by unauthorized entities.¶

Methods exist to secure the communication of management information. The transport entity of the functional model MUST implement methods for secure transport. This document also contains an Information model and Data-Model in which none 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. The information model contains several optional elements which can be enabled or disabled for the sake of privacy and security. Proper authentication and audit trail MUST be included for all the users/processes that access the LMO.¶

9. IANA Considerations

Acknowledgments

The ideas in this document originate from early work by Tony Colon, Carlos Pignataro, and Yenu Gobena originally referred to as Experience Telemetry.¶

This document was created by meaningful contributions from Josh Suhr, Eric Vyncke, Yannis Viniotis, Nagendra Kumar Nainar, Yenu Gobena, Dhiren Tailor and Jan Lindblad.¶

The authors wish to thank Gonzalo Salgueiro, Martin Beverley and many others for their helpful comments and suggestions.¶

Change log

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

version 03¶

• Flexible root structure has been introduced by the ietf-lmo YANG module: Modules are arranged into layers, with ietf-lmo-common and ietf-lmo at the core. Other modules can be added in layers on top. This structure allows flexibility and the option to be enhanced by vendor implementation.
  The new structure allows to include other lmo classes, or exclude current lmo classes.¶
• Feature and Usage containers have been split in two independent modules. Where Usage relates to runtime data.¶
• Organization attribute, has been enhanced to an independent YANG module, adding flexibility and the option to be called independently and enhanced.¶
• Service and User YANG modules, have been also introduced in a similar flexible structure, being part of new lmo classes.¶
• Information Model, has been enhanced with new modules: Organization, Service and User modules. On this version the new lmo classes can be called independently or from the licenses module. There is no restriction to be called from any of the other YANG odules.¶

version 02¶

• "Support case" renamed to "incident".¶
• Add MAC address and IP address attributes under asset-inventory YANG module.¶
• Link among objects & YANG modules (notably with feature).¶
• New text about asset usage.¶

version 01¶

• Fixes for YANG validator and idnits warnings.¶

version 00¶

• Initial version.¶

Authors' Addresses