OPSA Working Group J. Lindblad Internet-Draft S. Mitrovic Intended status: Standards Track M. Palmero Expires: 8 November 2024 G. Salgueiro Cisco Systems 7 May 2024 Power and Energy Efficiency draft-opsawg-poweff-01 Abstract This document specifies a device YANG “dashboard” data model that allows devices to report which power measurement and control functions they offer. This basic YANG model is applicable to any kind of device, regardless of whether the device itself has any support for YANG-based management interfaces or not. The YANG model simply allows a device to describe what it can report, and which interfaces are available to request this data. Devices that lack any on-board YANG-based management interfaces provide this information in form of a YANG instance data file. This file may be readable from an on-board web server on the device, or hosted anywhere else. 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 November 2024. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Lindblad, et al. Expires 8 November 2024 [Page 1] Internet-Draft POWEFF May 2024 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. Requirements language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Proposed Solution Outline . . . . . . . . . . . . . . . . 5 3.2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Information Model . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Level 0, Proprietary Dashboard Only . . . . . . . . . . . 7 4.2. Level 1, Current Total Power Draw . . . . . . . . . . . . 7 4.3. Level 2, Add Energy and Susbsystem Breakdown . . . . . . 8 4.4. Level 3, Add Fundamental Power Control . . . . . . . . . 8 4.5. Level 4, Add Service Attribution . . . . . . . . . . . . 10 4.6. Level 5, Add Service Level Power Control . . . . . . . . 12 5. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Module ietf-poweff-types.yang . . . . . . . . . . . . . . 12 5.2. Module ietf-poweff-level-1.yang . . . . . . . . . . . . . 21 5.3. Module ietf-poweff-level-2.yang . . . . . . . . . . . . . 23 5.4. Module ietf-poweff-level-3.yang . . . . . . . . . . . . . 26 5.5. Module ietf-poweff-level-4.yang . . . . . . . . . . . . . 30 5.6. Module ietf-poweff-level-5.yang . . . . . . . . . . . . . 33 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 37 7. Security Considerations . . . . . . . . . . . . . . . . . . . 37 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 38 8.2. The YANG Module Names Registry . . . . . . . . . . . . . 38 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 9.1. Normative References . . . . . . . . . . . . . . . . . . 38 9.2. Informative References . . . . . . . . . . . . . . . . . 38 Change log . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Lindblad, et al. Expires 8 November 2024 [Page 2] Internet-Draft POWEFF May 2024 1. Introduction As highlighted during the IAB workshop on environmental impacts (https://datatracker.ietf.org/doc/html/draft-iab-ws-environmental- impacts-report-00), visibility is a very important first step. Paraphrasing Peter Drucker’s mantra of “You cannot improve what you don’t measure”. During the workshop the need for standardized metrics was established, to avoid proprietary, redundant and even contradictory metrics across vendors. POWEFF is considered a first step, part of the Sustainability Telemetry Specification referred as part of the Sustainability Insights [I-D.draft-almprs-sustainability-insights-02] IETF draft (a newer version may exist). That is where the overall problem statement, solution principles and other components of the proposed solution can be found. Specifically, this work is meant to fit in with the [I-D.draft-lindblad-tlm-philatelist-01] framework. This Power Consumption and Energy Efficiency Telemetry Specification (POWEFF) provides a way for a controller to understand what a device offers in terms of power related sensors and controls. It also provides machine readable metadata for the sensors, such as which units of measurement are used, what is included in the reported data, the precision of the data, etc. This is referred to as the device dashboard. This document also contains embryonic definitions of recommended datasets and attributes defining a common data model to report Power Consumption and Energy Efficiency on assets, with multuple implementation levels, that new devices may choose to implement. Standardized calculations utilizing the specified datasets and attributes which will yield a power consumption value for any asset or network element, and standardized calculations utilizing the specified datasets and attributes which will yield the energy efficiency value for any asset or network element. 1.1. 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: Lindblad, et al. Expires 8 November 2024 [Page 3] Internet-Draft POWEFF May 2024 Asset Refers to hardware, software, applications, or services. An asset can be physical or virtual, as defined in the Asset Lifecycle Management and Operations [I-D.draft-palmero-ivy-ps-almo-01] IETF draft. Scope 1 Emissions directly caused by actions of the organization, such as when fossil fuels are burned when the organization is operating a fossil vehicle. See Greenhouse Gas protocol (https://ghgprotocol.org/). Scope 2 Emissions indirectly caused by actions of the organization, but under control of the organization. For example, when electric energy is purchased, causing a provider utility to make emissions on behalf of the organization. See Greenhouse Gas protocol (https://ghgprotocol.org/). Scope 3 Emissions the organization indirectly causes others to make, but outside the organizations direct control. Examples include the energy customers consume when operating the organization’s products, or when employees commute to work at the organization. See Greenhouse Gas protocol (https://ghgprotocol.org/). Scope 4 Refers to the term used in Greenhouse Gas (GHG) accounting and reporting to describe emissions that occur as a result of an organization’s value chain activities, but are not directly controlled or owned by the organization. Scope 4 emissions are considered indirect emissions and are typically associated with activities that are upstream or downstream from a organization’s operations. Such as when equipment provided by the organization enables a video conference, without which greater emissions from business travel would have happened. CO2eq Carbon dioxide equivalents, a measure of the disruptive force of greenhouse gas emissions. Power Refers to the (e.g. electrical or optical) energy per unit of time, supplied to operate an asset, such as a smartphone. It is usually measured in units of Watts. Energy Efficiency refers to the ability of an asset to perform its intended functions while minimizing energy consumption. It refers to the ratio between the useful output energy and input energy given by an asset. In a router or a switch, it is a measure of how efficiently the network element utilizes energy resources to transmit and process data or perform other network-related tasks. See Energy efficiency wikipedia (https://en.wikipedia.org/wiki/ Energy_efficiency). Lindblad, et al. Expires 8 November 2024 [Page 4] Internet-Draft POWEFF May 2024 3. Motivation The main objective of POWEFF is to enable Network Controllers to measure, report and control power and energy related metrics from networks with many and diverse devices, providing the necessary insights to improve the overall CO2eq emission for use cases of which the asset is part. Basically emissions that address direct use-phase emissions of Scope 3, Category 11 “use of sold products”. It includes emissions from the use of goods and services sold by the reporting company or vendor in the reporting year. A vendor’s Scope 3 emissions from use of sold products include the scope 1 and scope 2 emissions of end users. End users include both consumers and business customers that use final assets. It is important to note that Scope 3 category 11, reports around 75% of the total Scopes 1, 2 and 3 reported by a given asset. See Cisco ESG Reporting Hub (https://www.cisco.com/c/m/en_us/about/csr/esg-hub/environment/ goals.html#scope-1-3-emissions). Power and energy consumption Telemetry data available for different infrastructure vendors today is characterized by inconsistency and best effort: * Availability of primary data. Data is often only available on a case by case basis * Varying APIs. Where Telemetry might be available, access methods, data contents and formats are specific to platforms or elements * Limitations. Some useful or essential data items are never collected by the relevant hardware or software * Precision. Data often contains significant margins of error, both from random noise and systematic errors * Varying definitions. Calculated values use differing inputs and algorithms, limiting the value of any possible comparison and aggregation * Opacity. Lack of transparency of how and what is being measured makes it very hard to ascertain fair comparisions. 3.1. Proposed Solution Outline Formulate a Power and Energy Efficiency Telemetry Specification to promote consistency: Data Definition of datasets and attributes that will define a common Lindblad, et al. Expires 8 November 2024 [Page 5] Internet-Draft POWEFF May 2024 data model to report power and energy consumption on hardware and software assets Calculation Define a standardized calculation utilizing the specified datasets and attributes which will yield an energy consumption value for any asset. Implementing any Sustainability Solution at scale for customers with a broad range of equipment requires at minimum consistently available Power Consumption/Energy Efficiency Telemetry. Telemetry standardization will benefit numerous stakeholders, including Corporate Social Responsibility (CSR), who have a need for Power Consumption Telemetry data for a variety of purposes. 3.2. Use Cases * Monitoring power and energy efficiency based on common metrics. * Enhance reporting and provide a comprehensive overview for potentially improving power usage during the operational phase. * Consumption per device, e.g. wireless environment. * Capabilities to optimize energy consumption when assets are not in use, e.g. idle and allocated power. * Hardware Lifecycle. Circular economy enables to restore product value at the end of life, there are several options, reuse, remanufacturing, recycling, repurpose, etc. More elaborate use cases, e.g. define carbon footprint for network’s usage, might also be derived from POWEFF model, even discussion and common understanding will be required. 4. Information Model Implementors of this specification can choose the implementation level that is appropriate for their device at the current time. As the implementation matures, higher implementation levels may be chosen over time. Each implementation level is a superset of the previous level. Lindblad, et al. Expires 8 November 2024 [Page 6] Internet-Draft POWEFF May 2024 4.1. Level 0, Proprietary Dashboard Only At level 0, the device implements only proprietary dashboards, without implmementing any dashboards with predefined content. This allows controllers to find the power sensors already present in the implementation, and read the associated metadata, but may not be well prepared to really understand the meaning of the data being read. The dashboard may be provided by an on-board YANG-based management protocol, or delivered as a YANG instance data file from an on-board webserver, or delievered as a file by some other mechanism (e.g. web server elsewhere). For level 0, the Network Element implements the Philatelist YANG module ietf-tlm-philatelist-provider. This gives the controller one or more proprietary dashboard with whatever contents the implementor sees fit. 4.2. Level 1, Current Total Power Draw At level 1, the device implements a very small, but well defined dashboard, and lists it using the Philatelist ietf-tlm-philatelist- provider module. The level 1 dashboard consists of a single dashboard item. This dashboard item provides a way for the Network Controller to read the current total power draw of the Network Element. module: ietf-poweff-level-1 +--rw poweff +--ro stats +--ro device-current-total-power-draw? uint32 Figure 1: YANG tree diagram of the Level 1 Dashboard. The following requirements MUST be fulfilled by the Network Element implementing the level 1 and higher dashboards. + The reported telemetry data MUST be correct with regards to what is included and not included for all reported telemetry data values + The metadata MUST be correct with regards to measurement units for all reported telemetry data values + The metadata MUST be correct with regards to apparent/real RMS power, for all reported power and energy data values + The power consumption values reported MUST NOT be underestimated over time in actual field use Lindblad, et al. Expires 8 November 2024 [Page 7] Internet-Draft POWEFF May 2024 If Network Elements declaring conformance to the level 1, or higher, dashboard of this specification, do not actually fulfill the conditions required in this document, that may be construed as violating the EU Green Claims Directive (GCD), EU 2023/0085(COD) (https://oeil.secure.europarl.europa.eu/oeil/popups/ ficheprocedure.do?lang=en&reference=2023/0085(COD)) 4.3. Level 2, Add Energy and Susbsystem Breakdown At level 2, on top of all level 1 reporting, the Network Element also reports the gross energy usage over time (the integral over time of the power draw), and the power draw can be further inspected for each major subsystem within the device. module: ietf-poweff-level-2 augment /ietf-poweff-level-1:poweff/ietf-poweff-level-1:stats: +--ro device-total-energy-spent? uint32 +--ro device-total-energy-spent-since? yang:date-and-time +--ro subsystem* [name] +--ro name subsys-name-t +--ro current-power-draw? uint32 +--ro children* -> ../../subsystem/name Figure 2: YANG tree diagram of the Level 2 Dashboard. 4.4. Level 3, Add Fundamental Power Control From this level onward, a YANG-based management protocol is required, since standards based configuration control of the device is required. At level 3, all the reporting functions of level 2 are required, and also basic control over device global power-save modes. The controller may choose one of several power saving modes for the Network Element. Network Element implementors or Standards Defining Organizations (SDOs) may also augment the mode selection with additional power saving modes. The basic principle for the power saving controls is for the Network Controller to specify how much degradation of the maximum possible delivered performace it could tolerate, and for the Network Element to decide on what power saving measures that can be taken, while still fulfilling expectations. The Network Element SHOULD also provide an estimate of how much power can be saved under the given conditions. Lindblad, et al. Expires 8 November 2024 [Page 8] Internet-Draft POWEFF May 2024 This document specifies four power save modes and two power-save conditions that apply generally to the power save modes. fully-powered The subsystem is fully powered, i.e. does not take any power-saving measures that would risk lowering the performance below normal levels. powered-off The subsystem is completely powered off, i.e. it is drawing no or little power while also delivering zero performance. napping The subsystem is napping, i.e. is taking frequent but brief pauses in the service it provides. The Network Controller may specify a max-additional-latency. This determines the maximum tolerated length of the pauses with reduced performance. This means the maximum additional delay that this subsystem would incur on e.g. detecting incoming traffic or performing its function. throttling The subsystem is throttling, i.e. is running with reduced capacity in the service it provides. The Network Controller may specify a max-capacity-reduction. This determines the maximum tolerated reduction of performance. For example, if a Network Controller applied throttling with a max- capacity-reduction value at 50% onto a transport subsystem or service that consists of 3 underlaying links of equal capacity, the Network Element might decide to shut down one of the three links. For all the power-save modes (except the fully-powered mode, in which these have no effect) the two following general conditions also apply: max-time-to-cancel-power-save The maximum time the Controller allows the subsystem to recover full performance. The subsystem should not engage in power-saving measures that take longer than this time to revert to full performance. estimated-power-reduction The subsystem’s own estimate on how much of its own power draw that is reduced by the power-saving measures in effect. For example, if a Network Controller applied throttling with a max- capacity-reduction value at 50% onto a transport subsystem or service that consists of 3 underlaying links of equal capacity, the Network Element might decide to shut down one of the three links. The Network Element might then report an estimated-power-reduction of 33%. Lindblad, et al. Expires 8 November 2024 [Page 9] Internet-Draft POWEFF May 2024 module: ietf-poweff-level-3 augment /ietf-poweff-level-1:poweff: +--rw power-save +--rw subsystem* [name] +--rw name -> /poweff/stats/subsystem/name +--rw (selected-power-save-mode)? | +--:(fully-powered) | | +--rw fully-powered? empty | +--:(powered-off) | | +--rw powered-off? empty | +--:(napping) | | +--rw napping | | +--rw max-additional-latency? microseconds | +--:(throttling) | +--rw throttling | +--rw max-capacity-reduction? percent +--rw max-time-to-cancel-power-save? microseconds +--ro estimated-power-reduction? uint32 Figure 3: YANG tree diagram of the Level 3 Dashboard. 4.5. Level 4, Add Service Attribution At level 4, the Network Element also provides a list of services/tenants/clients/domains/functions that it delivers value towards, and attributes the Network Element’s power draw to each of the services. The list of services may include one “overhead/idle/other/unknown” entry that absorbs any overhead not attributable to a particular service. The power draw MAY be further subdivided for each service by using a dot notation. One service instance called ‘-idle-‘ may be present in the list and absorb any overhead/idle/other/unknown kind of power draw that the system would not allocate to any service. It is up to the implementor to decide what a ‘service’ means for this type of system. It may be any kind of service that it delivers user value towards. For example, if a system serves three customers, X, Y and Z, their power draw could be declared as follows: Lindblad, et al. Expires 8 November 2024 [Page 10] Internet-Draft POWEFF May 2024 +===============+====================+=========================+ | name | current-power-draw | children | +===============+====================+=========================+ | X | 45 | vpn | +---------------+--------------------+-------------------------+ | X.vpn | 39 | eth1/16 eth2/33 eth3/11 | +---------------+--------------------+-------------------------+ | X.vpn.eth1/16 | 14 | | +---------------+--------------------+-------------------------+ | X.vpn.eth2/33 | 12 | | +---------------+--------------------+-------------------------+ | X.vpn.eth3/11 | 9 | | +---------------+--------------------+-------------------------+ | Y | 26 | | +---------------+--------------------+-------------------------+ | Z | 19 | | +---------------+--------------------+-------------------------+ | -idle- | 48 | | +---------------+--------------------+-------------------------+ Table 1 The sum of the current-power-draw top level entries (in this example: X, Y, Z and -idle-, with values 45 + 26 + 19 + 48 = 138) must match the value provided in ietf-poweff-level-1:device-current-total-power- draw The sub-service values (e.g. X.vpn, 39W) need to be lower than or equal to (but do not necessarily need to match) their parent level (e.g. X, 45W). Note: the name of the children have been abbreviated in the diagram above. In the actual payload, the full names would always be used, e.g. ‘eth1/16’ above would actually be communicated as ‘X.vpn.eth1/16’. module: ietf-poweff-level-4 augment /ietf-poweff-level-1:poweff/ietf-poweff-level-1:stats: +--ro service* [name] +--ro name string +--ro current-power-draw? uint32 +--ro children* -> ../../service/name Figure 4: YANG tree diagram of the Level 4 Dashboard. Lindblad, et al. Expires 8 November 2024 [Page 11] Internet-Draft POWEFF May 2024 4.6. Level 5, Add Service Level Power Control At level 5, the device additionally implements power-save modes per delivered service. The structure is exactly the same as the level 3 structure, except that it is for services rather than subsystems. A service would be something that is relevant and meaningful from a customer’s or user’s perspective. It is up to the Network Element implementor to decide exactly what constitutes a service. module: ietf-poweff-level-5 augment /ietf-poweff-level-1:poweff/ietf-poweff-level-3:power-save: +--rw service* [name] +--rw name -> /poweff/stats/service/name +--rw (selected-power-save-mode)? | +--:(fully-powered) | | +--rw fully-powered? empty | +--:(powered-off) | | +--rw powered-off? empty | +--:(napping) | | +--rw napping | | +--rw max-additional-latency? microseconds | +--:(throttling) | +--rw throttling | +--rw max-capacity-reduction? percent +--rw max-time-to-cancel-power-save? microseconds +--ro estimated-power-reduction? uint32 Figure 5: YANG tree diagram of the Level 5 Dashboard. 5. YANG Modules 5.1. Module ietf-poweff-types.yang module ietf-poweff-types { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-types"; prefix ietf-poweff-types; import ietf-tlm-philatelist-types { prefix ietf-tlm-philatelist-types; } organization "IETF OPSA (Operations and Management Area) Working Group"; contact "WG Web: WG List: Lindblad, et al. Expires 8 November 2024 [Page 12] Internet-Draft POWEFF May 2024 Editor: Jan Lindblad Editor: Snezana Mitrovic Editor: Marisol Palmero "; description "This YANG module defines basic quantities, measurement units and sensor types for the POWEFF framework. 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 2024-04-16 { description "Restructured to use the Telemetry Philatelist framework"; reference "RFC XXXX: ..."; } typedef something { // FIXME: Used when we haven't decided the type yet type string; description "FIXME"; } typedef xpath { type string; // FIXME: Proper type needed description "FIXME"; } typedef sample-frequency { type string; // FIXME: Proper type needed description "FIXME"; } Lindblad, et al. Expires 8 November 2024 [Page 13] Internet-Draft POWEFF May 2024 // ========== SENSOR-QUANTITY ============================== identity sq-voltage { base ietf-tlm-philatelist-types:sensor-quantity; description "Sensor reports electric tension, voltage. "; } identity sq-current { base ietf-tlm-philatelist-types:sensor-quantity; description "Sensor reports electric current. "; } identity sq-power { base ietf-tlm-philatelist-types:sensor-quantity; description "Sensor reports power draw (energy per unit of time). "; } identity sq-power-apparent { base sq-power; description "Sensor reports apparent power, i.e. average electrical current times voltage (in VA). "; } identity sq-power-true { base sq-power; description "Sensor reports true power, i.e. integral over current and voltage at each instant in time. "; } identity sq-energy { base ietf-tlm-philatelist-types:sensor-quantity; description "Sensor reports actual energy drawn by asset. "; } identity sq-co2-emission { base ietf-tlm-philatelist-types:sensor-quantity; description "Sensor reports CO2 (carbon dioxide) emission by asset. "; } identity sq-co2eq-emission { base ietf-tlm-philatelist-types:sensor-quantity; description Lindblad, et al. Expires 8 November 2024 [Page 14] Internet-Draft POWEFF May 2024 "Sensor reports CO2 (carbon dioxide) equivalent emission by asset. "; } identity sq-temperature { base ietf-tlm-philatelist-types:sensor-quantity; description "Sensor reports temperature of asset. "; } identity sq-time { base ietf-tlm-philatelist-types:sensor-quantity; description "Sensor reports time duration. "; } // ========== SENSOR-UNIT ============================== identity su-volt { base ietf-tlm-philatelist-types:sensor-unit; base sq-voltage; description "Sensor unit volt, V. "; } identity su-ampere { base ietf-tlm-philatelist-types:sensor-unit; base sq-current; description "Sensor unit ampere, A. "; } identity su-watt { base ietf-tlm-philatelist-types:sensor-unit; base sq-power; description "Sensor unit watt, W. "; } identity su-voltampere { base ietf-tlm-philatelist-types:sensor-unit; base sq-power; description "Sensor unit Volt*Ampere, VA. "; } identity su-kw { base ietf-tlm-philatelist-types:sensor-unit; Lindblad, et al. Expires 8 November 2024 [Page 15] Internet-Draft POWEFF May 2024 base sq-power; description "Sensor unit kilowatt, kW. "; } identity su-joule { base ietf-tlm-philatelist-types:sensor-unit; base sq-energy; description "Sensor unit joule, J. "; } identity su-wh { base ietf-tlm-philatelist-types:sensor-unit; base sq-energy; description "Sensor unit watthour, Wh. "; } identity su-kwh { base ietf-tlm-philatelist-types:sensor-unit; base sq-energy; description "Sensor unit kliowatthour, kWh. "; } identity su-kelvin { base ietf-tlm-philatelist-types:sensor-unit; base sq-temperature; description "Sensor unit kelvin, K. "; } identity su-celsius { base ietf-tlm-philatelist-types:sensor-unit; base sq-temperature; description "Sensor unit celsius, C. "; } identity su-farenheit { base ietf-tlm-philatelist-types:sensor-unit; base sq-temperature; description "Sensor unit farenheit, F. "; } identity su-gram { Lindblad, et al. Expires 8 November 2024 [Page 16] Internet-Draft POWEFF May 2024 base ietf-tlm-philatelist-types:sensor-unit; base sq-co2-emission; description "Sensor unit gram, g. "; } identity su-kg { base ietf-tlm-philatelist-types:sensor-unit; base sq-co2-emission; description "Sensor unit kliogram, kg. "; } identity su-ton { base ietf-tlm-philatelist-types:sensor-unit; base sq-co2-emission; description "Sensor unit ton, t. "; } identity su-second { base ietf-tlm-philatelist-types:sensor-unit; base sq-time; description "Sensor unit second, s. "; } identity su-millisecond { base ietf-tlm-philatelist-types:sensor-unit; base sq-time; description "Sensor unit millisecond, ms. "; } identity su-microsecond { base ietf-tlm-philatelist-types:sensor-unit; base sq-time; description "Sensor unit microsecond, us. "; } // ========== SENSOR-TYPE ============================== extension sensor-type { argument identity-name; description "YANG Extension used to declare which sensor type (as in input/output, quantity and unit) it has in a Lindblad, et al. Expires 8 November 2024 [Page 17] Internet-Draft POWEFF May 2024 standardized machine readable way. See ietf-tlm-philatelist-types:sensor-type. "; } identity st-v-in { base ietf-tlm-philatelist-types:sensor-type; base ietf-tlm-philatelist-types:sc-input; base sq-voltage; base su-volt; description "Sensor reporting Voltage In to asset. "; } identity st-v-out { base ietf-tlm-philatelist-types:sensor-type; base ietf-tlm-philatelist-types:sc-output; base sq-voltage; base su-volt; description "Sensor reporting Voltage Out of asset. "; } identity st-i-in { base ietf-tlm-philatelist-types:sensor-type; base ietf-tlm-philatelist-types:sc-input; base sq-current; base su-ampere; description "Sensor reporting Current In to asset. "; } identity st-i-out { base ietf-tlm-philatelist-types:sensor-type; base ietf-tlm-philatelist-types:sc-output; base sq-current; base su-ampere; description "Sensor reporting Current Out of asset. "; } identity st-p-in-apparent-watt { base ietf-tlm-philatelist-types:sensor-type; base ietf-tlm-philatelist-types:sc-input; base sq-power-apparent; base su-voltampere; description "Sensor reporting Power In to asset as apparent (I*U) power. Lindblad, et al. Expires 8 November 2024 [Page 18] Internet-Draft POWEFF May 2024 "; } identity st-p-out-apparent-watt { base ietf-tlm-philatelist-types:sensor-type; base ietf-tlm-philatelist-types:sc-output; base sq-power-apparent; base su-voltampere; description "Sensor reporting Power Out of asset as apparent (I*U) power. "; } identity st-p-in-true-watt { base ietf-tlm-philatelist-types:sensor-type; base ietf-tlm-philatelist-types:sc-input; base sq-power-true; base su-watt; description "Sensor reporting Power In to asset as true power. "; } identity st-p-out-true-watt { base ietf-tlm-philatelist-types:sensor-type; base ietf-tlm-philatelist-types:sc-output; base sq-power-true; base su-watt; description "Sensor reporting Power Out of asset as true power. "; } identity st-p-allocated-watt { base ietf-tlm-philatelist-types:sensor-type; base ietf-tlm-philatelist-types:sc-allocated; base sq-power; base su-watt; description "Sensor reporting Allocated Power for asset. "; } identity st-w-j { base ietf-tlm-philatelist-types:sensor-type; base sq-energy; base su-joule; description "Sensor reporting energy draw of asset in J. "; } identity st-w-wh { Lindblad, et al. Expires 8 November 2024 [Page 19] Internet-Draft POWEFF May 2024 base ietf-tlm-philatelist-types:sensor-type; base sq-energy; base su-wh; description "Sensor reporting energy draw of asset in Wh. "; } identity st-w-kwh { base ietf-tlm-philatelist-types:sensor-type; base sq-energy; base su-kwh; description "Sensor reporting energy draw of asset in kWh. "; } identity st-t-k { base ietf-tlm-philatelist-types:sensor-type; base sq-temperature; base su-kelvin; description "Sensor reporting Temperature of asset in K. "; } identity st-t-c { base ietf-tlm-philatelist-types:sensor-type; base sq-temperature; base su-celsius; description "Sensor reporting Temperature of asset in °C. "; } identity st-t-f { base ietf-tlm-philatelist-types:sensor-type; base sq-temperature; base su-farenheit; description "Sensor reporting Temperature of asset in °F. "; } // ========== TSDB-PATH ====================================== extension tsdb-path { argument tsdb-path; description "YANG Extension for declaring the TSDB path that a given YANG leaf would have. "; } Lindblad, et al. Expires 8 November 2024 [Page 20] Internet-Draft POWEFF May 2024 // ========== COLLECTION-METHOD ============================== // None defined here // ========== POWER-SAVE UNITS =============================== typedef microseconds { type uint32; units us; description "Time unit, millionths of a second. 10^-6 seconds. "; } typedef percent { type uint32 { range 0..100; } units %; description "Percent fraction, 1/100 of something. "; } } 5.2. Module ietf-poweff-level-1.yang module ietf-poweff-level-1 { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-level-1"; prefix ietf-poweff-level-1; import ietf-poweff-types { prefix ietf-poweff-types; } organization "IETF OPSA (Operations and Management Area) Working Group"; contact "WG Web: WG List: Editor: Jan Lindblad Editor: Snezana Mitrovic Editor: Marisol Palmero "; description "This YANG module defines the POWEFF Level 1. Copyright (c) 2024 IETF Trust and the persons identified as Lindblad, et al. Expires 8 November 2024 [Page 21] Internet-Draft POWEFF May 2024 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 Revised 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. 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 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. "; revision 2024-04-16 { description "Initial revision of POWEFF Level 1"; reference "RFC XXXX: ..."; } container poweff { description "Top level container for POWEFF. "; container stats { config false; description "Statistics (read-only) branch of POWEFF. "; leaf device-current-total-power-draw { type uint32; units W; ietf-poweff-types:sensor-type ietf-poweff-types:st-p-in-true-watt; ietf-poweff-types:tsdb-path poweff.stats.device_current_total_power_draw; description "The current power draw of the device that the management server pertains to, including power supplies. Does not include power draw of external cooling systems Lindblad, et al. Expires 8 November 2024 [Page 22] Internet-Draft POWEFF May 2024 that may be required to operate this system. The power draw MUST be reported in Watts, and MUST be the true RMS power. The reported value MUST NOT be lower than the actual power draw. Any violations of these conditions may be legally construed as greenwashing, as defined by EU Green Claims Directive (GCD), EU 2023/0085(COD). "; } } } } 5.3. Module ietf-poweff-level-2.yang module ietf-poweff-level-2 { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-level-2"; prefix ietf-poweff-level-2; import ietf-yang-types { prefix yang; } import ietf-poweff-types { prefix ietf-poweff-types; } import ietf-poweff-level-1 { prefix ietf-poweff-level-1; } organization "IETF OPSA (Operations and Management Area) Working Group"; contact "WG Web: WG List: Editor: Jan Lindblad Editor: Snezana Mitrovic Editor: Marisol Palmero "; description "This YANG module defines the POWEFF Level 2. Copyright (c) 2024 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or Lindblad, et al. Expires 8 November 2024 [Page 23] Internet-Draft POWEFF May 2024 without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised 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. 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 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. "; revision 2024-04-16 { description "Initial revision of POWEFF Level 2"; reference "RFC XXXX: ..."; } typedef subsys-name-t { type union { type enumeration { enum sys { description "The name of the top level object is 'sys'."; } } type string { pattern '[a-zA-Z]+[a-zA-Z0-9_/\.:-]*[a-zA-Z0-9_/]+'; } } description "Type for subsystem names. Must start with an ASCII alpabetic characters. The characters following may also be numeric characters, dash, underscore, forward slash. Parts of the name may be interpunctuated with a dot or colon. Interpunctuation must not be the last character in the name."; } augment /ietf-poweff-level-1:poweff/ietf-poweff-level-1:stats { description "Level 2 extends the Level 1 defintions with additional content. "; Lindblad, et al. Expires 8 November 2024 [Page 24] Internet-Draft POWEFF May 2024 leaf device-total-energy-spent { type uint32; units J; ietf-poweff-types:sensor-type ietf-poweff-types:st-w-j; ietf-poweff-types:tsdb-path poweff.stats.device_total_energy_spent; description "The total energy spent by the device since the point in time specified by ../device-total-energy-spent-since. This is the integral over time of the power draw as specified by ../ietf-poweff-level-1:device-current-total-power-draw. The energy used MUST be reported in Joule. The reported value MUST NOT be lower than the actual energy used. Any violations of these conditions may be legally construed as greenwashing, as defined by EU Green Claims Directive (GCD), EU 2023/0085(COD)."; } leaf device-total-energy-spent-since { type yang:date-and-time; description "The point in time at which the energy couting started. Typically at the most recent system initalization."; } list subsystem { key name; description "List of subsystems, in a tree structure, as defined by the system implementor. There MUST be an entry called 'sys', which MUST have a current-power-draw value equal to the ../ietf-poweff-level-1:device-current-total-power-draw value. "; leaf name { type subsys-name-t; description "The name of the subsystem. The name is built from the name of its ancestors joined with a dot (.). The root object of tree is called 'sys'. An example of a valid tree structure: - sys - sys.main-board - sys.main-board.cpu0 - sys.main-board.cpu1 - sys.linecard1 - sys.linecard1.eth0/1 - sys.psu0 Lindblad, et al. Expires 8 November 2024 [Page 25] Internet-Draft POWEFF May 2024 - sys.psu0.fan0 - sys.psu0.fan1 "; } leaf current-power-draw { type uint32; units W; ietf-poweff-types:sensor-type ietf-poweff-types:st-p-in-true-watt; ietf-poweff-types:tsdb-path poweff.stats.subsystem.current_power_draw; description "Current power draw of the subsystem in Watts. This value MUST be larger than or equal to the sum of the power draw of all children listed in ../children, if any."; } leaf-list children { type leafref { path ../../subsystem/name; } description "Children of this subsystem, each contributing to the power draw of this subsystem."; } } } } 5.4. Module ietf-poweff-level-3.yang module ietf-poweff-level-3 { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-level-3"; prefix ietf-poweff-level-3; import ietf-poweff-types { prefix ietf-poweff-types; } import ietf-poweff-level-1 { prefix ietf-poweff-level-1; } import ietf-poweff-level-2 { prefix ietf-poweff-level-2; } organization "IETF OPSA (Operations and Management Area) Working Group"; contact Lindblad, et al. Expires 8 November 2024 [Page 26] Internet-Draft POWEFF May 2024 "WG Web: WG List: Editor: Jan Lindblad Editor: Snezana Mitrovic Editor: Marisol Palmero "; description "This YANG module defines the POWEFF Level 3. Copyright (c) 2024 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 Revised 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. 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 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. "; revision 2024-04-16 { description "Initial revision of POWEFF Level 3"; reference "RFC XXXX: ..."; } augment /ietf-poweff-level-1:poweff { description "Level 3 extends the Level 1 & 2 defintions with additional content. "; container power-save { description "Container for power-save control functions that the Lindblad, et al. Expires 8 November 2024 [Page 27] Internet-Draft POWEFF May 2024 Network Controller may use to ask this Network Element to employ zero or more power-saving techniques. "; list subsystem { key name; description "List of subsystems that offer power-saving functions. "; leaf name { type leafref { path "/ietf-poweff-level-1:poweff/" + "ietf-poweff-level-1:stats/"+ "ietf-poweff-level-2:subsystem/"+ "ietf-poweff-level-2:name"; require-instance false; } description "Name of the subsystem that offers power-saving functionality. This name normally matches one of the names in the poweff/stats subsystem list, but it is possible that a subsystem is not listed there e.g. because it has not started yet, during the system initialization. "; } choice selected-power-save-mode { description "Choice of power saving modes that the Controller may select. Additional power-saving modes may be augmented into this choice by implementors, but may not be known/understood by the controller. "; leaf fully-powered { type empty; description "The subsystem is fully powered, i.e. does not take any power-saving measures that would risk lowering the performance below normal levels. "; } leaf powered-off { type empty; description "The subsystem is completely powered off, i.e. it is drawing no or little power while also delivering zero performance. "; Lindblad, et al. Expires 8 November 2024 [Page 28] Internet-Draft POWEFF May 2024 } container napping { description "The subsystem is napping, i.e. is taking frequent but brief pauses in the service it provides. "; leaf max-additional-latency { type ietf-poweff-types:microseconds; description "Determines the maximum tolerated length of the pauses with reduced performance. This means the maximum additional delay that this subsystem would incur on e.g. detecting incoming traffic or performing its function. "; } } container throttling { description "The subsystem is throttling, i.e. is running with reduced capacity in the service it provides. "; leaf max-capacity-reduction { type ietf-poweff-types:percent; description "Determines the maximum tolerated reduction of performance. If this setting is applied to a bundle interface, for example, that consists of 3 underlaying links of equal capacity, and the controller sets the max-capacity-reduction value to 50%, the bundle interface could shut down one of the links. "; } } } leaf max-time-to-cancel-power-save { type ietf-poweff-types:microseconds; description "The maximum time the Controller allows the subsystem to recover full performance. The subsystem should not engage in power-saving measures that take longer than this time to revert to full performance. "; } leaf estimated-power-reduction { type uint32; config false; description Lindblad, et al. Expires 8 November 2024 [Page 29] Internet-Draft POWEFF May 2024 "The subsystem's own estimate on how much of its own power draw that is reduced by the power-saving measures in effect. If the controller sets a bundle interface that consists of 3 underlaying links of equal capacity, for example, into 50% throttling mode, the subsystem might shut down one of the underlaying links and report an estimated-power-reduction of 33%. "; } } } } } 5.5. Module ietf-poweff-level-4.yang module ietf-poweff-level-4 { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-level-4"; prefix ietf-poweff-level-4; import ietf-poweff-types { prefix ietf-poweff-types; } import ietf-poweff-level-1 { prefix ietf-poweff-level-1; } organization "IETF OPSA (Operations and Management Area) Working Group"; contact "WG Web: WG List: Editor: Jan Lindblad Editor: Snezana Mitrovic Editor: Marisol Palmero "; description "This YANG module defines the POWEFF Level 4. Copyright (c) 2024 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 Lindblad, et al. Expires 8 November 2024 [Page 30] Internet-Draft POWEFF May 2024 the license terms contained in, the Revised 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. 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 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. "; revision 2024-04-16 { description "Initial revision of POWEFF Level 4"; reference "RFC XXXX: ..."; } augment /ietf-poweff-level-1:poweff/ietf-poweff-level-1:stats { description "Level 4 extends the Level 1, 2 & 3 defintions with power draw data broken down on services. "; list service { key name; description "List of services that the Network Element is aware of, and their current power draw. The power draw MAY be further subdivided for each service by using a dot notation. One service instance called '-idle-' may be present in the list and absorb any overhead/idle/other/unknown kind of power draw that the system would not allocate to any service. It is up to the implementor to decide what a 'service' means for this type of system. It may be any kind of service that it delivers user value towards. For example, if a system serves three customers, X, Y and Z, their power draw could be declared as follows: | name | current- | children | Lindblad, et al. Expires 8 November 2024 [Page 31] Internet-Draft POWEFF May 2024 | | power- | | | | draw | | |---------------|----------|-----------------------------| | X | 45 | [ vpn ] | | X.vpn | 39 | [ eth1/16 eth2/33 eth3/11 ] | | X.vpn.eth1/16 | 14 | | | X.vpn.eth2/33 | 12 | | | X.vpn.eth3/11 | 9 | | | Y | 26 | | | Z | 19 | | | -idle- | 48 | | The sum of the current-power-draw top level entries (in this example: X, Y, Z and -idle-, with values 45 + 26 + 19 + 48 = 138) must match the value provided in ietf-poweff-level-1:device-current-total-power-draw The sub-service values (e.g. X.vpn, 39W) need to be lower than or equal to (but do not necessarily need to match) their parent level (e.g. X, 45W). Note: the name of the children have been abbreviated in the diagram above. In the actual payload, the full names would always be used, e.g. 'eth1/16' above would actually be communicated as 'X.vpn.eth1/16'. "; leaf name { type string; description "Name of the service/tenant/client/domain/function that the system allocates power draw for. Power draw MAY be further subdivided for each service by using a dot notation. "; } leaf current-power-draw { type uint32; units W; ietf-poweff-types:sensor-type ietf-poweff-types:st-p-in-true-watt; ietf-poweff-types:tsdb-path poweff.stats.service.current_power_draw; description "The current power draw of the service provided in Watts. "; } leaf-list children { type leafref { path ../../service/name; Lindblad, et al. Expires 8 November 2024 [Page 32] Internet-Draft POWEFF May 2024 } description "Child-services that contribute to the service's power draw. All leafref values must exactly match the names used in the name leaf. "; } } } } 5.6. Module ietf-poweff-level-5.yang module ietf-poweff-level-5 { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-poweff-level-5"; prefix ietf-poweff-level-5; import ietf-poweff-types { prefix ietf-poweff-types; } import ietf-poweff-level-1 { prefix ietf-poweff-level-1; } import ietf-poweff-level-3 { prefix ietf-poweff-level-3; } import ietf-poweff-level-4 { prefix ietf-poweff-level-4; } organization "IETF OPSA (Operations and Management Area) Working Group"; contact "WG Web: WG List: Editor: Jan Lindblad Editor: Snezana Mitrovic Editor: Marisol Palmero "; description "This YANG module defines the POWEFF Level 5. Copyright (c) 2024 IETF Trust and the persons identified as authors of the code. All rights reserved. Lindblad, et al. Expires 8 November 2024 [Page 33] Internet-Draft POWEFF May 2024 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 Revised 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. 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 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. "; revision 2024-04-16 { description "Initial revision of POWEFF Level 5"; reference "RFC XXXX: ..."; } augment /ietf-poweff-level-1:poweff/ietf-poweff-level-3:power-save { description "Level 5 extends the Level 3 & 4 defintions with power control for each on service instance. "; list service { key name; description "List of services that offer power-saving functions. "; leaf name { type leafref { path "/ietf-poweff-level-1:poweff/" + "ietf-poweff-level-1:stats/"+ "ietf-poweff-level-4:service/"+ "ietf-poweff-level-4:name"; require-instance false; } description "Name of the sservice instance that offers power-saving functionality. This name normally matches one of the names in the poweff/stats/service list, but it is Lindblad, et al. Expires 8 November 2024 [Page 34] Internet-Draft POWEFF May 2024 possible that a service is not listed there e.g. because it has not started yet, or has been removed. "; } choice selected-power-save-mode { // FIXME: This is currently a copy of the level-3 power-save // modes. If it is to remain so, we should break it out into // a grouping. But maybe we want them to be different? description "Choice of power saving modes that the Controller may select. Additional power-saving modes may be augmented into this choice by implementors, but may not be known/understood by the controller. "; leaf fully-powered { type empty; description "The service is fully powered, i.e. does not take any power-saving measures that would risk lowering the performance below normal levels. "; } leaf powered-off { type empty; description "The service is completely powered off, i.e. it is drawing no or little power while also delivering zero performance. "; } container napping { description "The service is napping, i.e. is taking frequent but brief pauses in the service it provides. "; leaf max-additional-latency { type ietf-poweff-types:microseconds; description "Determines the maximum tolerated length of the pauses with reduced performance. This means the maximum additional delay that this service would incur on e.g. detecting incoming traffic or performing its function. "; } } container throttling { description Lindblad, et al. Expires 8 November 2024 [Page 35] Internet-Draft POWEFF May 2024 "The service is throttling, i.e. is running with reduced capacity in the functionality it provides. "; leaf max-capacity-reduction { type ietf-poweff-types:percent; description "Determines the maximum tolerated reduction of performance. If this setting is applied to a bundle interface, for example, that consists of 3 underlaying links of equal capacity, and the controller sets the max-capacity-reduction value to 50%, the bundle interface could shut down one of the links. "; } } } leaf max-time-to-cancel-power-save { type ietf-poweff-types:microseconds; description "The maximum time the Controller allows the service to recover full performance. The service should not engage in power-saving measures that take longer than this time to revert to full performance. "; } leaf estimated-power-reduction { type uint32; config false; description "The service's own estimate on how much of its own power draw that is reduced by the power-saving measures in effect. If the controller sets a bundle interface that consists of 3 underlaying links of equal capacity, for example, into 50% throttling mode, the service might shut down one of the underlaying links and report a estimated-power-reduction of 33%. "; } } } } Lindblad, et al. Expires 8 November 2024 [Page 36] Internet-Draft POWEFF May 2024 6. Deployment Considerations POWEFF data models define the data schemas for power consumption and energy efficiency data. POWEFF data models are based on YANG. YANG data models can be used independently of the transport and can be converted into any encoding format supported by the network configuration protocol. YANG is therefore largely management protocol independent. To enable the exchange of POWEFF 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 POWEFF models. * The process to share and collect POWEFF data across the consumers consistently, including the transport mechanism. The POWEFF YANG models can be used with network management protocols such as NETCONF [RFC6241], RESTCONF [RFC8040], streaming telemetry, etc. OpenAPI specification could be considered to consume POWEFF metrics. * How the configuration of assets should be done. 7. Security Considerations The security considerations mentioned in section 17 of [RFC7950] apply. POWEFF 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. POWEFF when used alone or with other relevant data, can identify an individual, revealing Personal Identifiable Information (PII). How the configuration of assets should be accomplished could 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 Lindblad, et al. Expires 8 November 2024 [Page 37] Internet-Draft POWEFF May 2024 for the purpose of privacy and security. Proper authentication and audit trail MUST be included for all the users/processes that access POWEFF data. 8. IANA Considerations 8.1. The IETF XML Registry FIXME 8.2. The YANG Module Names Registry FIXME 9. References 9.1. Normative References [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, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References [I-D.draft-almprs-sustainability-insights-02] Andersson, P., Lindblad, J., Mitrovic, S., Palmero, M., Roure, E., Salgueiro, G., and S. Emile, "Sustainability Insights", Work in Progress, Internet-Draft, draft-almprs- sustainability-insights-02, 20 October 2023, . [I-D.draft-palmero-ivy-ps-almo-01] Palmero, M., Brockners, F., Kumar, S., Cardona, C., and D. Lopez, "Asset Lifecycle Management and Operations: A Lindblad, et al. Expires 8 November 2024 [Page 38] Internet-Draft POWEFF May 2024 Problem Statement", Work in Progress, Internet-Draft, draft-palmero-ivy-ps-almo-01, 24 April 2024, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . Change log RFC Editor Note: This section is to be removed during the final publication of the document. * From version -01 to -02 - Adapted to leverage the updated Philatelist framework - Added the dashboard concept * From version -00 to -01 - Major rewrite as a device level YANG framework - Added the implementation levels concept * Version -00 - Initial version. Acknowledgments This document was created by meaningful contributions from Per Andersson, Jeff Apcar, Derek Engi, Esther Roure Vila, Pascal Thubert, Klaus Verschure, Joel Goergen, Colin Seward, Michael King, Angelo Fienga and Suresh Krishnan. The authors wish to thank them and many others for their helpful comments and suggestions. Lindblad, et al. Expires 8 November 2024 [Page 39] Internet-Draft POWEFF May 2024 Authors' Addresses Jan Lindblad Cisco Systems Email: jlindbla@cisco.com Snezana Mitrovic Cisco Systems Email: snmitrov@cisco.com Marisol Palmero Cisco Systems Email: mpalmero@cisco.com Gonzalo Salgueiro Cisco Systems Email: gsalguei@cisco.com Lindblad, et al. Expires 8 November 2024 [Page 40]