Skip to main content

A YANG model for Power Management
draft-li-green-power-00

Document Type Active Internet-Draft (individual)
Authors Tony Li , Ron Bonica
Last updated 2024-10-17
Replaces draft-li-ivy-power
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-li-green-power-00
IVY Working Group                                                  T. Li
Internet-Draft                                                 R. Bonica
Intended status: Standards Track                        Juniper Networks
Expires: 20 April 2025                                   17 October 2024

                   A YANG model for Power Management
                        draft-li-green-power-00

Abstract

   Network sustainability is a key issue facing the industry.  Networks
   consume significant amounts of power at a time when the cost of power
   is rising and sensitivity about sustainability is very high.  As an
   industry, we need to find ways to optimize the power efficiency of
   our networks both at a micro and macro level.  We have observed that
   traffic levels fluctuate and when traffic ebbs there is much more
   capacity than is needed.  Powering off portions of network elements
   could save a significant amount of power, but to scale and be
   practical, this must be automated.

   The natural mechanism for enabling automation would be a Yet Another
   Next Generation (YANG) interface, so this document proposes a YANG
   model for power management.

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 20 April 2025.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Li & Bonica               Expires 20 April 2025                 [Page 1]
Internet-Draft            YANG Power Management             October 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirement Language  . . . . . . . . . . . . . . . . . .   3
   2.  Power Management Elements . . . . . . . . . . . . . . . . . .   3
     2.1.  Power consumption . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Power control capability  . . . . . . . . . . . . . . . .   4
     2.3.  Power control . . . . . . . . . . . . . . . . . . . . . .   4
     2.4.  Automatic Power Saving  . . . . . . . . . . . . . . . . .   4
   3.  Functional Dependencies . . . . . . . . . . . . . . . . . . .   5
     3.1.  Required Components . . . . . . . . . . . . . . . . . . .   5
     3.2.  Dependent components  . . . . . . . . . . . . . . . . . .   5
   4.  Tree Representation . . . . . . . . . . . . . . . . . . . . .   6
   5.  Traffic Planning  . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Tree Representation . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   Network sustainability is a key issue facing the industry.  Networks
   consume significant amounts of power at a time when the cost of power
   is rising and sensitivity about sustainability is very high.  As an
   industry, we need to find ways to optimize the power efficiency of
   our networks both at a micro and macro level.  We have observed that
   traffic levels fluctuate and when traffic ebbs there is much more
   capacity than is needed.  Powering off portions of network elements
   could save a significant amount of power, but to scale and be
   practical, this must be automated.

   The natural mechanism for enabling automation would be a Yet Another
   Next Generation (YANG) interface, so this document proposes a YANG
   model for power management.

   [RFC8348] already provides a model for server hardware management,
   but does not naturally extend to routers and other network elements.
   That gap is currently being addressed by

Li & Bonica               Expires 20 April 2025                 [Page 2]
Internet-Draft            YANG Power Management             October 2024

   [I-D.ietf-ivy-network-inventory-yang].  This document extends the
   work presented there to include power management.  Specifically, this
   document augments the 'component' object found at /ietf-network-
   inventory/network-elements/network-element/components/component.

   This initial draft only provides a tree representation.  When there
   is rough consensus on the tree represetnation, the details of the
   model will be fleshed out.

1.1.  Requirement 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.  These words may also appear in this
   document in lower case as plain English words, absent their normative
   meanings.

2.  Power Management Elements

   The models mentioned above already model a router or network element
   as a set of components.  The details of those components are left to
   the specific implementation and can be at any level of specificity.
   Thanks to this flexibility, it is necessary and sufficient that we
   characterize power management relative to components.

   The elements defined below allow management entities to understand
   how much power each component is using and whether the component can
   be placed into a 'power-save' mode where it would consume less power.
   Another element allows the management plane to put the component into
   power-save mode.

2.1.  Power consumption

           Name: used-power
           Node Type: leaf
           Data Type: uint32
           Description: Power drawn by the component, in watts.

   This node is applied to components in the model.  If an accurate
   dynamic power measurement is not available, then static power
   estimates are acceptable.

Li & Bonica               Expires 20 April 2025                 [Page 3]
Internet-Draft            YANG Power Management             October 2024

           Name: total-used-power
           Node Type: leaf
           Data Type: uint32
           Description: Power drawn by the component and its
             subcomponents, in watts.

   This node captures the total power used by a component and all of its
   subcomponents.  This simplifies reporting requirements.  If an
   accurate dynamic power measurement is not available, then static
   power estimates are acceptable.

2.2.  Power control capability

           Name: power-save-capable
           Node Type: leaf
           Data Type: boolean
           Description: True if the component can be put into power-save
             mode.

