[Green] Re: [Lsr] Re: Adoption of draft-many-lsr-power-group

Tony Li <tony.li@tony.li> Mon, 24 August 2026 23:52 UTC

Return-Path: <tony1athome@gmail.com>
X-Original-To: green@mail2.ietf.org
Delivered-To: green@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 349C612EC75DD for <green@mail2.ietf.org>; Mon, 24 Aug 2026 16:52:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1787615568; bh=i5hXASxu/WOW+DIXpcY8uy//kU7TJMA/mCGY2QIIVgo=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=nQ7cLAoVeHQXtyWhII7sJ9EDNcgw12lnnyUg3TDWEo1noe6Jzy7To0zGhS4Qdkyjx Xw98t5F50xyDLOSJ+PAyqLK222tvYt1REn2cRJYPmkUDpKx4Bzs0qUQr7S5Wx27s7X wgR7rx1IKXAP21ndRID72NyrLFNlFJ3uCVetMIF4=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 95Os_JxdqWhU for <green@mail2.ietf.org>; Mon, 24 Aug 2026 16:52:47 -0700 (PDT)
Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 8852D12EC75BF for <green@ietf.org>; Mon, 24 Aug 2026 16:52:47 -0700 (PDT)
Received: by mail-pf1-x433.google.com with SMTP id d2e1a72fcca58-848643382fcso4265943b3a.1 for <green@ietf.org>; Mon, 24 Aug 2026 16:52:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787615561; x=1788220361; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:content-type :message-id:from:sender:from:to:cc:subject:date:message-id:reply-to :content-type; bh=HESx5gGfNZXpQmlzasQ24oc+F+bA7NBbSw3JNTdyVPs=; b=ir18jFu/cRixVa+dIxnkgKjlJAv3PVPLaygunb9PYlOq6H9CDlYqzL/Sq0Rw1GFjHU bMc10w7IJ3NdKMU12klpfwvZD7stoqfIWmV6osezKCJamoMFUTjaAET/caP41X/xs+qE ntJcUNcTf3QJT1TmBDD0W6BVPoX+U0tUBIwn9U9qbm6DYU4bVwe8KBf393/8BAlFnvnr m9i9eQu+1QX8w5PjWRRH3G2v1urmsSfu7mrAuxeaI4Q42lM1BaPcJRAYBEPRmL+Gm1W9 75ctTErQ/ZTE2PPsZ27fGcaGy2FkvAJyNSZcM97hanFV10oKM0SLYYymDjeOtBUEgL6p 5cCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787615561; x=1788220361; h=references:to:cc:in-reply-to:date:subject:mime-version:content-type :message-id:from:sender:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=HESx5gGfNZXpQmlzasQ24oc+F+bA7NBbSw3JNTdyVPs=; b=jELweg2yMD2cOPw00D5VbTEvT4+DynSJhFXjxO0HE0YHlZROg64Mm2M4QZq48oGLqn bOtDvoewcrJQLFR0RAkj1EujWbW29y6smkUfDRCHE5rDUpTp8Beb1xcbQXeLojHRhU/i aOKJwABJIVG0llEp3EQb1G2iP8p5eLSD0hhby+bRfEOa8HRNJpFsUaCAv8YhThkyJL9S sb4PF7/edj+twV/J6DWEO0Qvce5S2amAH7OXQ8pKzSNjINy3N8Xvb7l6hdww0MfkNjB/ vcbA3/sNvGzTfj/N9Xds0jgq7hMtvVQQf2TQ1/5M3i+REIR1VPqmJZ9+F5y+A8rZSzIs AR8w==
X-Forwarded-Encrypted: i=1; AHgh+RrGRiwoCjMaD4nnw36ViixllYxsx/27rxQXC/CuE+WHUNK7X9hmaPwuY3yzekxoewO38T6dPA==@ietf.org
X-Gm-Message-State: AFuF++mdbUMwJ0ikf7Drp7vv011bii/CYuIvgR0bX8eXSA2lE8GU1koT CXwdd/hn4NL97cSYmbDl3WAhcqNYOZMlgfOYwy7mtVtzqHC3a3SjPEIM
X-Gm-Gg: AR+sD116wYi+RgXb0JJBwnOu5ptBquQd8U6W5uWvdJOtxxijYWMd+jDr7rpFrd6m5fb 3T9fCi8iTaS930t+QEFEfc6/5FOotMEH264ZdiOjVVyv0efGKe7EMd866c/H0wf/WUmIJxEr5uW tfoCGyCW/8njpWAbGwdqrbYJ4z/JNcncT9ckr27ODdN8AnQZR0cPm1FBQMVRIOgHfMtuZVZ84DB 3KtnImfYaHqni7CgxjnIDuVKAnoNga5FY+gpcY59HuB/vkW6IaP/QMaNHiyWhDOQULERa1FIhhW 9dclHHk0xFTThcgfxsHIiOjy+JxjrUlyfsUHR85mr06M40933BFyr4dNTeNoFbRQC76VDp455UY zn/jfuTCbyS8HG1NoK31Wi7DVEa2I8EwdoLuv69AgRNwRRIFCPUTk6tUVO/6X43eP3trpUh6mtV EOX/Xr3nmXZgnbDpNJPRsB2rGBUt95KvtlP5d83W6oIu1HCt35zxIu8IuZSgXH54PKs+sLjlafk WguJX+fbBIRw/fut+RRULwmay9wUVvhuy+MWg==
X-Received: by 2002:a05:6a21:3a83:b0:3c3:8d86:9855 with SMTP id adf61e73a8af0-3cd2fea6532mr56364687637.7.1787615560625; Mon, 24 Aug 2026 16:52:40 -0700 (PDT)
Received: from smtpclient.apple (c-73-93-167-4.hsd1.ca.comcast.net. [73.93.167.4]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-327f909c6c9sm34732553eec.6.2026.08.24.16.52.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Aug 2026 16:52:40 -0700 (PDT)
Sender: Tony Li <tony1athome@gmail.com>
From: Tony Li <tony.li@tony.li>
Message-Id: <35E69EA0-AEC2-40E6-B199-FC99000BF91B@tony.li>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F6162519-3F09-4DA4-A766-2FA85832C136"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\))
Date: Mon, 24 Aug 2026 16:52:28 -0700
In-Reply-To: <26483686-55b4-4ffd-aed4-9156ff055c39@everything-ops.net>
To: "Benoit@everything-ops.net" <benoit@everything-ops.net>
References: <DM4PR11MB5971D68AB69D5E98DA1B52D8C1C32@DM4PR11MB5971.namprd11.prod.outlook.com> <9819F39D-17D1-4979-A98A-BBF574229EDB@chopps.org> <CAMj-N0+jkDJpVFTJ7BtAkcsXAx2sy5iRD9ZL7HaaRP=cHH09tQ@mail.gmail.com> <CABF896F-28AB-4BDF-8787-DA831A823C65@gmail.com> <AS1PR07MB8589445E1EB905EA8A6FB34DE0A72@AS1PR07MB8589.eurprd07.prod.outlook.com> <51A4E870-F7E2-4E03-8FB9-06A9604E88D9@gmail.com> <AS1PR07MB85899DC89108DA6139E1D2C5E0A62@AS1PR07MB8589.eurprd07.prod.outlook.com> <CAMoPOhms85YG8Vd1cBq2Q-U3-OAE4==-Vxt9xPEKPPz3VPSQpg@mail.gmail.com> <CAO+xseks0pNQ1UaiAyA0WyqDPdYTiWp+wKEQoCPoMdJZzN7rzw@mail.gmail.com> <ca9faef8-8161-4728-a9ea-339dd6e3da02@everything-ops.net> <5F602DA7-1DAF-4D08-9990-75B158711EC3@tony.li> <26483686-55b4-4ffd-aed4-9156ff055c39@everything-ops.net>
X-Mailer: Apple Mail (2.3864.600.51.1.1)
Message-ID-Hash: JWOXZNXDBJF7X5Y5S5CVGHSZEF4ZPI4B
X-Message-ID-Hash: JWOXZNXDBJF7X5Y5S5CVGHSZEF4ZPI4B
X-MailFrom: tony1athome@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Marisol <marisol.ietf@gmail.com>, Vishnu Pavan Beeram <vishnupavan.ietf@gmail.com>, "Gunter van de Velde (Nokia)" <gunter.van_de_velde@nokia.com>, Acee Lindem <acee.ietf@gmail.com>, TEAS WG Chairs <teas-chairs@ietf.org>, Christian Hopps <chopps@chopps.org>, "\"“lsr-ads@ietf.org”\"" <lsr-ads@ietf.org>, Les Ginsberg <ginsberg@cisco.com>, lsr-chairs <lsr-chairs@ietf.org>, lsr <lsr@ietf.org>, Getting Ready for Energy-Efficient Networking Discussion List <green@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Green] Re: [Lsr] Re: Adoption of draft-many-lsr-power-group
List-Id: Getting Ready for Energy-Efficient Networking WG <green.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/green/_2Bm_wmAz851Rk7AJBkoTGRMTWM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/green>
List-Help: <mailto:green-request@ietf.org?subject=help>
List-Owner: <mailto:green-owner@ietf.org>
List-Post: <mailto:green@ietf.org>
List-Subscribe: <mailto:green-join@ietf.org>
List-Unsubscribe: <mailto:green-leave@ietf.org>

