Re: [E-impact] Why carbon aware routing ...
Toerless Eckert <tte@cs.fau.de> Tue, 20 February 2024 16:12 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: e-impact@ietfa.amsl.com
Delivered-To: e-impact@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D88C18DB8C for <e-impact@ietfa.amsl.com>; Tue, 20 Feb 2024 08:12:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.657
X-Spam-Level:
X-Spam-Status: No, score=-6.657 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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=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 diRTLOZOnzQ4 for <e-impact@ietfa.amsl.com>; Tue, 20 Feb 2024 08:12:44 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (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 9D806C14F71D for <e-impact@ietf.org>; Tue, 20 Feb 2024 08:12:43 -0800 (PST)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 4TfPZG3CFYznkPW; Tue, 20 Feb 2024 17:12:38 +0100 (CET)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4TfPZG2M9RzkmtP; Tue, 20 Feb 2024 17:12:38 +0100 (CET)
Date: Tue, 20 Feb 2024 17:12:38 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Vesna Manojlovic <BECHA@ripe.net>
Cc: e-impact@ietf.org
Message-ID: <ZdTPdirfKJMiVHx2@faui48e.informatik.uni-erlangen.de>
References: <CADbu6ZpetH22JXhnN8U6+n2SEwPf-T8vbMtZxVfOjyL=qozbbA@mail.gmail.com> <459643D6-2B47-4980-BA8D-88CABCE76982@ifi.uio.no> <CAFvDQ9r4raECRF6T2sjNg9JhhSBaUD3zAMgc35vjhVw8_UNaRQ@mail.gmail.com> <CAPWZuKn=rXYhSOvSXSfhUCbOHAmAW6Ve8vF-=4jaMzSsdHt5tA@mail.gmail.com> <f0374fc1-5dd1-4c94-9b6b-bba51c5a903e@hefr.ch> <CAPWZuKmnA1udMUxf8pFLcn_8a3J7L2CaMueSk6A5z9uFCJQh5g@mail.gmail.com> <ZdPsTna9ZoXx1SuR@faui48e.informatik.uni-erlangen.de> <BL0PR05MB552403DA56E7AB956D524E3DDA502@BL0PR05MB5524.namprd05.prod.outlook.com> <ZdS608KYj9pI8jbX@faui48e.informatik.uni-erlangen.de> <4c5cf734-727a-4e80-bf44-2c92c5885aef@ripe.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4c5cf734-727a-4e80-bf44-2c92c5885aef@ripe.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/e-impact/cv1rcwNs6bIeIVunppRIU1kWIs4>
Subject: Re: [E-impact] Why carbon aware routing ...
X-BeenThere: e-impact@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Environmental impacts of the Internet <e-impact.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/e-impact>, <mailto:e-impact-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/e-impact/>
List-Post: <mailto:e-impact@ietf.org>
List-Help: <mailto:e-impact-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/e-impact>, <mailto:e-impact-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Feb 2024 16:12:48 -0000
On Tue, Feb 20, 2024 at 04:59:50PM +0100, Vesna Manojlovic wrote:
> > Carbon aware routing is fine if all the factors play out, but as Rudolf and i tried to
> > explain, there are just a lot of "ifs" that must be met before the approach can make money,
>
> I see the added "sustainability" of routing / networking comparable to the
> added security - it is not directly going to make any money for the
> operator, but in the long term is is important to implement it - for other
> (business, regulation, trust...) reasons.
A bit too much hand waiving for me. What is "business" other than "money" ?
Where are the "regulations" ? How would you even regulate this ? Today the closest i think
we are to regulation is that policy makers simply raise more taxes against CO2 producing
energy to make green energy cheaper in comparison. But then you just buy more green energy
for your network, no carbon aware routing needed. What is "trust" ?
And btw: "security" is not selling equally well in all countries. Some seem to be
happy to just wait for sh*t to happen and then fix it afterwards..
> And this analogy goes further, to address the statements such as
>
> "every network operator gets to decide for themselves how to run their own
> network"
>
> ... which is partially true - indeed, ASNs are numbering "autonomous"
> networks ...
>
> and at the same time, the *cooperation* between these networks is what makes
> BGP work! The "Mutually Agreed Norms for Routing Security (MANRS)", such as
> route-flap dampening parameters & RPKI validation are not enforced nor
> forced on the operators,
>
> each ISP can decide to NOT follow those "guidelines" (rules?),
>
> but then they would soon find out that there are consequences, such as:
> other autonomous network operators would not want to inter-connect with
> them!
Yes, but that is because those other operators will incur loss of money because
of attacks coming from that other network but impact reliable operations == money
on their own network.
You need to create a viable scenario in which an operator has a monetary benefit
or regulatory requirement to include considerations for greenness upon not only
its own network, but that of its transitive peers.
> > But carbon aware routing is not just an accounting methods, but its serious network operations work, and a good
> > amount of that introduces a risk of creating more instability in the network
>
> exactly same arguments are valid for added security, via RPKI.
Which is why it took/takes so long to get deployed.
> it introduces complexity, additional risks, and more instability.
>
> and just like "sustainability", it also prevents other risks, and brings
> other benefits - specially in the long term.
Again too much hand waiving. This needs to be more specific to sell.
Not saying that this can't be done, it just gets harder the more you get towards
those crucial details, so there is little value in just the high level hand waiving.
> For these other benefits, it is worth exploring potential solutions such as
> "carbon aware routing" and improving on them, as some parts of this thread
> are doing.
As i sai, i think there is a lot that would be useful IMHO to write up, but i see
no appropriate venue to do this in the IETF because its a lot more policy,
regulation and other aspects that IETF will declare itself to be non-authoritative for.
Cheers
Toerless
> I am curious if the original authors will be able to distill the
> constructive feedback & improve on their original idea. I'd be interested in
> a follow-up!
>
> Vesna
>
>
> --
> Senior Community Builder, RIPE NCC
> https://labs.ripe.net/author/becha/
>
> --
> E-impact mailing list
> E-impact@ietf.org
> https://www.ietf.org/mailman/listinfo/e-impact
--
---
tte@cs.fau.de
- [E-impact] Carbon aware routing Hesham ElBakoury
- Re: [E-impact] Carbon aware routing Toerless Eckert
- Re: [E-impact] Carbon aware routing Hesham ElBakoury
- Re: [E-impact] Carbon aware routing Dirk Trossen
- Re: [E-impact] Carbon aware routing Chris Adams
- Re: [E-impact] Carbon aware routing Noa Zilberman
- Re: [E-impact] Carbon aware routing Rudolf van der Berg
- Re: [E-impact] Carbon aware routing Hesham ElBakoury
- Re: [E-impact] Carbon aware routing Eve Schooler
- Re: [E-impact] Carbon aware routing Michael Welzl
- Re: [E-impact] Carbon aware routing Hesham ElBakoury
- [E-impact] Why carbon aware routing would break t… Rudolf van der Berg
- Re: [E-impact] Why carbon aware routing would bre… Dom Robinson
- Re: [E-impact] Why carbon aware routing would bre… Sébastien Rumley
- Re: [E-impact] Why carbon aware routing would bre… Rudolf van der Berg
- Re: [E-impact] {Spam?} Re: Why carbon aware routi… Romain Jacob
- [E-impact] Carbon aware network service pricing ?… Toerless Eckert
- Re: [E-impact] Why carbon aware routing would bre… Toerless Eckert
- Re: [E-impact] Why carbon aware routing would bre… Colby Barth
- Re: [E-impact] Why carbon aware routing would bre… Toerless Eckert
- Re: [E-impact] Why carbon aware routing ... Vesna Manojlovic
- Re: [E-impact] Why carbon aware routing ... Toerless Eckert
- Re: [E-impact] Why carbon aware routing ... Noa Zilberman
- Re: [E-impact] Why carbon aware routing would bre… Noa Zilberman
- Re: [E-impact] Why carbon aware routing would bre… Rudolf van der Berg
- Re: [E-impact] Why carbon aware routing would bre… Rudolf van der Berg
- Re: [E-impact] Why carbon aware routing would bre… Noa Zilberman