FYI ----- Forwarded Message ----- From: John Drake <[email protected]>To: 'Tony Li' <[email protected]>; Aijun Wang <[email protected]>Cc: 'Vishnu Pavan Beeram' <[email protected]>; 'Oscar de Dios' <[email protected]>; 'TEAS WG' <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>Sent: Wednesday, September 2, 2026 at 05:42:19 AM PDTSubject: Re: [Teas] Re: Call for adoption: draft-many-teas-power-steering-01 (Ends 2026-09-10) Hi, Generally, a network is provisioned in a centralized fashion using the global [source, destination] traffic matrix and then applications, both TE and non-TE, make use of the resultant topology. If the global[source, destination] traffic matrix changes, for example due to time of day or day of week, it seems quite natural to re-provision the network, e.g., powering-down links, in a centralized fashion and then have applications, both TE and non-TE, make use of the resultant topology. I.e., I don't see any role for the IGP in provisioning or re-provisioning a network. Comment inline. Thanks, John On Monday, August 31, 2026 at 07:05:55 PM PDT, Aijun Wang <[email protected]> wrote: Hi, Tony:
Thanks for your explanation, it addresses some of my concerns. Let’s continue to explore your proposal: 1) Based on your explanation, it is obvious that “moving out of TE traffic can’t assure the link utilization down to zero to be turned off”. Normally, TE traffic on one interface occupies only small percentage of the traffic on the link. Then, the proposal in your document doesn’t meet its expected aim. JD: Right, assertions to the contrary, the proposal doesn't work for non-TE traffic. Which is not to say it works as intended for TE traffic. 2) The usage of IGP should be discussed further. To achieve the aim of CSPF, the entity should know not only the network topology, but also its real status, for example, link utilization in real time. Such information is impractical to be obtained by the head router, and can only collected by the central controller. Then, what you described CSPF can only be run by the controller. Considering all the interface information can easily be collected, or configured(power group, interface power etc.) in the NMS, which is easy to synchronize to the controller, why bother IGP? Based on the above considerations, I think Yang based solution is the most appropriate approach, which is more easily to cover the metric-based adjustment to cover the non-TE traffic at the same time. Best Regards Aijun Wang China Telecom From: [email protected] [mailto:[email protected]] On Behalf Of Tony Li Sent: Monday, August 31, 2026 11:16 PM To: Aijun Wang <[email protected]> Cc: Vishnu Pavan Beeram <[email protected]>; Oscar de Dios <[email protected]>; TEAS WG ([email protected]) <[email protected]>; [email protected]; [email protected] Subject: [Teas] Re: Call for adoption: draft-many-teas-power-steering-01 (Ends 2026-09-10) Hi Aijun, I would like to discuss with you to address some concerns before its adoption: 1) This document discuss only the TE traffic, how about the non-TE traffic? If the non-TE traffic can’t be moved out of the sleep capable interfaces, how to save the overall energies? There are other techniquest for redirecting non-TE traffic, such as changing metrics. This is very well-known. 2) This document introduces some new terminologies, but doesn’t describe how to utilize them in one coherent manner, for example, it seems that “Interface Power” value is enough for the TED to calculate the CSPF path, what’s the necessary of the power group? The interface power is not necessarily sufficient. In some systems there is hardware that supports the interface that can also be potentially put into power-sleep. This also should contribute to the metric computation. In fact, in some cases, this is far more significant than the interface power. This hardware may include MACSEC hardware, gearboxes, PHYs, NPUs, daughter cards, and switch cards. These are described by power groups, each with its own PSP. 3) https://datatracker.ietf.org/doc/html/draft-many-teas-power-steering-00#section-8.2 describes that A Power Group is a hierarchical abstraction of power consumed by hardware components. And https://datatracker.ietf.org/doc/html/draft-many-teas-power-steering-00#section-6.3 mentioned the LSR extensions for this value. Is IGP the right protocol to advertise such configuration hierarchical information? Yes, since it is necessary to characterize the hardware architecture for correct path computation. 4) https://datatracker.ietf.org/doc/html/draft-many-teas-power-steering-00#name-the-pcpps-metric mentions the following: The PCPPS Metric is greater than or equal to the TE Metric. The difference between them reflects the cost of a link's power utilization. Can you explain it in more detail? Why PCPPS metric should be greater than TE metric? What’s the meaning of their differences? Shouldn’t PCPPS metric be one new type of TE metric? We are proposing the PCPPS metric to be based on the user’s choice of metric plus an implementation-specific component to account for the PSP along the path. As the penalty for power consumption is necessarily non-negative this makes the PCPPS metric greater than or equal to the base metric. The difference is a penalty based on the PSP of the path. A separate metric would cause additional managerial overhead, which we are trying to avoid. Regards, Tony _______________________________________________ Teas 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]
