Hi Vishnu, The described approach is ok except this: "and sleeping adjacencies "
IMO definition of new ISIS adj type belongs to a document which describes how they are created. Rest (especially TE related extensions) are ok to proceed in my books as written. Kind regards, Robert On Thu, Aug 27, 2026 at 3:42 AM Vishnu Pavan Beeram < [email protected]> wrote: > Les, > > The question about coordinating sleep-wake transitions is valid — as Colby > noted earlier, we plan to cover it in a separate companion document that > defines automated coordination procedures. > > That said, these procedures are not a prerequisite for progressing the two > documents currently under discussion, which serve distinct purposes: > > - The LSR draft advertises power group membership, PSP values, and > sleeping adjacencies — it is an information distribution mechanism. > - The TEAS draft uses that information for power-aware path placement > — it concentrates traffic to make links candidates for sleeping. > > Neither document prescribes how an interface transitions to sleep. The > sleep-wake coordination procedure is intentionally decoupled — an > implementation may choose to use controller-driven coordination (ideally > backed by a standard data model such as GREEN YANG), a standardized > protocol handshake (we plan to publish a document that provides one option > for this, though it need not be the only one), or its own coordination > procedure using device APIs on both ends of the link. > > The TLVs defined in the LSR document are usable with any of these > approaches. > > We can add an explicit statement in both drafts clarifying that the > procedures for coordinating sleep-wake transitions are outside their scope. > > Regards, > -Pavan > > On Wed, Aug 26, 2026 at 7:51 AM Les Ginsberg (ginsberg) < > [email protected]> wrote: > >> Colby – >> >> >> >> Given that these procedures seem to be relevant to interoperability, I >> find it odd that you think discussing them is outside the scope of the >> current documents. >> >> Defining new TLVs without defining the procedures which make them usable >> seems less than desirable. >> >> >> >> Les >> >> >> >> *From:* Barth, Colby <[email protected]> >> *Sent:* Wednesday, August 26, 2026 5:49 AM >> *To:* Les Ginsberg (ginsberg) <[email protected]>; Robert Raszuk < >> [email protected]>; 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]>; lsr-chairs <[email protected]>; >> lsr <[email protected]>; Getting Ready for Energy-Efficient Networking >> Discussion List <[email protected]> >> *Subject:* Re: [Green] Re: [Lsr] Re: Re: Adoption of >> draft-many-lsr-power-group >> >> >> >> Hi Les, >> >> >> >> Yes, we definitely care about coordinating sleep-wake transitions between >> directly connected interfaces. The procedures for dynamically ensuring that >> both ends of the link have been put to sleep are outside the scope of this >> document and should be discussed separately. They are outside the scope of >> the TEAS document as well. >> >> >> >> -- Colby >> >> >> >> *From: *Les Ginsberg (ginsberg) <[email protected]> >> *Date: *Wednesday, August 26, 2026 at 1:58 AM >> *To: *Robert Raszuk <[email protected]>; 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]>; 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 >> >> Just continuing to walk down this road… >> >> >> >> If A and B have an adjacency, and A makes a local decision – after >> whatever traffic flow consolidation has taken place – to place the >> interface to B in power sleep mode – what assurance do we have that B will >> do the same?? >> >> If it doesn’t, you end up with A advertising a sleeping adjacency to B >> and B not advertising any adjacency (regular or sleeping) to A. >> >> Which means the two way connectivity check that Ron has mentioned as >> regards to sleeping adjacencies fails…which means we really have no way of >> knowing whether the link A-B actually exists (other than history). >> >> >> >> Or are you thinking that B – upon seeing that A is now advertising a >> sleeping adjacency to B – MUST do the same on the link to A? And presumably >> MUST do so before the non-sleeping adjacency to A goes down – else there >> will be no knowledge that the link A-B is potentially usable. >> >> >> >> Colby – do you care about this?? >> >> Do you think this needs to be discussed in the LSR draft? Or the TEAS >> draft? >> >> >> >> Les >> >> >> >> >> >> *From:* Robert Raszuk <[email protected]> >> *Sent:* Tuesday, August 25, 2026 2:56 PM >> *To:* Barth, Colby <[email protected]> >> *Cc:* [email protected]; 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 (ginsberg) <[email protected]>; lsr-chairs <[email protected]>; >> lsr <[email protected]>; Getting Ready for Energy-Efficient Networking >> Discussion List <[email protected]> >> *Subject:* Re: [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 ? >> >> >> >> And likewise what makes a power group with all its members (interfaces) >> to wake up ? Is this mgmt driven ? >> >> >> >> 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!gj2s31bLTl_s8ynWgf4RKj-GpsucY1VLHvzp5Q8zeOfXvT9ASHw7v00ECO_Ov8bsdhtS9h_3aW8MlalHHdvnaw0FZINme4A$> >> 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!gj2s31bLTl_s8ynWgf4RKj-GpsucY1VLHvzp5Q8zeOfXvT9ASHw7v00ECO_Ov8bsdhtS9h_3aW8MlalHHdvnaw0F1cbQcpI$> >> >> >> >> >> 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]
