Re: [E-impact] [OPSAWG] side meeting #119: Power Metrics: concrete usage example

"Rob Wilton (rwilton)" <rwilton@cisco.com> Wed, 27 March 2024 11:19 UTC

Return-Path: <rwilton@cisco.com>
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 EACE9C14F694 for <e-impact@ietfa.amsl.com>; Wed, 27 Mar 2024 04:19:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.592
X-Spam-Level:
X-Spam-Status: No, score=-9.592 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b="EZDUi5be"; dkim=pass (1024-bit key) header.d=cisco.com header.b="a27jzym2"
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 KI3YDC666dsK for <e-impact@ietfa.amsl.com>; Wed, 27 Mar 2024 04:19:17 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 410FCC14F614 for <e-impact@ietf.org>; Wed, 27 Mar 2024 04:19:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.com; i=@cisco.com; l=81202; q=dns/txt; s=iport; t=1711538357; x=1712747957; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=hYLhoGn/uNPYS5w5nLCgKcrqHR+sicIKnHUrGnVUNZ0=; b=EZDUi5bepiak4tjsVAPE3yoJf/CndFk4IcKYJrodvYNPPdBbXaqk6wq7 tcMsAfwuEr2a3C7ye10tQYzbCtdD8b3SoUGDVEWedodHkhFdYLAnqpiKW HvAaA3uM/JaGk3ioDUctxGVuoJSBX2Z7KW2qZt80KJi35JpSFlMrZE+sp c=;
X-CSE-ConnectionGUID: RCDYyKK+Sp2B4DFmdQljCw==
X-CSE-MsgGUID: 9ojLb2k1QfaGYtTNzBJWng==
X-IPAS-Result: A0AOAAAWAARmmIQNJK1aGgEBAQEBAQEBAQEDAQEBARIBAQEBAgIBAQEBZYEZAgEBAQELAYE1MSooegJRRkiEVYNMA4UtiGsDkUKGLYE4hgUDQg8FBwgBAQENAQEuAQUQBAEBhQYCFodvAiY3Bg4BAgICAQEBAQMCAwEBAQEBAQEBBgEBBQEBAQIBBwUUAQEBAQEBAQEeGQUOECeFbQ2GWQEBAQEDAQEMBAgJHQEBBxwCBwEKAQ8CAQYCDgMBAgEBASEBBgMCAgIkCxQDBggCBAENBQgTB4JeAYIXSAMBEJQLj08BgUACiih6gTKBAYIKAQEGBAWBT0GwaAmBSAGIJgGBUgIChB+CCoErgQgnG4FJRBKBA0KBZoECPoJWCwEBA4E0AQogFQkNCQiDHTmCL4IWgzeBDIFubYFZg0WBDIg+gVuDVYEYDWuGBVR4IgN9CARaDRsQHjcREBMNAwhuHQIxOgMFAwQyChIMCx8FEkIDQAZICwMCGgUDAwSBLwULGgIQGgYMKAMDEkkCEBQDOAMDBgMKMS5PQQxQA2cfMQk8DwwaAhsUDSQjAiw+AwkKEAIWAx0WBDIRCQsmAyoGNgISDAYGBlwgFgkEIwMIBANQAyBwEQMEGgQLB3aCAIE9BBNHEIEyihkMgzMpgU4pgRKDJwtDHgNEHUADC209NRQbBQQfAYEZBaJjPD0CAYFtFlQPLBAqMhEPASAvAQEGBAIJFSIoDAkEAQUgDxk8D5IuOAmDUIspR44Ek2GBIAqEE4wMglOTABeEBaVGZIgOkFQginWCXoh+OotcMASFHgIEAgQFAg8BAQaBUSkkgVtwFTuCZwlJGQ+OIBkfdgEJgkKFFIJmjWV4CzACAQMDAQoBAQMJiG4BJ4FSAQE
IronPort-PHdr: A9a23:qx7zkxFF/dq7eD3E5paFgZ1GfukY04WdBeZdwoAsh7QLdbys4NG4e kfe/v5qylTOWNaT5/FFjr/Ourv7ESwb4JmHuWwfapEESRIfiMsXkgBhSM6IAEH2NrjrOgQxH d9JUxlu+HToeVNNFpPGbkbJ6ma38SZUHxz+MQRvIeGgAJHTi9iw0ci5+obYZENDgz/uKb93J Q+9+B3YrdJewZM3MKszxxDV6ndJYLFQwmVlZBqfyh39/cy3upVk9kxt
IronPort-Data: A9a23:LL3h/q63Sou7cj4F1out6gxRtELHchMFZxGqfqrLsTDasY5as4F+v jQYUGuHaP+OZDSkKNona9zipkhTv8OHzoM2SgdqrSthZn8b8sCt6fZ1gavT04J+CuWZESqLO u1HMoGowPgcFyKa/lH1dOG58RGQ7InQLpLkEunIJyttcgFtTSYlmHpLlvUw6mJSqYDR7zil5 5Wq/KUzBHf/g2QoajlOtPrawP9SlK2aVA0w7wRWic9j5Dcyp1FNZLoDKKe4KWfPQ4U8NoZWk M6akdlVVkuAl/scIovNfoTTKyXmcZaOVeS6sUe6boD56vR0SoPe5Y5gXBYUQR8/ZzxkBLmdw v0V3XC7YV9B0qEhBI3xXjEAexySM5Gq95f9ClSOoO+wjHbeKVGw79trAHgyP6YHr7Mf7WFmr ZT0KRgEahSFwumx2r/+E7EqjcU4J86tN4Qa0p1i5WiGVrB9H9aaGOOTvoUwMDQY3qiiGd7Ee MsddT1pRB/BeBZIfFwQDfrSmc/y3iSlI2wJ8g/9Sawfsm/R6AYr0+HUPtP6S8C2Y9d/vHmeq TeTl4j+KkpHbIPEk2XtHmiXruKKnCbjUYkOPLy16vAsh0ecrlH/EzUfUV+95PK+kEP7AooZI E0P8S1opq83nKC2cjXjdyeTjE+VnT1fYMIKObEWxgSB867WyBnMUwDoUQV9QNAhscY3Qxkj2 VmIg87lCFRTXFu9Fyj1GlC882naBMQFEVLucxPoWufs3jUOiIg3ihSKRdF5Hevs1pv+GCr7x HaBqy1Wa1QvYSwjifnTEbPv2m7ESn31ougdvVq/soWNtVwRWWJdT9b0gWU3FN4ZRGpjcnGPv WIfh++V5/0UAJeGmUSlGbpURe32uKbbbmeB3zaD+qXNERzwqhZPmqgNsVlDyLtBba7ohBewO RCD51kNjHOtFCLwNPEfj32N5zQClvW4So+/CZg4n/JFY4N6c0ec7TpyaEuLl2Hrmw5ErE3ME cnzTCpYNl5DUf4P5GPvH481iOZ3rghgnjm7bc6gkHyaPU+2OST9pUEtagXeN4jULcqs/W3oz jqoH5HVm0wBC7egOnK/HEx6BQliEEXXzKve8qR/XuWCOQFhXmomDpfsLXkJIuSJQ4w9ej/0w 0yA
IronPort-HdrOrdr: A9a23:+ym+Da5Y3ULbsP4PDQPXwYeCI+orL9Y04lQ7vn2ZFiYlEfBwxv rPoB1E737JYW4qKQAdcLC7VJVpQRvnhOdICPoqTMeftWjdySSVxeRZnOnfKlLbalDDH4JmpM Bdmu1FeaPN5DtB/IjHCWuDYqodKbC8mcjC65a6vhNQpENRGt5dBmxCe36m+zhNNXN77O0CZe GhD6R81lydUEVSRP6WQlMCWO/OrcDKkpXJXT4qbiRM1CC+yRmTxPrfCRa34jcyOgkj/V4lyw f4uj28wp/mn+Cwyxfa2WOWxY9RgsHdxtxKA9HJotQJKx334zzYJLhJavmnhnQYseuv4FElnJ 3nuBE7Jfl+7HvXYyWcvQbt4Q/9yzwjgkWSimNwwEGT4/ARdghKT/aptrgpNScxLHBQ+u2U5Z g7ml5xcaAnVC8o0h6Nv+QgHCsa5XZc6UBS49L7yUYvELf3rNRq3NYiFIQ/KuZaIAvqrI8gC+ VgF8fa+bJfdk6bdWnQui11zMWrRWlbJGbNfqEugL3c79FtpgEz82IIgMgE2nsQ/pM0TJdJo+ zCL6RzjblLCssbd7h0CusNSda+TjWle2OBDEuCZVD8UK0XMXPErJD6pL0z+eGxYZQNiJ8/go 7IXl9UvXM7P0juFcqN1ptW9Q2lehTxYR39jsVFo5RpsLz1Q7TmdSWFVVA1isOl5+4SB8XKMs zDca6+w8WTW1cGNbw5qDEWAaMiXEX2ePdlzuoGZw==
X-Talos-CUID: 9a23:9ePpHWCbdRIG4ij6ExNM2H8FOeNmSWWH5iv8DUq0MGJrY6LAHA==
X-Talos-MUID: 9a23:v4AuagUx9j1eC/fq/G7rhhVobsQx2qqnJ3ERrbMUkeu7MyMlbg==
X-IronPort-Anti-Spam-Filtered: true
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-3.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Mar 2024 11:19:10 +0000
Received: from rcdn-opgw-2.cisco.com (rcdn-opgw-2.cisco.com [72.163.7.163]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 42RBJ9XQ029348 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <e-impact@ietf.org>; Wed, 27 Mar 2024 11:19:09 GMT
X-CSE-ConnectionGUID: 1Zu93UWHQNKnVyZtVYcnzQ==
X-CSE-MsgGUID: UxcJVfcXSwWSOldI1gqOgA==
Authentication-Results: rcdn-opgw-2.cisco.com; dkim=pass (signature verified) header.i=@cisco.com; spf=Pass smtp.mailfrom=rwilton@cisco.com; dmarc=pass (p=reject dis=none) d=cisco.com
X-IronPort-AV: E=Sophos;i="6.07,158,1708387200"; d="scan'208,217";a="11463564"
Received: from mail-dm6nam11lp2169.outbound.protection.outlook.com (HELO NAM11-DM6-obe.outbound.protection.outlook.com) ([104.47.57.169]) by rcdn-opgw-2.cisco.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Mar 2024 11:19:09 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Icz+gsdmBv/y6K/oJcpuJpUYSaRYsZuA5xmoyOkwM5Jbt1GCF1QZ4OcQh/Fu9440v9PuSg7lh6HzWT0vJPYV7J/F3kIv5YpbPsgy339uDDgNYriaqW0plv88KafjIW6VxFOZoCvxW/NmCWi0aDDm9M36iWOv4ruAeanqQ4vZ8HG59T5qIMPIPr8b0z5lVarSV6OOlifrqjdCZLDVbsEDtLQ5QxdiOhoR1G6vNP+CQ6g7Cc/f14I/GEmpgIEj7hRm9jU3cN2+fXUIkVwmvenWOH92cUFmn6u69TptDu4/gnTKLhw3rbrOa3ZFunzyH7VHRhb98MIp8pVKafMu22FMYg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hYLhoGn/uNPYS5w5nLCgKcrqHR+sicIKnHUrGnVUNZ0=; b=kqx0zmmqC1nnmke9Pjxo6q95fKvasc/FYwP7M8WF09fmkMOHkyevJM4EhAX5RXDKIZniErc0ylb3HgcFPgUuui/KNZwcO7k3z+tJJ3LCyvBF6U1G3dzHXEF2/IO1PfxHHky4qU0a/Q2BjRAj+NqY+qf4/nvnSraWMF3UOUNjzU+524BdIKgJIVDmc72ZBNLiceQH737/yv0qvYI1tzfhLpoZnn0hTRURC6QeoAeop8VT5j6oT3gTNAIArq4v9Tcz4zaf/t9n5la7bBGIJy7tlI8BGaPTSBUo24R9fouj3WwZnp3L10YKMTRrj8wDB8n5EkLWhjPHPnDEfaxVP2AxFg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hYLhoGn/uNPYS5w5nLCgKcrqHR+sicIKnHUrGnVUNZ0=; b=a27jzym2GJ7+MnCGg8FKYiRlNGYHJnWE2yBCXM0I5tK7STmkHfh3S2bLD+a77amFnTtB16y9SemIpUKU+ettUr4ljlvdHLMFfFQ9eK5NW0fHfJZRxApT88mj8bZ2WxHmc0D8cTDCyULFcNvSs8QXakGIiNDz8SNC5epfATOMR8E=
Received: from LV8PR11MB8536.namprd11.prod.outlook.com (2603:10b6:408:1ec::19) by BL3PR11MB6362.namprd11.prod.outlook.com (2603:10b6:208:3b5::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7409.33; Wed, 27 Mar 2024 11:19:07 +0000
Received: from LV8PR11MB8536.namprd11.prod.outlook.com ([fe80::dae8:c4e2:9d09:1d9]) by LV8PR11MB8536.namprd11.prod.outlook.com ([fe80::dae8:c4e2:9d09:1d9%7]) with mapi id 15.20.7409.031; Wed, 27 Mar 2024 11:19:06 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: Michael Welzl <michawe@ifi.uio.no>, Dom Robinson <dom@id3as.co.uk>
CC: Dirk Trossen <dirk.trossen@huawei.com>, George Michaelson <ggm@algebras.org>, E-Impact IETF <e-impact@ietf.org>
Thread-Topic: [E-impact] [OPSAWG] side meeting #119: Power Metrics: concrete usage example
Thread-Index: AQHadvvqrcvTSD5xYUatEf2bcshhf7FIafUAgAAgkLCAAHj5AIAALp9JgAArOICAAD1ngIAAKg2AgAAg8gCAAAG9gIAAAGuAgAAHFQCAACounw==
Date: Wed, 27 Mar 2024 11:19:06 +0000
Message-ID: <LV8PR11MB8536590F9C9EB518A9F62A89B5352@LV8PR11MB8536.namprd11.prod.outlook.com>
References: <CAKr6gn3Ze0FrskGYouRjP+yRTG7Ts60EPy-LveHOXVRFBXNPew@mail.gmail.com> <6E972713-CA73-4D61-AF02-B83E59CCF8AD@id3as.co.uk> <9d3f52c06a274680a0762d65baa1308b@huawei.com> <3BB20F26-CC7B-4467-8C89-3622A08347B6@id3as.co.uk> <f279b87f5a394657a5285e8f914baf0b@huawei.com> <A26397BE-A568-4A40-8897-611BC18B91E7@id3as.co.uk> <CC2DF697-19ED-4FE5-9A22-EB16630E373C@ifi.uio.no>
In-Reply-To: <CC2DF697-19ED-4FE5-9A22-EB16630E373C@ifi.uio.no>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: LV8PR11MB8536:EE_|BL3PR11MB6362:EE_
x-ms-office365-filtering-correlation-id: c7c425b9-1de2-404d-5097-08dc4e4fb798
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 8j6+txIr2KdW4RlLCV5qcUasdKb9XbZ3NfIhDkSkPKag6gwI5TMK302/D8Or0FK5xtIPOIFYXGdKm481CNUN3IC+fcJfmmjBZ0tBZjiY/+aKMZbWR5dTrIEN3Q4MR/lwrUJJxZnlMqgTGWhXa92Zy7gROTPVjH33vv3Ik0t0RGk8JmwmICOn6aoeoXVN9gx3NExjxUmGwnH7QRFduWj1Gw/eN0DshU5rvr2lS9WO12quS7S7NKBDNV8j5sMlsIsGPCQcuSPOZ6MXlDcPgk1uMfCgXr2OBAj44ZlSaewAJirjvNDckpgXoBObEpesHv6o8Yw1E5o0WDnR2Iy6A63vj+Ox/AJYfcdn4lmKr+19qayjbXukv9PWzjOrq//y4bFPxd2AFaC1h4EWwdEHTwe1RORHS5SBoMECeGXzOMqUcWTLa3lH3uN1GEqVuYDudRItAQomTZF33j9hYpNg08DmjUjxSGdClxdf5jrbQz0r+WikElnqzJiaam2k+Em17b+AOSocszvciR40t3a+ST3WDfYlrqnVgyVNrugqwWePgZpcI5gRphTxR6nK2H94XiBYbEGFO+G62BRBg7IHTvrBq+Lash7EidXj2aNoVG5pvQkPlb1D6QINOLPU1ImPurd3Rb9Xc2bGOYphEns2xKoC5h1BtwSkiu4IxsBd/FVibosR8PfkPdGicTBBLpticdut
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LV8PR11MB8536.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230031)(1800799015)(366007)(376005)(38070700009); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: jxAq9kOMqIzFf5qxgfopilI8WKT05tY/IVHvqFK9C895dokdgQQCzJ187g0Tgg3VFPCRTk6uO5CaGCp0wrM5WKajr4OYEQpnPojFlL0us/DFk/P1fKz4cB2TGG68F1I7pJf0dM7H9Ztt3wIUh1Z8Jk8BYwDNcjbD3FX9CwV85M9QXsODwHyi3hTdFVZYW/NLvgz8NQ9LTknMzFXUAFRMy9U4oHh+GYNwVMQsEsZqpasF+0+CxYfaeWleFJOzKZ2Ecvhz9cWPDHJx1R97XfEYTO/UFq8lmotuJ3buwF3spEm21VRocNeIUvq0FcreYDwWbEOYtkme9D96OBZ7WLEhuWRagMDIunsZeczqe1Zm610/GvxtAhC7yZnkUGaXIlz4ouQB3SlfKJFS9nVrjy6tqJ+OEBcg+e6WcLeKcGiaPP43J4jdSGZHS/0uejFREr+gzxQiSh7sjWp9JMib//5hIW+BweI+3PPL82mBH55YWZEWo8pHbvOmVkwmv5NBQK75nUb5vuaV+TyjwjrFk47VxBS6BjN/OBeE8v90wlZPtZwFR1FE3mHGnrTs0yL2TJJXhCkVFW8mb0pA647KiWIwdtuMNB58PhRPciGTtIT6Efpiwza618XFpbH6pedBF32KyUK/bKqR0TYJaN3psyIjvclOMP9nRGo09IctDQdiz9gkyWlL1gftBVSjW/OwjEGxbcZhzF1AV26oMUS1juJOeofMrc4hBef4EOf1RCDHxbiyO1kETHNExYXLRvI/Xfa5TgaCIwXIArqifi+ShzmatLJfbs3eBeGXEDioYob8c8scoWjgYz54jTX6bXofWdm4b76AHGP5i525nApPnuK0iS1Jt1/PUjYDXj2mewNvgrB2v0b5/j4mtj4A04E4SbaJyV3PujDaCH0mRHT6L+AIcJJlfT+Rc/DVNGugwCf3Ud9oQudYc1HDdYp3GaA//k+2iyivPmFl+r2m7p37qm+jYlezS6SweFSfvPeJFHAoAdH16LE0yJRFNIiiCc2SBS8BX43iEtk6MPUS7HQfeon4rVjU0A+nFuDWWLJDSb7yB1qeOqKN9gmBQaKQAxF2jbG6ryvkh3OAnBO/ZjHFWTyfqFm0Is+AFGmB+9FXyzARzuzAUC80x08fpz6p9w2yxPvUTZVDQl9MDyY5XGB31s1lqEfNc/Pnyn5pg0BMfpN04lrOdqtaj3+RSDtDkXxnV8p2AyLgQ727kgldpM+b4IjY8i5oqsd6gfquiC5Z6Uh6IHw4dANq5N/FZwSEtOR3bkvTcukeS6L8+taZDF/5II5FnhXC1Cw253ohl09DX2TnyEms/7K44gzZAan/qOYh+YFllgHtpF1B9edaKUa4226lFk4PLdWN701cT0gcgn5ufUmJe0vXnpFUBuw70Us/Byr/wUXsAHD9iLHFFgCyF7QDcIYlL3X598/wYJmtCLUjBgQCtvB6jReLatVGEs6rU/GJwiR2WH5XkbxsGRUS5Qf9/6zbtxkfxdndhbUoH/Jyr6Z4IDnHRH99EUrv4MsTIVbH2vNWIq12QqcFyXA4Q1xA+hRKknR6UvVDFL7CToECE18Rg1KrWFzqUS4ow0ddbGOf
Content-Type: multipart/alternative; boundary="_000_LV8PR11MB8536590F9C9EB518A9F62A89B5352LV8PR11MB8536namp_"
MIME-Version: 1.0
X-OriginatorOrg: cisco.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: LV8PR11MB8536.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c7c425b9-1de2-404d-5097-08dc4e4fb798
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2024 11:19:06.9105 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: uwYRtUdfzrMAbGzE7VD78qr3khN0aK8hRm6WYaHSJFPqP3ABbQyvAsujNSr2rRtAOVd6O7Z8jVXXbIGxKwvVQg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL3PR11MB6362
X-Outbound-SMTP-Client: 72.163.7.163, rcdn-opgw-2.cisco.com
X-Outbound-Node: alln-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/e-impact/_Iz9kQR8w2-YVi1Iv_MDYvIMXOY>
Subject: Re: [E-impact] [OPSAWG] side meeting #119: Power Metrics: concrete usage example
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: Wed, 27 Mar 2024 11:19:22 -0000

HI Michael, others,

There are various comments on this thread saying that it is too early to modify routing algorithms for energy efficiency and I would say that I broadly agree.  In fact, I’m not entirely sure whether solving this in the routing plane makes practical sense at all due to the complexity involved, but certainly if it does it is a far more complicate solution that needs more discussion before anything useful can be standardized.  I see this topic as being perfect for discussion within the e-Impact program within the IAB.

In terms of an IETF WG, what is being proposed for short term standardization with the IETF is a simple YANG configuration model for turning on/off parts of the device when they don’t need to be used (e.g., as a starting idea, perhaps see draft-li-ivy-power-01 - A YANG model for Power Management (ietf.org)<https://datatracker.ietf.org/doc/draft-li-ivy-power/>, by Tony Li and Ron Bonica).  Many networks that use traffic engineering or a configuration controller based architecture could make use of these data models, along with operational data models that report current energy usage of components, to optimize the energy usage of their networks by draining certain links or linecards and then powering them off when the overall load on the network is lower.  I see this as being directly analogous to mobile providers who are reducing some of their radio capability at night when the demand on their network is much lower to reduce energy consumption.

If we do ever get to trying to solve some of this in the routing plane, then I believe that both metrics on actual energy being consumed, and the ability to depower links, forwarding ASICs, linecards, fabric planes, and entire chassis, would be a key component to such as solution.  I.e., the proposed work that we are aiming to do now would seem to be required foundation steps for this future work anyway.  And to be clear, personally, I think that if we try and optimize traffic away from devices without the ability to turn off components, or put them into a lower power state, then we would end up with a much more complicated solution achieving only minimal energy savings, because as has been widely reported on the e-impact list many network devices have a high base load, with a much smaller proportion of overall power being directly related to actual traffic load.  For me, the most interesting aspect of this is how to depower elements of the system whilst still keeping sufficient knowledge of their existence in the routing state, being able to bring components back ready into a forwarding state quickly (before they are actually needed), and how to maintain sufficient redundancy in the network.  I believe that similar topics are probably being discussed in the TVR WG.

But for the moment, the aim of the new WG within the IETF is to standardize what can be clearly scoped and where the problem and rough solution are already well understood.  I don’t believe that it should impact the scope, or usefulness of the e-Impact IAB program in anyway, I think that it can, and should be, entirely complementary.

Regards,
Rob


From: E-impact <e-impact-bounces@ietf.org> on behalf of Michael Welzl <michawe@ifi.uio.no>
Date: Tuesday, 26 March 2024 at 11:13
To: Dom Robinson <dom@id3as.co.uk>
Cc: Dirk Trossen <dirk.trossen@huawei.com>, George Michaelson <ggm@algebras.org>, E-Impact IETF <e-impact@ietf.org>
Subject: Re: [E-impact] [OPSAWG] side meeting #119: Power Metrics: concrete usage example
Hi everyone!

Many good points here. Just to bring one more view to the table:

I agree with George that it’s hard to see the actual "protocol work” that would help - but I think that this may just be because we’re used to think of algorithmic solutions.

E.g., what routing strategy is “better” - based on energy? based on carbon efficiency? based on a mix between these and “traditional” metrics?  (well of course - e.g. shortest path will never cease to be important, but how to mix these?)   People have already come up with example cases where these metrics *can* be useful. But how useful are they really, and how realistic is it to apply them at a larger scale? WOULD a larger scale be what we should aim for, or is this inherently limited-scope stuff?

It doesn’t seem like we have overall answers to these questions, and I don’t think we can expect to find them anytime soon; and should *we*, as engineers? Hesham has pointed at sociology and marketing; Rudolf has pointed at economics.

Concluding from all this, it seems to me that useful work can already be done in the IETF to *instrument* protocols to provide, or enable use of, sustainability-related information (at least energy, but perhaps also carbon efficiency or some such metric if we do have hope to come up with a useful definition…).  I.e., define a routing metric; offer management information (see the proposed YANG model and ICMP extension);  ... and then it would be up to others to see what they can do with it.

Here’s another way of looking at this: if we don’t instrument protocols with such information, nobody can even try to deploy any strategy because the tools are just not available - and nothing will happen.

So, IMO, such “instrumentation” work should indeed happen in the IETF, soon - and in addition, we should keep having this mailing list to inform the discussion on how the newly offered instruments could be brought to good use.

Cheers,
Michael



On Mar 26, 2024, at 11:46 AM, Dom Robinson <dom@id3as.co.uk> wrote:

100%
--
Dom Robinson
www.id3as.co.uk<http://www.id3as.co.uk/>
www.greeningofstreaming.org<http://www.greeningofstreaming.org/>
uk.linkedin.com/in/domrobinson<http://uk.linkedin.com/in/domrobinson>
Meet >> https://calendly.com/id3as


On 26 Mar 2024, at 10:45, Dirk Trossen <dirk.trossen@huawei.com> wrote:

Dom,

Yes, it is a slippery slope from dumb to aware to (artificially) intelligent 😉

But given that constraint-based routing already represents awareness (e.g., to latency), adding energy in a limited scope is not a big slide down that slope IMO. And we may find other opportunities on the dry end of that slope before slippery kicks in.

The reason for having this discussion in an engineering forum is to get the balance of views right between the crazy desires and the actual working things.

Dirk

From: Dom Robinson <dom@id3as.co.uk>
Sent: 26 March 2024 11:39
To: Dirk Trossen <dirk.trossen@huawei.com>
Cc: George Michaelson <ggm@algebras.org>; E-Impact IETF <e-impact@ietf.org>
Subject: Re: [E-impact] [OPSAWG] side meeting #119: Power Metrics: concrete usage example

Dirk

So I agree on being careful about the scope of energy considerations in protocol design (to avoid feature creep, to avoid raising new security considerations) but I cannot agree that it is not potentially substantive protocol work for the IETF.

More good points: better made than my own!

I stand by giving the whole idea of giving the seemingly inexorable merge of energy operations with IP (as far as this group is concerned) a solid kick-test. Without that check and balance i do fear an unending scope creep in trying to bring ever-deeper decisioning / awareness into the routing layer.

"Dumb-networks" have proven very successful for a long while and while it’s tempting to add (A)intelligence to everything these days it may take us toward using a particle accelerator to crack a nut :)

But i happily cede to the points you make about prior form for such ‘awareness' already being present as far as traffic flow is concerned.



--
Dom Robinson
www.id3as.co.uk<http://www.id3as.co.uk/>
www.greeningofstreaming.org<http://www.greeningofstreaming.org/>
uk.linkedin.com/in/domrobinson<http://uk.linkedin.com/in/domrobinson>
Meet >> https://calendly.com/id3as

On 26 Mar 2024, at 08:41, Dirk Trossen <dirk.trossen@huawei.com<mailto:dirk.trossen@huawei.com>> wrote:

Dom, all,

Chiming in here as a passive observer so far on this list.

When you say: “But should a data routing protocol confuse its purpose by routing based on its own ‘awareness’ of energy? I think that adds a burden to IP that would weaken it and be out of scope.” I wonder why you limit the scope of IP routing constraints (which do exist, right?) to NOT consider energy?

Why is it that we cannot envision energy costs associated to links in the same manner we assign latency budgets to select one path over another? If one considers multi-constraint routing work (see https://www.semanticscholar.org/paper/Routing-on-Multiple-Optimality-Criteria-Sobrinho-Ferreira/8ce4650878576839d61d0be35a364e019c18318b for what is hopefully working as a non-paywall reference), even multiple constraints in combination with latency or bandwidth are foreseeable IMO.

When you say: “l3 routing should be routing, and not try to scope creep into application / infrastructure. It should stick to the end to end principle and leave the ends to decide on energy actions, while facilitating the data exchange.”, it confuses me since I was under the impression that routing is exactly about infrastructure, while it is also about application requirements (highest BW or lowest latency, or maybe even lowest energy) to make the right data exchange decisions.

An example of work in the IETF, where we can see (down the line) an active consideration of energy is that of traffic steering, i.e., the selection of one of possibly several choices of network locations where traffic could go to. If you see several (e.g., virtualized) instances of a service residing at those different network locations, picking the ‘best’ of the choices is key here. Isn’t it a good thought to consider energy as a possible ‘best’ choice here?

The CATS WG is one such body of work in the IETF right now. Its very name limits it to ‘compute-awareness’ but isn’t the energy consumption of compute endpoints not one such possible awareness metric? Of course, works like CATS but also ALTO need to work out the signaling of such application/service metrics to network nodes to act upon them, but that’s (in part) why those WGs exist.

So I agree on being careful about the scope of energy considerations in protocol design (to avoid feature creep, to avoid raising new security considerations) but I cannot agree that it is not potentially substantive protocol work for the IETF.

Best,

Dirk

From: E-impact <e-impact-bounces@ietf.org<mailto:e-impact-bounces@ietf.org>> On Behalf Of Dom Robinson
Sent: 26 March 2024 07:11
To: George Michaelson <ggm@algebras.org<mailto:ggm@algebras.org>>
Cc: E-Impact IETF <e-impact@ietf.org<mailto:e-impact@ietf.org>>
Subject: Re: [E-impact] [OPSAWG] side meeting #119: Power Metrics: concrete usage example

George - you make some good points very well.

I am simply unconvinced there is substantive
protocol work in energy burden to be done in IETF protocol space at
this time.


I have to say I agree.

As an influencing discussion, e-impact is hugely valuable.

As an intermediary between layers 1/2 and layer 4 (where all the energy is consumed) IP can already carry information (as an ‘application’) that leads to energy saving infrastructure and workload management. In this regard it already does the job perfectly!

But should a data routing protocol confuse its purpose by routing based on its own ‘awareness’ of energy? I think that adds a burden to IP that would weaken it and be out of scope.

It risks becoming ‘for the sake of it’ rather than because it is really improving the protocol IMHO.

I think better to continue to focus on how the physical layers and link layers are efficient, and the application layer has information to steer decisions.

l3 routing should be routing, and not try to scope creep into application / infrastructure. It should stick to the end to end principle and leave the ends to decide on energy actions, while facilitating the data exchange.

IPs role is hugely important, but it needs to remain benign else it will become a political tool. Energy information becoming a component of routing data looks like a cyberattack waiting to happen to me.

BGP tables going wrong causes chaos, but generally ‘only’ impact data access. A DDoS attack on our energy using IP networks could cause real-world problems with much deeper consequences than ‘some data loss’.



--
Dom Robinson
www.id3as.co.uk<http://www.id3as.co.uk/>
www.greeningofstreaming.org<http://www.greeningofstreaming.org/>
uk.linkedin.com/in/domrobinson<http://uk.linkedin.com/in/domrobinson>
Meet >> https://calendly.com/id3as


On 26 Mar 2024, at 02:31, George Michaelson <ggm@algebras.org<mailto:ggm@algebras.org>> wrote:
Without wanting to push too hard, I would personally push back on
E-impact becoming a WG or having any solidity beyond an experimental
ongoing activity. I am simply unconvinced there is substantive
protocol work in energy burden to be done in IETF protocol space at
this time.

* I absolutely believe there is an energy impact issue in DC, in long
distance communications and maintenance of RF carrier, for the IEEE,
for 3GPP, for economies with unreliable power facing the question to
house a CDN or long-line it to somewhere else. These problems lie in
other people's standards bodies.

* I absolutely do believe we can theorise physical and link layer
protocol changes which reduce energy burdens (in many cases with cost,
like no 0RTT responses because we have to re-establish link) -And that
things like delay tolerant networking or 6LOWPAN go into this space
sometimes.

* I also absolutely do believe there may in future be clearer drive to
do work on energy in IETF, in protocol design for DC or other contexts
where it has to be exposed through the protocol stack to the
application. Therefore I can say there COULD be work to be done here,
in the future.

About as far as I would go right now is a problem statement. And, a
watch-and-review status.

I'm not in charge here and I don't have some magic veto card. If
people wanted to continue, I wouldn't oppose a list being hosted, but
I would be uncomfortable with positions being taken in public implying
the IETF or the IAB have substantive work to do here: I don't see it.

Maybe the IAB differs.

-G

--
E-impact mailing list
E-impact@ietf.org<mailto:E-impact@ietf.org>
https://www.ietf.org/mailman/listinfo/e-impact

--
E-impact mailing list
E-impact@ietf.org
https://www.ietf.org/mailman/listinfo/e-impact