Sustainability Insights

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

To answer questions about how sustainable equipment and operational practices are, various key performance indicators (KPIs) produced by network devices, management systems, and networking solutions are necessary. While such KPIs are abundantly produced and collected today there are quite a few issues with their usability and commonality. Without a common definition of metrics across the industry and widespread adoption, we will be left with ill-defined, potentially redundant, and proprietary metrics.¶

An aspect lacking today is the precise definitions of the collected metrics. This leads to KPIs that are not comparable to each other, as it is unknown what is included in the outcomes and what is not. It makes it challenging to sum or compare numbers from different manufacturers and organizations without investing in data normalization and a high number of assumptions.¶

To produce aggregate data, it is also important to consider how the component inputs are combined. Different vendors and operators might do this aggregation differently, yet again producing values that are hard to combine or compare when also using different units of measurement. In many cases, one might suspect the actual numbers are underestimated, since there is competitive pressure to produce small numbers to report on the environmental impact of Internet communications and applications in contrast with the benefit of using it. The aim shall not be to "produce the numbers" but to find quantitative measures, when possible, that give a fair assessment of Sustainability related metrics vs. useful work.¶

It may be tempting to define the useful work in networking equipment as simply as the number of bits that are passing through the device. For some types of equipment, that might be appropriate, but clearly a video system that is sending a video stream with better video compression is not necessarily less sustainable just because it sends fewer bits per Joule. There are also many kinds of networking equipment where measuring the end user value in number of passed bits is obviously ridiculous, and other metrics have to be defined. Monitoring or management systems are examples of this.¶

Another important and key aspect, when referring to environmental impact metrics is what needs to be considered as part of the lifecycle. Life cycle assessment, also known as LCA, of networks and services, is defined by ISO 14040 as the compilation and evaluation of the inputs, outputs, and potential environmental impacts throughout its lifecycle.¶

LCA is based on four main phases:¶

• Goal and Scope¶

• Inventory Analysis¶

• Impact Assessment¶

• Interpretation¶

This document is setting up the stage to identify data quality requirements, under the information and communications technology (ICT) category. Following product Lifecycle Accounting (LCA), this document focuses on using the five product lifecycle stages defined by the GHG Protocol Accounting and Reporting Standard, which is in accordance with the ISO 14040:44 standards:¶

1. Use¶

2. Manufacturing¶

3. Material Acquisition / Processing¶

4. Transport¶

5. End of Life¶

Impact and interpretation will be briefly covered under the document's motivation and use cases sections.¶

There is reason to suspect that nebulous definitions combined with the competitive pressure might produce greenwashing. Greenwashing involves making an unsubstantiated claim to deceive consumers into believing that a vendor's product or solution is environmentally friendly or has a greater positive environmental impact than it does. This document proposes the following initiative to counter these effects.¶

2. Terminology

Terminology and abbreviations used in this document:¶

Asset

Hardware, software, applications, or services. An asset can be physical or virtual.¶

Greenwashing

Marketing (intentionally or not) an asset as being green (i.e. fitting well into the circular economy) by selectively omitting less green aspects of the asset.¶

Circular economy

An economic paradigm in which the full lifecycle cost of resource use and emissions are included.¶

Climate change

The disruption of ecological processes caused by excessive resource use or emissions.¶

3. Motivation

Aside from the need for consistency on metrics to be considered as part of the ICT sector, to reduce environmental impact and increase benefit; this document and future work related, aim to support the Digital Product Passport initiative under the European Union's (EU's) Circular Economy Action Plan (CEAP) and the Ecodesign for Sustainable Products Regulation (ESPR). There is not much time for businesses to prepare and for IETF work to influence this development.¶

The Digital Product Passport (DPP) is key to the EU’s transition to a circular economy and will provide information about assets' environmental sustainability. It aims to improve traceability and transparency along the entire value chain of an asset and to improve the management and sharing of product-related data which are critical to ensuring their sustainable use, prolonged life, and circularity.¶

There is a need to:¶

• Track raw materials extraction/production, supporting due diligence efforts¶

• Enable manufacturers to increase transparency in the value chain, better compliance, increased circularity, and sustainability¶

• Enabling services related to its remanufacturing, reparability, second-life, and recyclability, enabling sustainable business models.¶

In the case of upgrading, repairing, repurposing, or remanufacturing a product, it should be clear the responsibility to update the information is transferred to the installer, repairer, or remanufacturer who will be putting the product into service or placing it on the EU market.¶

The three main target groups of the passport are:¶

• Public authorities and policymakers: reliable information on compliance of products with EU legislation¶

• Economic operators (such as recyclers): information on proper dismantling and waste treatment of products; the presence of Substances of Very High Concern (SVHCs) through a link to the SCIP database; etc.¶

