Hi JinMing, > Setting max-metric on a port does not guarantee that no traffic traverses it.
In the topologies under discussion it surely does guarantee that. Traffic will traverse max-metric link only if no other path exists. So such cases are not of interest to the topic being discussed. Regards, Robert On Thu, Aug 27, 2026 at 10:04 AM JinMing LI <[email protected]> wrote: > 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]> <[email protected]> > Date 8/17/2026 08:57 > To <[email protected]> <[email protected]> > Cc <[email protected]>, > <[email protected]><[email protected]>, > <[email protected]><[email protected]> > <[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/ > > 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 > > 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] >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
