Re: Network Energy Management

George Michaelson <ggm@algebras.org> Thu, 04 August 2022 23:34 UTC

Return-Path: <ggm@algebras.org>
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 7E103C15A723 for <ietf@ietfa.amsl.com>; Thu, 4 Aug 2022 16:34:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20210112.gappssmtp.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 VNsJ8eeq0LsE for <ietf@ietfa.amsl.com>; Thu, 4 Aug 2022 16:34:44 -0700 (PDT)
Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (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 AE836C14F73A for <ietf@ietf.org>; Thu, 4 Aug 2022 16:34:42 -0700 (PDT)
Received: by mail-yb1-xb2c.google.com with SMTP id y127so1422514yby.8 for <ietf@ietf.org>; Thu, 04 Aug 2022 16:34:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=Wg0+UmmiEmZZ+ACM9wG3zp1YUsRDCmGVgJSOpDHTohU=; b=AQOjmYgJN26xpdlvGE4R9xBpfot1ycKPCppv8fmyLK63DDmMb5i6/Ph1LnyFXuDHq9 2k4dpojqIpgVLZHJSBp3lmtT4aiDxnasnBPs8zi6C/qW4OTZCsRtC3zVUCFeVY7xzk9S gmGdrCQmvE7anSMljyWWTnJaAzGSoxffewwj+rOTCLjmJyx58CfddBfeStmA8oFL1oer ax88BR/268awUAhMwSkKJcyB42uOvUOz35V4GEXjemswMBVvCPGp2TYAgwWJEpfQLtcX gk4tBBAHmgQXTQ3+XCfuzCWMCxOiZAEctHfwS4szL0IYXRhTrh6ZbdKO+FC+Tcko9F0j TTUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=Wg0+UmmiEmZZ+ACM9wG3zp1YUsRDCmGVgJSOpDHTohU=; b=ZvHLuJ81p3ztFx9csY9CXvoddVrOaaHn9xP/Oftcvn/OTWCB1Y7Qh58jU9G0vOlF5V iKFQiF1sGSgZwXG0kOeqAY2ae/zNK2c+XG+/3PWn1l8AJ2SAfTnfsWKt2dAJCDHzOExx 7FWKutkXUu7Elr9UaXBRt7lA9GNsWoVM5f20IhAKdsxRTCuH8kLHYYn3UXCqPFkBrcRn GKrq1Vsay8nhmhNaGCzbxR5gYwQwpTWg36q/ziw/R+PFEV5XNKoJPVQWjFigXU3q9n6U fVKws7REWgYemfgb/Wz8F17t+EbOPRvvuiSxcGjoJ+LNOqfRAAVNFXlN9spMx6+61Ovp L/sw==
X-Gm-Message-State: ACgBeo1p6/kJOb5hNISGRCa2fplz9tzonionugN3Yr7anq3ku47q3OWe ogicsc07BN3TRZa021rqJKEW4yW+sPOeolJpl2qJyw==
X-Google-Smtp-Source: AA6agR5zdHM0CT2nI5LGL6RNxCMWXkHdujYlJOJPJUsGnbat2YvFohwR2hDw0WNEC5ZYWGJsfNrFtKi3EtmCGWR5u4w=
X-Received: by 2002:a25:bb86:0:b0:670:ef2:7f9a with SMTP id y6-20020a25bb86000000b006700ef27f9amr3352713ybg.318.1659656081919; Thu, 04 Aug 2022 16:34:41 -0700 (PDT)
MIME-Version: 1.0
References: <81c9a652-81d2-9511-1c4a-3da06e80b48b@gmail.com>
In-Reply-To: <81c9a652-81d2-9511-1c4a-3da06e80b48b@gmail.com>
From: George Michaelson <ggm@algebras.org>
Date: Fri, 05 Aug 2022 09:34:31 +1000
Message-ID: <CAKr6gn2AEv+aKrurBUhKEA_c27c945Xzui=0xrLtRW7HbdpRyA@mail.gmail.com>
Subject: Re: Network Energy Management
To: Hesham ElBakoury <helbakoury@gmail.com>
Cc: IETF <ietf@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/pMkbB1n2EyqeveYtKB6l_qLQ8pw>
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: Thu, 04 Aug 2022 23:34:48 -0000

A comment made to microphone in OPSAWG is that the most expensive
energy component of routing is probably the RF and optical segment,
and if you have any kind of redundancy in routing, you cannot turn
these off. I cant say if this is true or not, I don't know the core
ASIC cost to perform switching. So I take this on trust.

The general tone to the comments was "can we stick to the tractable
part of the problem and not wade into things which are political" (my
words) -Not that you are,  just to round out what I think I heard in
the room.

Basically, this conversation is in OPSAWG:
https://datatracker.ietf.org/meeting/114/materials/agenda-114-opsawg-01

cheers
-G

On Fri, Aug 5, 2022 at 9:12 AM Hesham ElBakoury <helbakoury@gmail.com> wrote:
>
> 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
>