Re: Network Energy Management

Hesham ElBakoury <helbakoury@gmail.com> Fri, 05 August 2022 04:47 UTC

Return-Path: <helbakoury@gmail.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 23D0BC14F74E for <ietf@ietfa.amsl.com>; Thu, 4 Aug 2022 21:47:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 u1Mk8NwcwClA for <ietf@ietfa.amsl.com>; Thu, 4 Aug 2022 21:47:37 -0700 (PDT)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 ietfa.amsl.com (Postfix) with ESMTPS id D12E0C157B52 for <ietf@ietf.org>; Thu, 4 Aug 2022 21:47:37 -0700 (PDT)
Received: by mail-qt1-x82f.google.com with SMTP id ey23so1307593qtb.11 for <ietf@ietf.org>; Thu, 04 Aug 2022 21:47:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=8HbwdqYBZN/GSHSdWE6vLGuQe5t8+bvM7qOZsRvsj1E=; b=MuPGBSHm+a3qvmA+sr69whhq6whFp7ED1CQ8dfn2CDTqB/EnP8S1HWc9e1EMECsxs/ b0FKdNp+pxdkJvNO5BX4QaNrKsj+3MdIC/aLr+n5TisRZAQ3lJWVTvSMXOLFWhikJ0HJ jCDuM3Z7vH0qoLxvrBZypt3kSChkWVLVQyO0Bl+PuulkLSZiMhWK+NH/XamRKSm2Y4IT CVy5x9Bdw5NL1cMkqqNSCP2hTj3P6gWTiSWToVSKR4XFLOswJF6/O9vAZq90NFzYdjL1 LJApavNvLzfg6gtVQeRiK1pn5rlCXaF09TQATowAJVziNaRzDYAYbxu3pOFoHv6Zb19J xxsA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=8HbwdqYBZN/GSHSdWE6vLGuQe5t8+bvM7qOZsRvsj1E=; b=1Hz8sHTj+UAw2U3rHnz4j11uGuXe6ZkpoiI/L9KeDLVdcz0MYE2ooI/674G4Ea4Aa6 qzNrPe9Dq82G5M8+zvZTCO6Amj50DdFySagEJJ43FfXR007/u0lyh73OY3cqn8+2WO4X b3SkHAhv66qztK9ESVxzswIc5mz3r+hPtBz8kH7Bzp7sa6Stmc9xcWM3xmJGDtno+JvT 9YAgqKvg1f2DlYqipCmLDlqGK6d9YuYL3Mz5v4i7uhkLdh7YYOYPrq2aRT3ZTl35fpSp wzWXvbJPHq7RNF8nui0JW1TO9Yu3AuwghlvosZs06f43MOOqdDD+EaCda9jItg4ofXXa 3w/Q==
X-Gm-Message-State: ACgBeo1EYxEhtcRohLEN0X7/MecoRhBSVcxV2dQ3U/V+jRs1vUf0cm5n N65n35mEIykgERG+U6An+Pc=
X-Google-Smtp-Source: AA6agR5b2kSw5GWoiQk9lFyD4ZbGpg9PRNM4sJ18Z+wPdWj3rB+/ek0685nZiRKwXUclk39X3zTW/Q==
X-Received: by 2002:ac8:5848:0:b0:31e:f4d3:fe59 with SMTP id h8-20020ac85848000000b0031ef4d3fe59mr4453753qth.662.1659674856488; Thu, 04 Aug 2022 21:47:36 -0700 (PDT)
Received: from ?IPV6:2602:306:cc88:dec9:4dff:4d2e:7592:838f? ([2602:306:cc88:dec9:4dff:4d2e:7592:838f]) by smtp.gmail.com with ESMTPSA id x21-20020a05620a0b5500b006b5f06186aesm1992891qkg.65.2022.08.04.21.47.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Aug 2022 21:47:36 -0700 (PDT)
Message-ID: <1893e737-698e-c428-e55e-b8d613988163@gmail.com>
Date: Thu, 04 Aug 2022 21:47:33 -0700
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: George Michaelson <ggm@algebras.org>
Cc: Tianran Zhou <zhoutianran@huawei.com>, IETF <ietf@ietf.org>
References: <81c9a652-81d2-9511-1c4a-3da06e80b48b@gmail.com> <c23c3f60359249f3959e14d616f014c4@huawei.com> <CAFvDQ9qQKTD5QSmmsD7Yuv+KihBxusXi4BD8wcuWxRGhy556HA@mail.gmail.com> <7dcc2e2d7cf245c88ab7788f0df36148@huawei.com> <2c3b9597-c1f4-a062-50ba-ba55d342c7d2@gmail.com> <CAKr6gn2T=Lu3h0w3_tdD2Yu-iTXdGky1ei1pXUWs46k8-dyqhw@mail.gmail.com>
From: Hesham ElBakoury <helbakoury@gmail.com>
In-Reply-To: <CAKr6gn2T=Lu3h0w3_tdD2Yu-iTXdGky1ei1pXUWs46k8-dyqhw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/PFfYYYO3P-FB74ls3m5dVxw41Wo>
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 04:47:42 -0000

There are representatives of several service providers who attend IETF. 
They may have good ideas on the solutions they need to achieve their Net 
Zero goal, and what needs to be standardized (if any) in IETF.

Thank

Hesham

On 8/4/2022 9:25 PM, George Michaelson wrote:
> If you want to ask SP's a question, a NOG list or a WG is a better
> place than an IETF wide list.
>
> -G
>
> On Fri, Aug 5, 2022 at 2:11 PM Hesham ElBakoury <helbakoury@gmail.com> wrote:
>> Actually, I am interested to find out from service providers what solutions they need to deploy to achieve their Net-Zero goal and what needs to be standardized (if any) to deploy these solutions.
>>
>> Hesham
>>
>> On 8/4/2022 6: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