Internet DRAFT - draft-li-ivy-power
draft-li-ivy-power
IVY Working Group T. Li
Internet-Draft R. Bonica
Intended status: Standards Track Juniper Networks
Expires: 18 April 2024 16 October 2023
A YANG model for Power Management
draft-li-ivy-power-01
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 18 April 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Li & Bonica Expires 18 April 2024 [Page 1]
Internet-Draft YANG Power Management October 2023
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 Management . . . . . . . . . . . . . . . 4
3. Functional Dependencies . . . . . . . . . . . . . . . . . . . 4
3.1. Required Components . . . . . . . . . . . . . . . . . . . 5
3.2. Dependent components . . . . . . . . . . . . . . . . . . 5
4. Tree Representation . . . . . . . . . . . . . . . . . . . . . 5
5. Traffic Planning . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Tree Representation . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Normative References . . . . . . . . . . . . . . . . . . . . 6
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 18 April 2024 [Page 2]
Internet-Draft YANG Power Management October 2023
[I-D.wzwb-opsawg-network-inventory-management] and
[I-D.ietf-ccamp-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-
hardware-inventory/network-hardware-inventory/network-elements/
network-element/components/component in
[I-D.ietf-ccamp-network-inventory-yang].
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 18 April 2024 [Page 3]
Internet-Draft YANG Power Management October 2023
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.
2.4. Automatic Power Management
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-management
Node Type: leaf
Data Type: Boolean
Access: Read/write
Description: True if the component is regulating its own
power.
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.
Li & Bonica Expires 18 April 2024 [Page 4]
Internet-Draft YANG Power Management October 2023
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.
4. Tree Representation
+--ro component* [uuid]
+--ro uuid yang:uuid
+--ro used-power? uint32
+--ro power-save-capable? boolean
+--rw power-save? boolean
+--ro required-components* -> ../uuid
+--ro dependent-components* -> ../uuid
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 [RFC7223] with the
following:
Li & Bonica Expires 18 April 2024 [Page 5]
Internet-Draft YANG Power Management October 2023
Name: expected-input-bandwidth
Node Type: leaf
Data Type: uint32
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: uint32
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? uint32
+--rw expected-output-bandwidth? uint32
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.
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.wzwb-opsawg-network-inventory-management]
Wu, B., Zhou, C., Wu, Q., and M. Boucadair, "A Network
Inventory Management Model", Work in Progress, Internet-
Draft, draft-wzwb-opsawg-network-inventory-management-03,
24 July 2023, <https://datatracker.ietf.org/doc/html/
draft-wzwb-opsawg-network-inventory-management-03>.
Li & Bonica Expires 18 April 2024 [Page 6]
Internet-Draft YANG Power Management October 2023
[I-D.ietf-ccamp-network-inventory-yang]
Yu, C., Belotti, S., Bouquier, J., Peruzzini, F., and P.
Bedard, "A YANG Data Model for Network Hardware
Inventory", Work in Progress, Internet-Draft, draft-ietf-
ccamp-network-inventory-yang-02, 9 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-ccamp-
network-inventory-yang-02>.
[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>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<https://www.rfc-editor.org/info/rfc7223>.
Authors' Addresses
Tony Li
Juniper Networks
Email: tony.li@tony.li
Ron Bonica
Juniper Networks
Email: rbonica@juniper.net
Li & Bonica Expires 18 April 2024 [Page 7]