2.3.  Power control

           Name: power-save
           Node Type: leaf
           Data Type: Boolean
           Access: Read/write
           Description: True if the component is in power-save mode.

   There have been suggestions that this leaf should accept a variety of
   values, representing many different 'power states'.  This presumes
   that the external entity understands the exact state of the device,
   the impact of the power state, and the optimal setting.  A better
   approach is to enable automatic power saving on the component and
   then provide information to the device about the external state to
   allow the device to optimize its own behavior.  Section 5 is an
   example of the type of external state information that may be useful.

2.4.  Automatic Power Saving

   Some systems (e.g., fan trays) have the capability to self-manage
   their power consumption.  However there are cases where this
   capability should be disabled.

           Name: automatic-power-saving
           Node Type: leaf
           Data Type: Boolean
           Access: Read/write
           Description: True if the component is regulating its own
             power.

Li & Bonica               Expires 20 April 2025                 [Page 4]
Internet-Draft            YANG Power Management             October 2024

3.  Functional Dependencies

   Most inventory models have a hierarchy of components.  This hierarchy
   reflects the physical structure of the system (e.g., a line card can
   physically contain a port).

   With regard to physical containment, components maintain a one-to-
   many relationship.  That is, Component A can contain many other
   components, including Component B.  However, component B can be
   contain by only one component (i.e., Component A.)

   However, legacy inventory models do not reflect functional
   dependencies.  Specifically, they do not indicate which components
   obtain services from, and therefore depend, components other than
   their container.  Because funtional dependencies are relavant to
   power management, they are included in the proposed model.

   With regard to functional dependencies, components maintain a many-
   to-many relationship.  That is, a component can reuire on many
   components and be required by many other components.

   Functional dependencies may be updated dynamically.

3.1.  Required Components

   This container holds a list of components that the component uses.
   For example, a linecard uses a set of switch cards, so the switch
   cards would be required components.  If the bandwidth used by the
   linecard changes, then the set of switch cards that are required may
   change dynamically.

           Name: required-components
           Node Type: list
           Description: A list of other components that are required for
             this component to operate.

3.2.  Dependent components

   This container holds a list of components that are used by this
   component.  For example, a switch card is used by a set of line
   cards, so the line cards would be dependent components.  This list
   can also change dynamically.

           Name: dependent-components
           Node Type: list
           Description: A list of other components that are used by this
             component.

Li & Bonica               Expires 20 April 2025                 [Page 5]
Internet-Draft            YANG Power Management             October 2024

4.  Tree Representation

    +--rw component* [component-id]
       +--rw component-id               string
       +--ro used-power?                uint32
       +--ro power-save-capable?        boolean
       +--rw power-save?                boolean
       +--ro required-components*       -> ../../component/component-id
       +--ro dependent-components*      -> ../../component/component-id

5.  Traffic Planning

   Some systems have the capability of automatically managing their
   power consumption if they have an understanding of the expected
   traffic loads.  To provide this, we provide the expected input and
   output bandwidth for each interface and augment '/interfaces/
   interface' [RFC8343] with the following:

           Name: expected-input-bandwidth
           Node Type: leaf
           Data Type: yang:gauge64
           Default: 0
           Access: Read/write
           Description: The expected input bandwidth of the interface,
             in Mbps. A value of zero (0) indicates full bandwidth.

           Name: expected-output-bandwidth
           Node Type: leaf
           Data Type: yang:gauge64
           Default: 0
           Access: Read/write
           Description: The expected output bandwidth of the interface,
             in Mbps. A value of zero (0) indicates full bandwidth.

5.1.  Tree Representation

    +--rw interface* [name]
       +--rw expected-input-bandwidth?     yang:gauge64
       +--rw expected-output-bandwidth?    yang:gauge64

6.  Security Considerations

   YANG provides information about and configuration capabilities to the
   network management plane.  Other mechanisms already exist that help
   secure these interactions.  This document extends the scope of what
   can be controlled by the management plane, but creates no new access
   paths.

Li & Bonica               Expires 20 April 2025                 [Page 6]
Internet-Draft            YANG Power Management             October 2024

7.  IANA Considerations

   This document makes no requests for IANA.

8.  Normative References

   [RFC8348]  Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A
              YANG Data Model for Hardware Management", RFC 8348,
              DOI 10.17487/RFC8348, March 2018,
              <https://www.rfc-editor.org/info/rfc8348>.

   [I-D.ietf-ivy-network-inventory-yang]
              Yu, C., Belotti, S., Bouquier, J., Peruzzini, F., and P.
              Bedard, "A YANG Data Model for Network Inventory", Work in
              Progress, Internet-Draft, draft-ietf-ivy-network-
              inventory-yang-03, 7 July 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ivy-
              network-inventory-yang-03>.

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

   [RFC8343]  Bjorklund, M., "A YANG Data Model for Interface
              Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
              <https://www.rfc-editor.org/info/rfc8343>.

Authors' Addresses

   Tony Li
   Juniper Networks
   Email: tony.li@tony.li

   Ron Bonica
   Juniper Networks
   Email: rbonica@juniper.net

Li & Bonica               Expires 20 April 2025                 [Page 7]