RE: Network Energy Management

Tianran Zhou <zhoutianran@huawei.com> Fri, 05 August 2022 00:49 UTC

Return-Path: <zhoutianran@huawei.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 2F9BFC14F72D for <ietf@ietfa.amsl.com>; Thu, 4 Aug 2022 17:49:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 6PAeLSim7tvO for <ietf@ietfa.amsl.com>; Thu, 4 Aug 2022 17:49:03 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87025C14F722 for <ietf@ietf.org>; Thu, 4 Aug 2022 17:49:03 -0700 (PDT)
Received: from fraeml707-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4LzRjz0LqSz688yX for <ietf@ietf.org>; Fri, 5 Aug 2022 08:46:31 +0800 (CST)
Received: from kwepemi100009.china.huawei.com (7.221.188.242) by fraeml707-chm.china.huawei.com (10.206.15.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Fri, 5 Aug 2022 02:48:59 +0200
Received: from kwepemi500009.china.huawei.com (7.221.188.199) by kwepemi100009.china.huawei.com (7.221.188.242) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Fri, 5 Aug 2022 08:48:58 +0800
Received: from kwepemi500009.china.huawei.com ([7.221.188.199]) by kwepemi500009.china.huawei.com ([7.221.188.199]) with mapi id 15.01.2375.024; Fri, 5 Aug 2022 08:48:58 +0800
From: Tianran Zhou <zhoutianran@huawei.com>
To: Hesham ElBakoury <helbakoury@gmail.com>, IETF <ietf@ietf.org>
Subject: RE: Network Energy Management
Thread-Topic: Network Energy Management
Thread-Index: AQHYqFe+Q9YhSMaWtka65P75XWJuYK2feQtw
Date: Fri, 05 Aug 2022 00:48:58 +0000
Message-ID: <c23c3f60359249f3959e14d616f014c4@huawei.com>
References: <81c9a652-81d2-9511-1c4a-3da06e80b48b@gmail.com>
In-Reply-To: <81c9a652-81d2-9511-1c4a-3da06e80b48b@gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.40.195]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/n9IIZjKNFZHs-JKvGb3kfJjFoOw>
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 00:49:05 -0000

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