Re: Network Energy Management

Joel Halpern <jmh@joelhalpern.com> Fri, 05 August 2022 02:13 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1EA3C14CF00 for <ietf@ietfa.amsl.com>; Thu, 4 Aug 2022 19:13:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oarx0SNxtVSW for <ietf@ietfa.amsl.com>; Thu, 4 Aug 2022 19:12:56 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 372DFC14F72B for <ietf@ietf.org>; Thu, 4 Aug 2022 19:12:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4LzTdg57gcz6Gq27; Thu, 4 Aug 2022 19:12:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1659665575; bh=MvoupdCSSlHWx1KZoal8A90Cdpnu1Oztv8+P1mZAQ0Y=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=NPT78sTAJftQxhqq8yRDPMhufIIAyMl2sCZDEMxWDlJ0SDlpk5Codfj7a+6UpAwlI QlZOVTCLej0v2qeqypEmfHnfpz2tvZ+Kwlzw1/mb2TIxbzUylfLxIYGfQzA4oXch+z n4A1HxPv2PhhZdCXlawdFXNYF/SI+6ThbOV2batw=
X-Quarantine-ID: <og27_gIBkYmL>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.23.181] (unknown [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4LzTdg0NgRz6GdRF; Thu, 4 Aug 2022 19:12:54 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------Tuw5cN19ItOGOAgSQAGBxiE6"
Message-ID: <acb080c1-3409-58e5-2814-3284413497e2@joelhalpern.com>
Date: Thu, 04 Aug 2022 22:12:53 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
Subject: Re: Network Energy Management
Content-Language: en-US
To: Tianran Zhou <zhoutianran=40huawei.com@dmarc.ietf.org>, Hesham ElBakoury <helbakoury@gmail.com>
Cc: IETF <ietf@ietf.org>
References: <81c9a652-81d2-9511-1c4a-3da06e80b48b@gmail.com> <c23c3f60359249f3959e14d616f014c4@huawei.com> <CAFvDQ9qQKTD5QSmmsD7Yuv+KihBxusXi4BD8wcuWxRGhy556HA@mail.gmail.com> <7dcc2e2d7cf245c88ab7788f0df36148@huawei.com>
From: Joel Halpern <jmh@joelhalpern.com>
In-Reply-To: <7dcc2e2d7cf245c88ab7788f0df36148@huawei.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/8w1ANwZ5LCB4uY6LGZZ2_oW2x-E>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Aug 2022 02:13:00 -0000

I am finding this conversation somewhta strange.

Having the ability to monitor energy consumption and report it is 
understandable.  And I can see how the reporting of that could fall into 
a YANG module or similar construct done in the IETF.

But power distribution, power storage, power rearrangement?  That is for 
power engineers, not the IETF.  We don't tell people how to power their 
routers.  We don't tell them whether to put batteries in the router, in 
their UPS, or somewhere else entirely.  Not our expertise.

We have in the past discussed turning things off when not in use.  As 
noted earlier in the thread, from where we sit, rather tricky.   Someone 
developing an AI / ML system to drive heuristics for it may or may not 
be useful.  But again doesn't look like IETF business.  Our job is to 
provide the data such systems would need.  Which we already do.

Yours,

Joel

On 8/4/2022 9:53 PM, Tianran Zhou wrote:
>
> Hi Hesham,
>
> To be specific, what’s your thoughts on the following two use cases.
>
> 3- Use traffic analysis and modeling techniques perhaps with AI/ML 
> algorithms to predict which elements to power down/up and when, in 
> such a way to avoid service disruption.
> 4- Use renewable energy, store it in the router and return back to the 
> energy source the energy that is not used so that someone else can use it.
>
> Thanks,
>
> Tianran
>
> *From:*Hesham ElBakoury [mailto:helbakoury@gmail.com]
> *Sent:* Friday, August 5, 2022 9:08 AM
> *To:* Tianran Zhou <zhoutianran@huawei.com>
> *Cc:* IETF <ietf@ietf.org>
> *Subject:* Re: Network Energy Management
>
> There are publicatipns about changes to IP, TCP, Routing Protocols, 
> Traffic Engineering, ... etc but I am not sure if these changes are 
> implemented and deployed in service provider networks.
>
> Thanks
>
> Hesham
>
> On Thu, Aug 4, 2022, 5:49 PM Tianran Zhou <zhoutianran@huawei.com> wrote:
>
>     While I think this is an very interesting topic that I would like
>     to follow, I am confused most of the proposal here may not related
>     to network protocol.
>     I.e, I am not sure what IETF can help on this.
>
>     Best,
>     Tianran
>
>     -----Original Message-----
>     From: ietf [mailto:ietf-bounces@ietf.org] On Behalf Of Hesham
>     ElBakoury
>     Sent: Friday, August 5, 2022 7:12 AM
>     To: IETF <ietf@ietf.org>
>     Subject: Network Energy Management
>
>     There has been some discussions in IETF 114 about how to reduce
>     the network energy consumption and carbon footprint. Most of the
>     energy-aware routing and traffic engineering publications that I
>     have seen rely on powering down network elements such as
>     interfaces, line cards and routers to save power. The problems
>     with this approach are: 1) to power up these elements when they
>     are needed may take long time which may cause undesirable service
>     disruption, and 2) network operators may not trust routing and
>     traffic engineering software to power down and up these elements
>     without operator intervention.
>
>     To address these problems we may do one of the following:
>
>     1- Do not power down any network element, and try some other way
>     to reduce energy such as adjusting the cooling level based on
>     network load.
>
>     2- Do not power down any network element, but put the element in
>     low power idle state to consume least amount of power while it is
>     not used to forward traffic.  In this state it is quicker to bring
>     the element into fully operational state. This solution may
>     require hardware support.
>
>     3- Use traffic analysis and modeling techniques perhaps with AI/ML
>     algorithms to predict which elements to power down/up and when, in
>     such a way to avoid service disruption.
>
>     4- Use renewable energy, store it in the router and return back to
>     the energy source the energy that is not used so that someone else
>     can use it.
>
>     5- If you have other approaches, please let us know.
>
>     In all these approaches we need to instrument the network to
>     monitor its traffic loading and energy consumption.
>
>     Comments ?
>
>     Hesham
>