Hi Benoit,


>> There is no tracking of interfaces in power-state-off, nor of interfaces that are power-state-on but have not formed an adjacency.  There is no tracking of power state of higher levels of hardware.  Presumably when all relevant interfaces are sleeping, the platform can put higher level hardware to sleep.  Once again, we are not trying to perform management plane functions, only control plane traffic engineering. 
> You know, this is exactly my point. And I have seen this pattern in the past. "It's just routing, not mgmt, so we don't care"


That’s grossly unfair.  We do care. But we also have other requirements.  We are proposing to carry this information in the IGP, as we have done for TE information for 30 years.  However, the IGP is not a limitless storage system.  In fact, it has a very finite capacity and the more that we add to it, the more it degrades IGP performance.  We are carrying the information that we need in the IGP to do routing’s job.  We have no objection to the GREEN YANG model and support that effort, but carrying YANG in the IGP does not make sense.


> Operators don't manage the control plane or the management plane (or the data plance) independently..
> They look at all planes (mgmt, control, data) for troubleshooting, anomaly detection, and assurance. See the NMOP "sharing your incidents" sessions.
> And yes, we could map, as an example, a BGP Flowspect Type 1 - Destination Prefix <https://www.rfc-editor.org/info/rfc8955/#name-type-1-destination-prefix> to destinationIPv4Prefix ... oh wait, maybe this is destinationIPv6Prefix?
> Explained differntly, here is the issue we face in operations: "Network Automation: the costly Data Models Integration and Mediation <https://www.claise.be/network-automation-and-the-costly-data-model-integration-mediation/>"


This may surprise you, but I do understand that.  I do have some history as a network operator (USC, Los Nettos, NTT).


> I really would like to understand (see described somewhere) how an operator would use the LSR power groups, optimize routing, and use the YANG module power state at the same time. To me, this would be a prerequisite before adopting. 


Please see draft-many-teas-power-steering.


> Btw, a specific operator told me: config management is so complex, with many frozen windows, that I will not allow energy-related configuration independently.


No one is proposing that.  All configuration changes are all part of normal system configuration.

Tony