Sustainability Insights
draft-almprs-sustainability-insights-03
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Per Andersson , Jan Lindblad , Snezana Mitrovic , Marisol Palmero , Esther Roure , Gonzalo Salgueiro , Emile Stephan | ||
| Last updated | 2024-05-07 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-almprs-sustainability-insights-03
Network Working Group P. Andersson
Internet-Draft J. Lindblad
Intended status: Informational S. Mitrovic
Expires: 8 November 2024 M. Palmero
E. Roure
G. Salgueiro
Cisco Systems
E. Stephan
Orange
7 May 2024
Sustainability Insights
draft-almprs-sustainability-insights-03
Abstract
Internet and the ICT industry is consuming a sizable portion of the
electricity available in the world today, and the fraction has been
growing significantly over time. Data shows that the power draw of
internet is relatively constant over the day and week, even though
the “load” and delivered services vary greatly over this time span.
This seems to suggest that there is room for optimizations.
This document provides some definitions, some proposed principles for
a solution, and then paints a picture of what a solution based on
existing standards and some current internet drafts might look like.
The first step of an optimization loop is to measure. This document
proposes a mechanism to collect energy related telemetry data from
the extremely diverse set of devices found in networks today, without
necessarily updating the network elements. Once the collection is
done, it’s also very relevant to be able to control the devices, and
turn them into low power modes when the service demand is lower.
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/.
Andersson, et al. Expires 8 November 2024 [Page 1]
Internet-Draft Sustainability Insights May 2024
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 November 2024.
Copyright Notice
Copyright (c) 2024 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The Sustainability Telemetry Standard Specification . . . 5
1.2. Requirements language . . . . . . . . . . . . . . . . . . 7
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Use Case I . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Scenario ‘monitoring power’ . . . . . . . . . . . . . 9
4.1.2. Sustainability Insights Added Value . . . . . . . . . 9
4.2. Use Case II . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Scenario ‘migration’ . . . . . . . . . . . . . . . . 9
4.2.2. Sustainability Insights Added Value . . . . . . . . . 10
4.3. Use Case III . . . . . . . . . . . . . . . . . . . . . . 10
4.3.1. Scenario ‘recycling’ . . . . . . . . . . . . . . . . 10
4.3.2. Sustainability Insights Added Value . . . . . . . . . 10
4.4. Use Case IV . . . . . . . . . . . . . . . . . . . . . . . 10
4.4.1. Scenario ‘power optimization’ . . . . . . . . . . . . 10
4.4.2. Sustainability Insights Added Value . . . . . . . . . 11
4.5. Use Case V . . . . . . . . . . . . . . . . . . . . . . . 11
4.5.1. Scenario ‘sustainability cost’ . . . . . . . . . . . 11
4.5.2. Sustainability Insights Added Value . . . . . . . . . 11
4.6. Use Case VI . . . . . . . . . . . . . . . . . . . . . . . 12
4.6.1. Scenario ‘switch off’ . . . . . . . . . . . . . . . . 12
4.6.2. Sustainability Insights Added Value . . . . . . . . . 12
5. Proposals for a Solution . . . . . . . . . . . . . . . . . . 13
Andersson, et al. Expires 8 November 2024 [Page 2]
Internet-Draft Sustainability Insights May 2024
5.1. Basic Principles . . . . . . . . . . . . . . . . . . . . 13
5.1.1. Describe the Collected Data using YANG . . . . . . . 13
5.1.2. Work with Existing Equipment . . . . . . . . . . . . 13
5.1.3. New Systems that want to be Helpful . . . . . . . . . 13
5.1.4. Time Series Database (TSDB) Storage . . . . . . . . . 13
5.1.5. Define Telemetry Component Roles: Providers,
Collectors, Aggregators, Processors . . . . . . . . . 14
5.1.6. Add YANG and Metadata where missing, and keep the
Metadata with the Data . . . . . . . . . . . . . . . 14
5.1.7. Transparency: Solid YANG to Time Series Database (TSDB)
Mapping . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. The Sustainability Framework . . . . . . . . . . . . . . 15
5.3. The Framework Architecture . . . . . . . . . . . . . . . 15
6. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Reaching Methodological Agreement . . . . . . . . . . . . 18
6.1.1. Need to Agree on What and How to Measure . . . . . . 18
6.1.2. Need to Agree on What and How to Aggregate . . . . . 18
6.1.3. Let’s bring in the Economists from SBTi, GHGP,
etc. . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2. Expanding the Scope . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . 19
Change log . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
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.
Andersson, et al. Expires 8 November 2024 [Page 3]
Internet-Draft Sustainability Insights May 2024
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
Andersson, et al. Expires 8 November 2024 [Page 4]
Internet-Draft Sustainability Insights May 2024
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.
1.1. The Sustainability Telemetry Standard Specification
As an industry, we need to cooperate and agree on a set of core KPIs
that are measured, including the definition of terms, units, and
measurement procedures. What is included, and what is not included.
Sustainability metrics require a broad diversity of data sources that
need to be combined.
* Static information. Data coming from manufacturing, including
reference values on how the assets have been designed if they
enable reuse and recycling, and which materials have been used
during manufacturing and packaging; normally this information is
defined once and it is part of data sheets provided by the
vendors.
* Dynamic data. Information measured in real-time or close to real-
time from the networking equipment or application. For instance,
metrics should consider current inventory and current source and
amount of consumed power, as well as what hardware and software
features are enabled and used by the specific network equipment.
* Best practices. Recommendations for optimizing the use of the
network equipment, throughout its complete lifecycle.
* Local context. Country-specific regulations, corporate policy,
and social aspects.
Andersson, et al. Expires 8 November 2024 [Page 5]
Internet-Draft Sustainability Insights May 2024
To enable the exchange of sustainability data among all interested
parties, deployment considerations that are out of the scope of this
document will need to include:
* Data models. The model definition can be implemented in different
forms. This document proposes YANG as part of the Specification
Data Model. YANG can be used independently of the transport and
can be converted into any encoding format supported by the network
configuration protocol. YANG models are decoupled from the
management protocol layer.
* Sustainability framework. To drive adoption, we propose an open-
source aggregation framework for sustainability data. This
framework should be seen as a reference architecture for a
sustainability monitoring mechanism. While each implementation
may be (and will be) different, the basic framework shall remain
constant. The framework must account for vendor-specific
calculations and enhancements in a plug-in architecture.
YANG data models as part of the Sustainability Telemetry
Specification, which will follow this document, have been classified
as follows:
* Identification of the assets. Assets include hardware (physical
as well as virtual), software, applications, and services. The
asset concept is defined in the Data Model for Lifecycle
Management and Operations (DMLMO)
[I-D.draft-palmero-ivy-dmalmo-01] IETF draft.
* Power and Efficiency. To measure power consumption and energy
efficiency, common methods, attributes, and units are needed to
define metrics. The approach needs to cover the different
networking domains, starting with hardware focus, but including
software and protocols attributes and metrics.
* Circular Economy attributes. Collecting circularity data (such as
materials used, or the embedded emissions footprint) is expensive
and difficult because of confidentiality and the non-standardized
approach to reporting and exchanging circularity data. The flow
of circularity data is typically lost at each step throughout the
supply chain, as goods are passed through suppliers,
manufacturers, system integrators, distributors, customers, and
consumers into reuse and recycling.
* Context metrics. Without understanding the context of the use,
none of the metrics listed above will provide much value. The
carbon intensity of the power used, for example, is key to
assessing the sustainability of a given application. An
Andersson, et al. Expires 8 November 2024 [Page 6]
Internet-Draft Sustainability Insights May 2024
efficiency number needs to be interpreted differently at peak
hours and night. A given usage may be considered less sustainable
if someone demonstrates the ability to deliver the same end-user
value with a smaller footprint. A system that is transported a
shorter distance or using a more sustainable mode of
transportation from the factory to the installation site may also
be assessed more positively. Or if it has a longer economic life
or comes with less single-use packaging.
The model definition can be implemented in different forms. We would
like to propose a specific YANG model for the sustainability metrics,
which intrinsically allows for a variety of collection protocols.
YANG can be used independently of the transport protocol, and lends
itself well to be converted into a variety of encoding formats
supported by popular network configuration protocols.
The rest of this document is organized as follows. Section 2
establishes the terminology and abbreviations. Section 3 outlines
the goals and motivation of Sustainability metrics. Section 4
discusses Use Cases that lay out the groundwork for the
Sustainability Telemetry Specification, to address new business needs
introduced by the Circular Economy and to avoid excessive climate
change. Section 5 proposes principles for and a solution based on
existing standards and current internet drafts. Section 6 lists
ideas for future development of this work.
1.2. Requirements language
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and
“OPTIONAL” in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
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.
Andersson, et al. Expires 8 November 2024 [Page 7]
Internet-Draft Sustainability Insights May 2024
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.
Andersson, et al. Expires 8 November 2024 [Page 8]
Internet-Draft Sustainability Insights May 2024
* 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. Use Cases
4.1. Use Case I
4.1.1. Scenario ‘monitoring power’
An organization is running a large and complex network with many
types of devices. By looking at the utility bills, it is clear that
the organization is consuming rather more energy per transported bit
than many other organizations. Exactly which devices or network
functions are at the root of the situation is unclear, however.
The product LCA in this scenario applies to the stage of “Use”.
4.1.2. Sustainability Insights Added Value
By providing near-real-time data that is broken down at least to an
individual hardware device, and ideally considerably deeper than
that, it will be possible to attribute energy and environmental
footprint costs to different device types, service types, and
individual customers.
If one customer is altering its behavior or load on the network, a
monitoring application could detect this quickly. It would also be
possible to try several implementations or configurations for a given
service and get quick feedback on the operations cost of that change.
4.2. Use Case II
4.2.1. Scenario ‘migration’
An organization is running a network with a variety of managed
services and applications. Some of the devices are getting old, and
have lower energy efficiency than more modern devices. Replacing old
devices with new ones might improve efficiency, but has an economical
as well as environmental cost. Without specific performance data, it
is difficult to make informed decisions about upgrades.
Andersson, et al. Expires 8 November 2024 [Page 9]
Internet-Draft Sustainability Insights May 2024
The product LCA stage applies to “Use”.
4.2.2. Sustainability Insights Added Value
By providing KPIs for reading sustainability parameters that pertain
to actual usage, rather than numbers from data sheets, the accuracy
of upgrade decisions is enhanced. Such data can make the case for an
upgrade very clear and easy to make, or it may show that it’s not a
good idea at this time. In both cases improving the sustainability
of the operations.
4.3. Use Case III
4.3.1. Scenario ‘recycling’
Recycling and reuse are major drivers of the circular economy.
Companies must put high efforts in this direction and transparency.
This is a qualitative KPI, passed if percentages of recycled and
reused goods given the manufacturing options, as well as reports
listing how many units have been recycled.
The product LCA applies to the stage of “Material Acquisition /
Processing”.
4.3.2. Sustainability Insights Added Value
The trend seems to be to report on the percentage of recycled user
devices and the eco-design and refurbishment efforts. Sustainability
Insights can enable the data sources to report comprehensive
reporting of recycling efforts.
4.4. Use Case IV
4.4.1. Scenario ‘power optimization’
An organization is running a network with a variety of managed
services and applications. The network and application performance
is continuously monitored, and there are even some automatic
remediation actions that may trigger when certain conditions are
detected.
In this scenario, the product LCA applies to the stage of “Use”.
Andersson, et al. Expires 8 November 2024 [Page 10]
Internet-Draft Sustainability Insights May 2024
4.4.2. Sustainability Insights Added Value
By providing KPIs for sustainability parameters such as power
consumption and power efficiency, the monitoring system can access
relevant data and perform actions that reduce the power consumption
or sustainability footprint of the delivered services.
For example, some overlay redundant links or systems may be powered
off at non-pick hours, or enter into a low-power mode. A highly
available application may be configured to take more load in the data
center with a lower price of energy, lower outside temperatures, or
an environmentally superior energy mix.
4.5. Use Case V
4.5.1. Scenario ‘sustainability cost’
IT solutions are currently analyzed from two main perspectives:
technological and economical. When looking at environmental, social,
and corporate governance (ESG) impact topics, sustainability metrics
in the context of digital transformation, deliver insights into
opportunities and risks that emerge from a rapidly growing
stakeholder demand for sustainable, digitally advanced products and
services.
The product LCA applies to all stages under its lifecycle.
4.5.2. Sustainability Insights Added Value
From an application point of view, this use case proposes to include
Sustainability factors in the Total Cost of Ownership (TCO)
calculation, where there is a need to add Environmental, Social, and
Governmental Key Performance Indicators (KPIs) to the analysis.
However, adding Sustainability metrics comes with challenges and
trades-off. Future work considers a model to calculate the Total
Sustainability Cost of Ownership (TSCO) for network solutions based
on the ESG Materiality Matrix. This model is open to adding any
implementation that takes into consideration Sustainability
objectives at a point in time, but it also evolves with the needs of
the business and the stakeholders. The initial scope proposes to
investigate the top four most important ESG Materiality issues as a
base to grow the TCO to a TSCO that matches the Company’s priorities
and issues.
Future work might include use cases that will cover “Manufacturing”,
“Transport” and “End of Life” examples.
Andersson, et al. Expires 8 November 2024 [Page 11]
Internet-Draft Sustainability Insights May 2024
4.6. Use Case VI
4.6.1. Scenario ‘switch off’
WIFI is deployed in any famous stadiums around the world. It is
common for such networks to rely on several thousands of Access
Points (APs).
Such networks are very dense and designed to separate finely fans
connections from business operations (ticketing, …).
Such WIFI network activity varies in time and follow a well-known
calendaring (but not as trivial as the match calendar). It is
obvious that the bigger part of a stadium WIFI network footprint is
most of the time unused at all.
Current WIFI management tools are not designed to stop and restart
the APs automatically following a schedule. In 2022 Orange and Cisco
implemented practical actions to lower the power consumption of the
WIFI APs of the Orange velodrome of Marseille. The experimentation
was able to save 20% of the APs power consumption without modifying
the infrastructure. The experimentation shown that the current
design of network operation tools need to be updated to save up to
50%.
Stadium and arenas WIFI network are made of a very limited number of
clusters. There are WIFI networks similar in size which are by far
more constraint in term of calendaring and capillarity. In France,
banks have thousands of branches. See Number of bank branches in
France (https://www.statista.com/statistics/744109/french-banks-
branches-number/).
NB: APs are not per designed build to support numerous cold restarts.
This may impacts TSCO
4.6.2. Sustainability Insights Added Value
Being able to stop and restart WIFI APs with the right time, space
and service granularity.
From an operation point of view, this use case proposes to save power
consumption during periods the APs are not in-used.
Andersson, et al. Expires 8 November 2024 [Page 12]
Internet-Draft Sustainability Insights May 2024
5. Proposals for a Solution
5.1. Basic Principles
5.1.1. Describe the Collected Data using YANG
There are many data/info modeling languages out there, but we are not
aware of any that comes close to YANG in its ability to concretely
and extensibly describe data structures and with a tools eco system
to render functionality from that.
5.1.2. Work with Existing Equipment
Network devices as well as servers and cooling systems are providing
metrics in various formats today. We could standardize how they
should report their information, and require them to follow certain
principles for accounting. We could then watch as these new systems
spread across the industry. Optimistically, this would take a few
years to standardize and another few to be implemented in devices.
Then yet another few years before it is widely deployed in production
networks. These are years that must not be lost in our efforts to
achieve reasonably sustainable networks. Therefore, we propose that
focusing on retrieving the data we need from the systems out there,
without inventing new reporting APIs/mechanisms on the equipment
level. The interfaces on existing devices are sometimes YANG-based
(e.g. YANG-push), but most are probably not (e.g. CLI scraping,
SNMP, homegrown REST, …)
5.1.3. New Systems that want to be Helpful
While we can’t expect all systems out there to adopt any new APIs or
reporting mechanisms, some system implementors may be interested to
help out as much as possible. In such cases, we think the best thing
a system implementor can do is to provide a catalog of the existing
sensors/measurement points the system provides, along with all the
metadata that the higher layers will need. We can standardize what
such an (optional) catalog would look like. This will make it easier
to integrate with the rest of the metrics collection system.
Implementing it may give a system a competitive advantage over
systems that don’t.
5.1.4. Time Series Database (TSDB) Storage
The already established industry norm seems to be storing any
collected and aggregated telemetry data in a Time Series Database
(TSDB).
Andersson, et al. Expires 8 November 2024 [Page 13]
Internet-Draft Sustainability Insights May 2024
5.1.5. Define Telemetry Component Roles: Providers, Collectors,
Aggregators, Processors
We need to agree on some terms. We have used the term “provider” to
mean any system that is reporting (sustainability) telemetry. This
could be a router, blade server or a building’s cooling system.
The telemetry data flow is initiated by a “collector”. The aim of
the collector is to ensure that data from a provider ends up in a
time series database, along with relevant metadata. How it
accomplishes this is outside the scope our efforts (could use e.g.
polling, subscriptions, YANG-push, …).
“Aggregators” and “processors” take telemetry data flow(s) from a
time series database and apply some sort transformation/aggregation
operation on them, and deliver the result to a time series database.
That could very well be a different partition/table/bucket in the
same time series database.
5.1.6. Add YANG and Metadata where missing, and keep the Metadata with
the Data
There are of course plenty of systems and telemetry data flows that
has no YANG description, but that can be solved. We, who are
building the telemetry stack, can add YANG descriptions to any data
flow we care about, if the system implementor doesn’t. Similarly,
aggregators and processors describe their outgoing data flows using
YANG models.
Both the YANG descriptions of the data flows and the corresponding
metadata descriptions of the flows should be kept close to the data
it pertains to. Preferably in or linked to the same database.
5.1.7. Transparency: Solid YANG to Time Series Database (TSDB) Mapping
Since all the data stored in the TSDB has a YANG description, we can
define an algorithm that maps any YANG defined data to the flat,
tagged, naming structure suitable for use in a TSDB. This makes it
easy to trace the origins of all the data in the TSDB. It is key to
be able to answer questions about the origins of the collected data
without looking into code. All the sources, and which processing
steps are applied, should be visible and editable as configuration
data, not deeply hidden in code created elsewhere.
Andersson, et al. Expires 8 November 2024 [Page 14]
Internet-Draft Sustainability Insights May 2024
5.2. The Sustainability Framework
To drive quick adoption, we propose to build an open-source
aggregation framework for sustainability data. This framework should
be seen as a reference architecture for a sustainability monitoring
mechanism. The reference implementation will be based on the
specifications mentioned in this document. The architecture would
supply a few base components, but otherwise, allow vendors or
standards bodies to plugin their applications that fit in the general
framework.
One example of such an application that we would like to propose is a
model to calculate the Total Sustainability Cost of Ownership (TSCO)
for network solutions based on the Environmental, Social, and
Governance (ESG) Materiality Matrix. This matrix model is open to
adding any implementation that takes into consideration
Sustainability objectives at a point in time, but it also evolves
with the needs of the business and the stakeholders. The initial
scope proposes to investigate the top four most important ESG
Materiality issues as a base to grow the TCO to a TSCO that matches
the Company’s priorities and issues.
5.3. The Framework Architecture
Even though the end-goal with the architecture is to enable fully
automated network management which is taking the sustainability
insights that comes out of the network into account, we envision the
top layer of the architecture would also contain a human consumable
graphs showing how well our network is operating with respect to
energy and emissions. We live in a demo-or-die world, after all.
Such graphs typically take their input from one or more Time-Series
Databases (TSDB). The mapping from YANG to TSDB is described in
[I-D.draft-kll-yang-label-tsdb-00]. The graphing technology already
exists, and many mature commercial and open source tools are
available. This operator user interface would also do well to have a
section for recommendations from the system, based on potential
savings the system has discovered.
An aggregation framework that collects information about, and to a
large extent directly from, the network elements and subsystems in
the network, and delivers it into a TSDB. Sometimes, the best
available data about some of the properties of some nework elements
is found in the datasheets for the network element. In such cases,
the information about a network element may be read from a web server
or file with structured information about the network element, rather
than reading it in (near) real-time from the system itself. We
propose that the aggregation system is built on the framework
described in the [I-D.draft-lindblad-tlm-philatelist-01].
Andersson, et al. Expires 8 November 2024 [Page 15]
Internet-Draft Sustainability Insights May 2024
In the figure below, many lines are drawn between components in the
aggregation framework. In general, those lines represent telemetry
data flows in and out of one or more TSDB buckets/topics. This state
of affairs is depicted in the diagram with a TSDB symbol “hanging in
the air” next to these lines.
Besides aggregating the collected telemetry data, the Philatelist
framework can also be used to associate selected points in the
collection tree with specific assets defined in the network
inventory, as defined in [I-D.draft-palmero-ivy-dmalmo-01].
Lower down in the stack, the aggregation framework needs to access
the actual devices, or other data sources standing in for them. The
variety in types of sensors and collection protocols to use here is
great. It is hard to know what sensors are available from a device,
and using which protocols. It is even harder to know more about what
the delivered metrics mean. What unit of measuremnt is used? Is the
power reported true RMS power, or something else? What is included
and not in this number, e.g. is the cooling cost included? What is
the precision? This metadata information SHOULD come from the device
vendor, either declared directly by the device itself, or by
providing a structured data manifest. The YANG interface and file
format for the manifest is described in [I-D.draft-opsawg-poweff-01].
A concrete device YANG model that provides some functionality for
reading power telemetry as well as some power control functionality
on the device level is found in [I-D.draft-li-ivy-power-01].
Andersson, et al. Expires 8 November 2024 [Page 16]
Internet-Draft Sustainability Insights May 2024
+-----------------+
| USER INTERFACE | ________
| Graphs | / \
| | ( TSDB )
+-----------------+ |\________/|
| | |
... \________/
|
+---------------+-------+-------+--------------+
| | | |
+------------+ +------------+ +------------+ +------------+
| PROCESSOR | | AGGREGATOR | | AGGREGATOR | | AGGREGATOR |
| Normalizer | | Network | | Storage | | Compute |
+------------+ +------------+ +------------+ +------------+
| | |\ |\
... ... ... ...
| | | |
|- YANG |-YANG |-YANG |-YANG
|- Metadata |-Metadata |-Metadata |-Metadata
| | | |
+------------+ +------------+ +------------+ +------------+
| COLLECTOR | | COLLECTOR | | COLLECTOR | | COLLECTOR |
+------------+ +------------+ +------------+ +------------+
| | |\ |\
... ... ... ...
| | | |
+- YANG | +- some YANG +- YANG
+- Metadata +- Metadata +- Metadata +- Metadata
| | | |
+----------+ +-----------+ +--------------+ +----------------+
| NETCONF | | CLI | | Device | | Device with |
| device | | and SNMP | | with REDFISH | | POWEFF models |
| | | device | | and RESTCONF | | over NETCONF |
+----------+ +-----------+ +--------------+ +----------------+
Figure 1: Example component diagram sketch of a Sustainability
Insights deployment.
6. 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.
Andersson, et al. Expires 8 November 2024 [Page 17]
Internet-Draft Sustainability Insights May 2024
6.1. Reaching Methodological Agreement
6.1.1. Need to Agree on What and How to Measure
Once we agree on the principles of how a collection framework should
be structured, we also need to agree on what data is meaningful to
measure from the systems, and how that measurement is done. What
units to convert to, what sample frequencies and how (im)precision is
conveyed. What about missing data points?
6.1.2. Need to Agree on What and How to Aggregate
Once we agree on what and how to measure, we also need to agree on
how we aggregate the data. Is linear interpolation of time series
data a good approach? Should we work with averages, and if so over
which time spans? Filter out outliers? How deep into the device
subsystems/interfaces etc should we drill? How should we add cost of
cooling, buildings, operations teams, etc?
6.1.3. Let’s bring in the Economists from SBTi, GHGP, etc.
On the e-impact mailing list, we have identified a number of hairy
questions when it comes to attribution/allocation of energy or co2eq-
cost, that are more of policy nature than hard science. E.g. who is
“responsible” for the idle power consumption of a system? Does it
matter if users pay a flat monthly fee for services, or per byte or
per cat video? All the above is about computing a cost-metric for
running the system. It may be equally important to compute a value
metric (e.g. based on what users pay for the service) to put in
relation to the cost. Just cost alone will be pretty much a useless
number.
To sort out questions on this level, it may be wise to involve “the
economists”. By that we mean the folks that are already assessing
many of our organizations when it comes to co2-reduction targets etc.
Folks from Science Based Targets initiative (SBTi), or Green House
Gas Protocol (GHGP), for example. They are used to construct
economic models where the right incentives show up.
6.2. Expanding the Scope
Items that are not in the scope of this edition of this document, but
could be addressed in future revisions, include:
* How to relate Sustainability Telemetry Specification to
sustainability Scopes 1, 2, and 3,
* Circular Economy Business models,
Andersson, et al. Expires 8 November 2024 [Page 18]
Internet-Draft Sustainability Insights May 2024
* Recommendations,
* Scope 4, i.e. metrics for avoided footprints (sometimes called
handprint). For instance, to reduce GHG emissions, automation
activities like Zero Touch, or certain technologies like Routed
Optical Networking, can replace other higher emitting activities.
Another example would be the positive impact arising from video
conferencing as opposed to international travel by airplane.
7. 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.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References
Andersson, et al. Expires 8 November 2024 [Page 19]
Internet-Draft Sustainability Insights May 2024
[I-D.draft-kll-yang-label-tsdb-00]
Larsson, K., "Mapping YANG Data to Label-Set Time Series",
Work in Progress, Internet-Draft, draft-kll-yang-label-
tsdb-00, 18 October 2023,
<https://datatracker.ietf.org/doc/html/draft-kll-yang-
label-tsdb-00>.
[I-D.draft-li-ivy-power-01]
Li, T. and R. Bonica, "A YANG model for Power Management",
Work in Progress, Internet-Draft, draft-li-ivy-power-01,
17 October 2023, <https://datatracker.ietf.org/doc/html/
draft-li-ivy-power-01>.
[I-D.draft-lindblad-tlm-philatelist-01]
Lindblad, J., "Philatelist, YANG-based Network Controller
collection and aggregation framework integrating Telemetry
data and Time Series Databases", Work in Progress,
Internet-Draft, draft-lindblad-tlm-philatelist-01, 7 May
2024, <https://datatracker.ietf.org/api/v1/doc/document/
draft-lindblad-tlm-philatelist/>.
[I-D.draft-opsawg-poweff-01]
Lindblad, J., Mitrovic, S., Palmero, M., and G. Salgueiro,
"Power and Energy Efficiency", Work in Progress, Internet-
Draft, draft-opsawg-poweff-01, 7 May 2024,
<https://datatracker.ietf.org/api/v1/doc/document/draft-
opsawg-poweff/>.
[I-D.draft-palmero-ivy-dmalmo-01]
Palmero, M., Brockners, F., Kumar, S., Cardona, C., and D.
Lopez, "Data Model for Asset Lifecycle Management and
Operations", Work in Progress, Internet-Draft, draft-
palmero-ivy-dmalmo-01, 24 April 2024,
<https://datatracker.ietf.org/doc/html/draft-palmero-ivy-
dmalmo-01>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
Change log
RFC Editor Note: This section is to be removed during the final
publication of the document.
* From version -02 to -03
- Rewrote the abstract
Andersson, et al. Expires 8 November 2024 [Page 20]
Internet-Draft Sustainability Insights May 2024
- Added a solution principles section
- Rewrote the architecture framework section to take a more
holistic view
- Removed the deployment considerations section
- Added methodological agreement section under next steps
- Many minor word changes and language fixes
- Updated list of normative references
* From version -01 to -02
- Includes explanation and new diagram for the architecture
framework
- Added Use Case VI
* From version -00 to -01
- Added an architecture framework section.
* Version -00
- Initial version.
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
Per Andersson
Cisco Systems
Email: perander@cisco.com
Jan Lindblad
Cisco Systems
Email: jlindbla@cisco.com
Andersson, et al. Expires 8 November 2024 [Page 21]
Internet-Draft Sustainability Insights May 2024
Snezana Mitrovic
Cisco Systems
Email: snmitrov@cisco.com
Marisol Palmero
Cisco Systems
Email: mpalmero@cisco.com
Esther Roure
Cisco Systems
Email: erourevi@cisco.com
Gonzalo Salgueiro
Cisco Systems
Email: gsalguei@cisco.com
Emile Stephan
Orange
Email: emile.stephan@orange.com
Andersson, et al. Expires 8 November 2024 [Page 22]