Hi Colby, I am not sure what Ron said applies to my or Les question. I am also not sure if we can treat it as out of scope of LSR discussion if you are defining a new adj state in the subject draft - which seems could be problematic to peers which do not understand the new extension.
Cheers, R. On Wed, Aug 26, 2026 at 2:00 PM Barth, Colby <[email protected]> wrote: > 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 <jonathan.barth= > [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] <[email protected]> > *Date: *Monday, August 24, 2026 at 4:55 PM > *To: *Tony Li <[email protected]> > *Cc: *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: *[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] > To unsubscribe send an email to [email protected] > >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
