Hi JinMing, Thanks for your comments.
(1) add an overall solution flow, The overall flow is described in the TEAS document. (2) justify the necessity of the IGP extension, and IGP extensions enable distributed power aware path placement. (3) clarify the basis on which device components are put to sleep. You kind of answered your own question with, "Is the basis for sleeping or powering down an optical module simply that no TE traffic flows through it?” There are many ways to measure whether an interface is transmitting various kinds of traffic. Thanks, -- Colby From: JinMing LI <[email protected]> Date: Thursday, August 27, 2026 at 4:06 AM To: Christian Hopps <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: [Lsr] WG adoption call for draft-many-lsr-power-group-03 (Ends 2026-08-30) Hi authors, all, Thanks to the authors for the work. Energy saving in the network is a worthwhile direction. However, until the following concerns are clarified, I would prefer to keep this document as an individual submission rather than adopting it as a WG document. 1. How are convergence and oscillation from sleeping/wake-up transitions avoided? Per the document's definition, each time an adjacency enters or leaves the sleeping state, it is a link-state change that triggers LSP flooding and SPF recomputation. The community's primary concern with energy-aware routing has always been the routing oscillation caused by flooding of energy-related information. This document no longer advertises dynamic energy values, but it advertises a sleep state that can change at any time — the risk remains. From the current content, I do not see how this concern is addressed. Can the authors provide a stability analysis or simulation results? 2. Who decides that a component sleeps or wakes up? Neither document provides a solution. The TEAS document, Section 7, states: The algorithm used to recover sleeping bandwidth is beyond the scope of this document. The options seen on the mailing list so far are: the decision may come from the management plane, a platform API, or "a local application that monitors interface utilization and powers interfaces on/off as needed" — i.e., autonomous local decision by the device is treated as one of the legitimate options. From an operator's perspective, it is hard to accept a device autonomously powering down a link that is carrying production traffic. Whether a link can be powered down is a network-wide decision: are protection paths reserved, is busy-hour capacity sufficient, does the SLA permit it — none of which a single device can see from its local view. If devices power down links on their own, fault isolation and operational audit also lose clear boundaries. This leads to a dilemma: * If the decision is made by the management plane / controller, the controller can obtain all needed information via BGP-LS or telemetry — so why is IGP-wide flooding needed at all? * If the decision is made locally by the device, the above problems become unacceptable. Can the authors clarify which decision model the document targets, and why IGP is the correct mechanism to distribute such information? 3. On what basis are components put to sleep / powered down? Is the basis for sleeping or powering down an optical module simply that no TE traffic flows through it? What about non-TE traffic? We cannot focus only on TE traffic; arbitrarily powering down links would seriously degrade the experience of non-TE traffic users. Setting max-metric on a port does not guarantee that no traffic traverses it. The draft's stated approach — "move traffic off first, then power down"— only accounts for TE traffic. The draft provides no representation of non-TE / best-effort IP traffic, so there is no way to measure or verify that non-TE traffic has drained before the link is powered down. Reliance on max-metric alone neither guarantees drainage nor handles the single-path case, where it would black-hole non-TE traffic. The draft must specify the procedure and the verification for non-TE traffic, rather than leaving it to verbal hand-waving. In summary, my suggestion is that the document should (1) add an overall solution flow, (2) justify the necessity of the IGP extension, and (3) clarify the basis on which device components are put to sleep. Thanks, JinMing JinMing LI China Mobile +8618810926581 [email protected] BeiJing China ---- Replied Message ---- From Christian Hopps via Datatracker<[email protected]><mailto:[email protected]> Date 8/17/2026 08:57 To <[email protected]><mailto:[email protected]> Cc <[email protected]>,<mailto:[email protected]> <[email protected]>,<mailto:[email protected]> <[email protected]><mailto:[email protected]> Subject [Lsr] WG adoption call for draft-many-lsr-power-group-03 (Ends 2026-08-30) Hi Folks, This begins a 2 week WG Adoption Call for the following draft: https://datatracker.ietf.org/doc/draft-many-lsr-power-group/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-many-lsr-power-group/__;!!NpxR!iB3nF1jxaP1quqy92dXxhoRAuy57Gmo7IqTzUIGoExYez92B74dm_YkFqFawY7xB70l44TIxG_F526f9MYiWC88kDw$> Please indicate your support or objections by August 30th, 2026. An IPR declaration has been made https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-many-lsr-power-group<https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-many-lsr-power-group__;!!NpxR!iB3nF1jxaP1quqy92dXxhoRAuy57Gmo7IqTzUIGoExYez92B74dm_YkFqFawY7xB70l44TIxG_F526f9MYhUsibo2w$> Authors, please respond to the list indicating whether you are aware of any other IPR that applies to this draft. Thanks, Chris. [Call for adoption end date (2026-08-30)] _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
