[spring] Re: Some comments on draft-liu-spring-sr-policy-energy-efficiency-04.txt
李金铭 <lijinming1836@163.com> Mon, 16 February 2026 10:51 UTC
Return-Path: <lijinming1836@163.com>
X-Original-To: spring@mail2.ietf.org
Delivered-To: spring@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 749FEB8426E6 for <spring@mail2.ietf.org>; Mon, 16 Feb 2026 02:51:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.843
X-Spam-Level:
X-Spam-Status: No, score=-1.843 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=163.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PiMdFgyn_Kv for <spring@mail2.ietf.org>; Mon, 16 Feb 2026 02:51:04 -0800 (PST)
Received: from m16.mail.163.com (m16.mail.163.com [117.135.210.5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id A83B6B8426C7 for <spring@ietf.org>; Mon, 16 Feb 2026 02:51:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:Message-Id:Content-Type:Mime-Version:Subject: Date:To; bh=0ckmVlhyH7Q35NzyyRhc/xEh+E+WqTfYbuaj3qXrpXU=; b=RR2+ Lg9M2ItwqrACD0xo6qILzciblv+zG5PKkIAuj6nF4qAFix/I5n7tm7TbTh3Qci+K cOnVYTUFOiqBxv1JS+Ad7K/EQwkv1qV2RMZB0WCmtPEe9Qz/JPV3kXNj78NW9KvH y6rZwPJ39v+QNL9lxlMIVKvlxPV/rTGGWp0jxno=
Received: from smtpclient.apple (unknown []) by gzsmtp4 (Coremail) with SMTP id PygvCgCHur2R9pJpd4CEPA--.7355S3; Mon, 16 Feb 2026 18:50:59 +0800 (CST)
From: 李金铭 <lijinming1836@163.com>
Message-Id: <4285F444-430C-439D-80F7-9A7C652D1343@163.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_21C9877B-B7B3-46D3-A079-1AC5A765E183"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.300.41.1.7\))
Date: Mon, 16 Feb 2026 18:50:47 +0800
In-Reply-To: <98ADD3DE-90D7-4DDE-A3FE-F469CA5A838F@tony.li>
To: Tony Li <tony.li@tony.li>
References: <177086026498.1610061.10563759991090294777@dt-datatracker-6bcfd44575-g5gjh> <98ADD3DE-90D7-4DDE-A3FE-F469CA5A838F@tony.li>
X-Mailer: Apple Mail (2.3864.300.41.1.7)
X-CM-TRANSID: PygvCgCHur2R9pJpd4CEPA--.7355S3
X-Coremail-Antispam: 1Uf129KBjvJXoWxAw1UCFyDur17Gw43Cr4DArb_yoW5Xw4DpF s5Gwn8KanrAFyxZ3ykZw4xWr1Sy3ykKr40vr13XFy3A390kFyYqF47tr4Yva4UAr15Aa4a vr4j9F4DC3WqyaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x0zMQ6JnUUUUU=
X-Originating-IP: [120.207.135.163]
X-CM-SenderInfo: polmx05plqwiqytwqiywtou0bp/xtbC9xPgommS9pNxlwAA3e
Message-ID-Hash: BVJOBJSFYHZDELYFDK4GTRXALAT3KOPR
X-Message-ID-Hash: BVJOBJSFYHZDELYFDK4GTRXALAT3KOPR
X-MailFrom: lijinming1836@163.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-spring.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: SPRING WG <spring@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [spring] Re: Some comments on draft-liu-spring-sr-policy-energy-efficiency-04.txt
List-Id: "Source Packet Routing in NetworkinG (SPRING)" <spring.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/60h0_0u2JWBJCN4wifVZMT_fJUw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Owner: <mailto:spring-owner@ietf.org>
List-Post: <mailto:spring@ietf.org>
List-Subscribe: <mailto:spring-join@ietf.org>
List-Unsubscribe: <mailto:spring-leave@ietf.org>
Hi Tony, Hope you’re doing well. Thank you very much for your comments and suggestions. Please excuse my delayed reply, as we are currently celebrating the Chinese New Year holiday. According to existing carbon accounting standards such as the GHG Protocol and ISO 14064/14067, when Company A evaluates the carbon emissions of leased operator dedicated lines, it typically relies on emission factors provided by communication service providers or industry databases. At present, operators usually disclose such emission factors through their ESG reports. While this approach is efficient, it is not sufficiently precise. We would like to propose a method that can assess the carbon emission level of a specific transmission path, as an alternative to the current enterprise dedicated line carbon emission evaluation approach. This method does not modify the existing SR network or PCE path computation behavior; it only calculates and returns the carbon emissions for each candidate path after the paths have been computed. For this draft, the items to be standardized include the required parameters and calculation method for carbon emission evaluation of a specific SR path. Regarding the comparison between a 1000-hop path with 95% energy efficiency and a 1-hop path with 90% energy efficiency: from a purely carbon emission perspective, a 1000-hop path using 100% green electricity is indeed better than a 1-hop path powered by 100% fossil fuels. Of course, such extreme cases are not realistic in practice. Looking forward to your feedback. Best regards, Jinming Li > 2026年2月15日 01:59,Tony Li <tony.li@tony.li> 写道: > > > Hi all, > > I would like to thank the authors for this work. I have several comments. > > First off, this draft does NOT seem to be SR specific. In fact, it would very much seem to be independent of the forwarding plane and thus could be generalized, resulting in a stronger contribution. This architecture need not be controller specific. This would apply equally to a PCE. > > Since this is really not SR specific, that strongly suggests that it actually belongs in TEAS, not in SPRING. > > Energy efficiency is not necessarily the only metric to be considered when performing a path computation. You can easily imagine a 1000 hop path where each hop is 95% efficient. Is that better than a single hop that is 90% efficient? Now, you’re probably thinking: how is this relevant, the details of the path computation are centralized, so does it need to be standardized? No, it does not. > > And that leads me to my final question: what problem are we solving here? > > Regards, > Tony > > > > > _______________________________________________ > spring mailing list -- spring@ietf.org > To unsubscribe send an email to spring-leave@ietf.org