Re: Network Energy Management

Hesham ElBakoury <helbakoury@gmail.com> Fri, 05 August 2022 01:08 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 7BF01C14F73F for <ietf@ietfa.amsl.com>; Thu, 4 Aug 2022 18:08:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 g_fxTc2qxx5S for <ietf@ietfa.amsl.com>; Thu, 4 Aug 2022 18:08:34 -0700 (PDT)
Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (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 06C08C14F72D for <ietf@ietf.org>; Thu, 4 Aug 2022 18:08:33 -0700 (PDT)
Received: by mail-qv1-xf2b.google.com with SMTP id y11so866442qvn.3 for <ietf@ietf.org>; Thu, 04 Aug 2022 18:08:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SW4CjWuxFHgCVyR9soUBBQU4BnfHFtnivs8eq8UkkMw=; b=MakekwVAfZxNrVX/BRlj5Jc3jJlHz9IP+81KxMA7XUzG09ZyA/1bYgbNgOKbvf0Rid v7wbeHX7dupHzgT0T3JHy48wFuiF0fIVLx33zeNjtSJp8Nb4wpI+cAc14RlXSYeHoNG/ ljw3M7w5pdommocceR9RXo47mAajG04KHfctmZ9nX86hN3FaqudYd6wR11eaDrhI7FyF EZ8Rm7CQH8stYHnYygtK9xH18wqMgIC1mhmf6hBL9Oe0aEScBIzl+3R04um6qaDlsob2 TEMi/ogBfBDFh5veyGEvOhMpNWKUJnl7lN6utlwe2sFk+1c2gjze1hzDztjJdIk1N8pX r1vA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SW4CjWuxFHgCVyR9soUBBQU4BnfHFtnivs8eq8UkkMw=; b=s3Hwg10bcEQryICnZyIM7pKVdbcVhZp09iX+OamWQ4i3CDdmRmxKHWG0ohZprpWAAx rMGrJapwuQMbec2NG+QX6KLKKR2H8daGEonS2VtvdErhT4ZdoeK4IjAryM9NUaphvRYh KpDYitpH+Zm1WLTZ4kkBd1FzuRmUjp9mNl+gvvKygucos92ijzVrpMz3eSSPxq0OOqzd jWZkejnv2aZ6PYMcsDDfTS9q6JvKFpaggyeaq6pClbWBfcJOsFUOg0yJOcaXrqK6YG9d fby5yOCsw5o+JSIyX5pBNdqEJZH0y2Ujmq1VPN6iH6Ki/AZg+n0LdlgM6ygg/Su0fr79 U2Pw==
X-Gm-Message-State: ACgBeo1U/w1QHspw9t+OD3UW4yp6LquLA6aQrdDA4syvwQnFsn1TEvzM 5CPM1yIV8Efd/Ggw5UzZz/pw3hQIE0HLUwm9kmk=
X-Google-Smtp-Source: AA6agR7smVSvnbLlP6BaRtcC/CyjsSxaz2NZPcDyeY22tNDL/HJ9pqaFi8869g1rajOA3J8lzj5XSWYLYuyxDi1pgbg=
X-Received: by 2002:ad4:5fc7:0:b0:478:c84c:6c01 with SMTP id jq7-20020ad45fc7000000b00478c84c6c01mr2637466qvb.127.1659661712896; Thu, 04 Aug 2022 18:08:32 -0700 (PDT)
MIME-Version: 1.0
References: <81c9a652-81d2-9511-1c4a-3da06e80b48b@gmail.com> <c23c3f60359249f3959e14d616f014c4@huawei.com>
In-Reply-To: <c23c3f60359249f3959e14d616f014c4@huawei.com>
From: Hesham ElBakoury <helbakoury@gmail.com>
Date: Thu, 04 Aug 2022 18:08:20 -0700
Message-ID: <CAFvDQ9qQKTD5QSmmsD7Yuv+KihBxusXi4BD8wcuWxRGhy556HA@mail.gmail.com>
Subject: Re: Network Energy Management
To: Tianran Zhou <zhoutianran@huawei.com>
Cc: IETF <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d8358d05e5741a9a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/KX8C1YQRipx2YPsYVIEt4JnKwzs>
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 01:08:38 -0000

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