• Consumers: instructions for use, information on repair centers, sorting instructions, and other information as required by existing EU legislation (e.g. CLP regulations), more information about products would be made available to consumers and customers to enable informed choices.¶

The DPP will help business planners and consumers make informed choices when purchasing assets, and should also help local and public authorities to better perform checks and controls.¶

4. Next Steps

To enable the exchange of sustainability data among all interested parties at each step of the value supply chain, a technical sustainability framework for how this data is queried, transported, and visualized will be required.¶

5. Use Cases

6. Architecture Framework

This section proposes a reference architecture for Sustainability Insights framework.¶

The following picture shows an example of how a framework like this could look like in a small data center use case.¶

Each component has a type (top line, in capitals), a name (lines below), and an id for reference (number in the lower right).¶

                      +-----------------+
                      | USER INTERFACE  |
                      |    Dashboard    |
                      |                 |
                      +--------------11-+
                               |
                      +-----------------+
                      |    PROCESSOR    |
                      | Recommendation  |
                      |     Engine      |
                      +--------------21-+
                               |
                      +-----------------+
                      |   AGGREGATOR    |
                      |   Data Center   |
                      +--------------31-+
                               |
       +---------------+-------+-------+--------------+
       |               |               |              |
+------------+  +------------+  +------------+  +------------+
| PROCESSOR  |  | AGGREGATOR |  | AGGREGATOR |  | AGGREGATOR |
| Normalizer |  |  Network   |  |  Storage   |  |  Compute   |
+---------41-+  +---------42-+  +---------43-+  +---------44-+
       |           |                   |\             |\
+------------+     |     +------+------------+  +------------+------+
| COLLECTOR  |     |     | YANG | COLLECTOR  |  | COLLECTOR  | YANG |
|  Cooling   |     |     +---52-+ Storage 1  |  | Compute 1  +---55-+
+---------51-+     |            +---------53-+  +---------54-+
       |           |             \ Storage 2  \  \ Compute 2  \
+------------+     |              +------------+  +------------+
|  PROVIDER  |     |               \ Storage N  \  \ Compute N  \
|Utility Bill|     |                +------------+  +------------+
+---------61-+     |
                   +--------------+
                   |              |
            +------------+  +------------+
            | COLLECTOR  |  | PROCESSOR  |
            |  Router 1  |  | Normalizer |
            +---------71-+  +---------72-+
                   |              |
            +------------+  +------------+
            |  PROVIDER  |  | COLLECTOR  |
            |  Router 1  |  | Firewall 1 |
            +---------81-+  +---------82-+
                                  |
                            +------------+
                            |  PROVIDER  |
                            | Firewall 1 |
                            +---------92-+

In the above diagram, each component may be procured from a commercial provider, obtained as open source, or developed from scratch by the deploying organization. The reference design project would contain a base collection of components of each type. Typical controllers would implement multiple, possibly all, controller functions in a single system, in which case each box above translates to a piece of configuration.¶

The key aspect of this architecture is the interfaces between the components. These interfaces are specified in YANG. The YANG interface may then be mapped to a variety of wire protocols.¶

7. Deployment Considerations

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

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

• The data model definition¶

• The data structure to describe all metrics and quantify relevant data consistently, i.e. specific formats like XML or JSON encoded messages would be deemed valid or invalid based on Sustainability Insights models.¶

• The process to share and collect Sustainability Insights data across the consumers consistently, including the transport mechanism. The Sustainability Insights YANG models can be used with network management protocols such as NETCONF [RFC6241], RESTCONF [RFC8040], streaming telemetry, etc. OpenAPI specifications might also help to consume Sustainability Insights metrics.¶

• How the configuration of assets to implement Sustainability Insights telemetry should be done.¶

It will be important to consider where, when, and how often the data will need to be collected. As per the specification of the data, data might need to be collected from different data sources: network devices, and different databases where manufacturing information is stored and maintained. Ideally all this information can be extracted via a well-defined API. The frequency to collect the data will also vary, for instance, comparing manufacturing data with runtime data. For example, it might be a good practice to collect inventory data once per day, while “environmental” data might need to be updated hourly or even more frequently. It will also be important to consider the platform from where data might be collected, and the need to properly correlate all the information.¶

8. Security Considerations

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

Sustainability Insights 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. Sustainability Insights 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 Sustainability Insights Telemetry Data.¶

Change log

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

version 02¶

• includes explanation and new diagram for the architecture framework, and Use Case VI.¶

version 01¶

• includes architecture framework section.¶

version 00¶

• Initial version of the draft.¶

Acknowledgments

This document was created by meaningful contributions from Jeff Apcar, Klaus Verschure and Suresh Krishnan.¶

The authors wish to thank them and many others for their helpful comments and suggestions.¶

Authors' Addresses