Robert, Inline <cb>
-- Colby From: Robert Raszuk <[email protected]> Date: Tuesday, August 25, 2026 at 5:56 PM To: Barth, Colby <[email protected]> Cc: Tony Li <[email protected]>; Marisol <[email protected]>; Vishnu Pavan Beeram <[email protected]>; Gunter van de Velde (Nokia) <[email protected]>; Acee Lindem <[email protected]>; TEAS WG Chairs <[email protected]>; Christian Hopps <[email protected]>; “[email protected]” <[email protected]>; Les Ginsberg <[email protected]>; lsr-chairs <[email protected]>; lsr <[email protected]>; Getting Ready for Energy-Efficient Networking Discussion List <[email protected]> Subject: [Green] Re: [Lsr] Re: Re: Adoption of draft-many-lsr-power-group Hi Colby, Sorry if I missed it but after traffic consolidation what exactly triggers a power group with all its members to be transitioned to ASLEEP state ? Is this local heuristic ? For example traffic is less then X Gb/s for the time T > of Y sec ? <cb> Sure. That’s one possibility. <cb> Ron Bonica said it nicely as well, "Are you sure that interfaces can only be switched on/off via a network management interface? Is it possible that the platform might offer an API through which an interface can be switched on/off? Might that API be made available to multiple network management applications (e.g., CLI, NETCONF)? Might that API also be made available to a local application that monitors interface utilization and powers interface on/off as needed?" And likewise what makes a power group with all its members (interfaces) to wake up ? Is this mgmt driven ? <cb> Again, that’s one possibility. Hth, —Colby Thx, R. On Tue, Aug 25, 2026 at 11:33 PM Barth, Colby <[email protected]<mailto:[email protected]>> wrote: Hi Benoit, all - I’m wondering if it may be helpful to take a step back and consider the big picture here (though I’m not sure the big picture needs to be described in an IETF document). For ‘unused or lightly used’ routing components to be transitioned to some power-sleep state, we need to consolidate traffic flows … without creating congestion. This is Traffic Engineering. And it’s what the 2 drafts we are discussing address, nothing more, nothing less. 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!jDqj8Af0E39jieEEeOMBEhMUqrwPoVdYaFno0V05SL60zO5dEu1YD4d9UCMyx-FLBRbsT0bO8ivOvBE$> and https://datatracker.ietf.org/doc/draft-many-teas-power-steering/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-many-teas-power-steering/__;!!NpxR!jDqj8Af0E39jieEEeOMBEhMUqrwPoVdYaFno0V05SL60zO5dEu1YD4d9UCMyx-FLBRbsT0bOZsNVHjc$> The former being the topic of this WG adoption poll. The power-groups are leveraged by any path computing entity, i.e. an ingress router or centralized PCE, and the facilitate power aware path placement. This is the topic of the latter draft. This traffic engineering step of flow consolidation would be required if one were to employ the GREEN YANG model for conveying and/or controlling various power related information/states to a centralized controller anyway. As far as I can tell, this has never been discussed nor is it in the scope of GREEN. The information carried in the power-group need not be identical to that which is conveyed via the YANG model. They serve different purposes. Once traffic has been consolidated, then some components could be transitioned to power-sleep state. Maybe that is facilitated by the GREEN YANG model or maybe that is left to individual nodes to decide. i.e. without centralized coordination. -- Colby From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Date: Monday, August 24, 2026 at 4:55 PM To: Tony Li <[email protected]<mailto:[email protected]>> Cc: Marisol <[email protected]<mailto:[email protected]>>; Vishnu Pavan Beeram <[email protected]<mailto:[email protected]>>; Gunter van de Velde (Nokia) <[email protected]<mailto:[email protected]>>; Acee Lindem <[email protected]<mailto:[email protected]>>; TEAS WG Chairs <[email protected]<mailto:[email protected]>>; Christian Hopps <[email protected]<mailto:[email protected]>>; “[email protected]<mailto:[email protected]>” <[email protected]<mailto:[email protected]>>; Les Ginsberg <[email protected]<mailto:[email protected]>>; lsr-chairs <[email protected]<mailto:[email protected]>>; lsr <[email protected]<mailto:[email protected]>>; Getting Ready for Energy-Efficient Networking Discussion List <[email protected]<mailto:[email protected]>> Subject: [Lsr] Re: [Green] Re: Adoption of draft-many-lsr-power-group Hi Tony, Thanks for engaging. See inline. On 24/08/2026 22:00, Tony Li wrote: Hi Benoit, How does the Power Group Identifier ("which has node-local significance") refers to a specific Power State in https://datatracker.ietf.org/doc/draft-ietf-green-power-and-energy-yang/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-green-power-and-energy-yang/__;!!NpxR!iFBNz28r2nufsGH34niZQ17aAsLTQDCHAh-GG8bmDm_1wEoidmMlHsXfVB9kKBShNWJyeBp3Jlwxc4_WNIzMSlCI$>, basically on/off/sleep (see YANG identities power-state-on, power-state-off, and power-state-sleep)? The power state is is not reflected in the Power Group Identifier (PGI). The PGI is just associated with a power group, which is an abstraction of some pieces of hardware in the hierarchy. The physical interfaces are the leaves in this hierarchy and the power state for the interfaces is reflected in the IS-IS adjacencies. Interfaces that have an adjacency are (obviously) in power-state-on. Interfaces with a sleeping adjacency are in power-state-sleep. 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" Think of BGP flowspec and IPFIX. Looking at the fields at https://www.rfc-editor.org/info/rfc5575/#section-4<https://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc5575/*section-4__;Iw!!NpxR!iFBNz28r2nufsGH34niZQ17aAsLTQDCHAh-GG8bmDm_1wEoidmMlHsXfVB9kKBShNWJyeBp3Jlwxc4_WNN693ZBN$>, this is such a missed opportunity not to have reused the IPFIX IEs. 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://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc8955/*name-type-1-destination-prefix__;Iw!!NpxR!iFBNz28r2nufsGH34niZQ17aAsLTQDCHAh-GG8bmDm_1wEoidmMlHsXfVB9kKBShNWJyeBp3Jlwxc4_WNHzTFd7N$> 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://urldefense.com/v3/__https://www.claise.be/network-automation-and-the-costly-data-model-integration-mediation/__;!!NpxR!iFBNz28r2nufsGH34niZQ17aAsLTQDCHAh-GG8bmDm_1wEoidmMlHsXfVB9kKBShNWJyeBp3Jlwxc4_WNBsySZB6$>" 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. Btw, a specific operator told me: config management is so complex, with many frozen windows, that I will not allow energy-related configuration independently. Regards, Benoit Cheers, Tony _______________________________________________ Green mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
