[Green] Re: [Lsr] Re: Re: Re: Re: Adoption of draft-many-lsr-power-group

[Joel Halpern <[e-mail]>]

I think I am missing something.  It is quite clear that multiple 
operational practices and algorithmic behaviors tcan exist that make use 
of this information about power save capability. Demanding that this 
draft decide which one is to be used would seem counter-productive.  And 
if it specified only one, some folks would rightly object that there are 
other ways to skin the cat.

Yours,

Joel

PS: May I suggest that folks trim the to: and cc: lists.  While how much 
to retain is a judgement call, the chairs were all getting extra copies, 
and a long list of people had accumulated. (I have retained all three 
working groups.  Apologies to the folks who thus receive 3 copies.)

On 8/28/2026 3:50 AM, Chengen(GenChen) wrote:
>
> Hi All,
>
> It is said here that sleep-wake coordination procedure is 
> intentionally decoupled, suggesting they could be handled by 
> controller-driven mechanisms, GREEN YANG, or device-specific APIs. 
> That is precisely the problem Benoit highlights: operators manage 
> control, data, and management planes holistically. They cannot 
> reconcile multiple unaligned power-saving methods without a unified 
> framework.
>
> Furthermore, the draft’s Power Group abstraction has no defined 
> relationship to the power states and hierarchy in the GREEN YANG 
> module and Framework.
>
> Adopting this draft now would force operators into costly data model 
> integration. We should first align the TE extensions with the broader 
> GREEN framework and define proper sleep-wake coordination 
> procedures—only then can LSR consider advertising these states in the IGP.
>
> BR,
>
> GenChen
>
> *From:* Robert Raszuk <[e-mail]>
> *Sent:* 2026年8月27日 18:10
> *To:* Vishnu Pavan Beeram <[e-mail]>
> *Cc:* Les Ginsberg (ginsberg) <[e-mail]>; Barth, Colby 
> <jonathan.barth=[e-mail]>; Barth, Colby 
> <[e-mail]>; Tony Li <[e-mail]>; Marisol 
> <[e-mail]>; Gunter van de Velde (Nokia) 
> <[e-mail]>; Acee Lindem <[e-mail]>; 
> TEAS WG Chairs <[e-mail]>; Christian Hopps 
> <[e-mail]>; “[e-mail]” <[e-mail]>; lsr-chairs 
> <[e-mail]>; lsr <[e-mail]>; Getting Ready for 
> Energy-Efficient Networking Discussion List <[e-mail]>
> *Subject:* [Green] Re: [Lsr] Re: Re: Adoption of 
> draft-many-lsr-power-group
>
> 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 
> <[e-mail]> 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)
>     <[e-mail]> 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 <jonathan.barth=[e-mail]>
>         *Sent:* Wednesday, August 26, 2026 5:49 AM
>         *To:* Les Ginsberg (ginsberg) <[e-mail]>; Robert
>         Raszuk <[e-mail]>; Barth, Colby <[e-mail]>
>         *Cc:* Tony Li <[e-mail]>; Marisol
>         <[e-mail]>; Vishnu Pavan Beeram
>         <[e-mail]>; Gunter van de Velde (Nokia)
>         <[e-mail]>; Acee Lindem
>         <[e-mail]>; TEAS WG Chairs <[e-mail]>;
>         Christian Hopps <[e-mail]>; “[e-mail]”
>         <[e-mail]>; lsr-chairs <[e-mail]>; lsr
>         <[e-mail]>; Getting Ready for Energy-Efficient Networking
>         Discussion List <[e-mail]>
>         *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)
>         <ginsberg=[e-mail]>
>         *Date: *Wednesday, August 26, 2026 at 1:58 AM
>         *To: *Robert Raszuk <[e-mail]>; Barth, Colby
>         <jonathan.barth=[e-mail]>
>         *Cc: *Tony Li <[e-mail]>; Marisol
>         <[e-mail]>; Vishnu Pavan Beeram
>         <[e-mail]>; Gunter van de Velde (Nokia)
>         <[e-mail]>; Acee Lindem
>         <[e-mail]>; TEAS WG Chairs <[e-mail]>;
>         Christian Hopps <[e-mail]>; “[e-mail]”
>         <[e-mail]>; lsr-chairs <[e-mail]>; lsr
>         <[e-mail]>; Getting Ready for Energy-Efficient Networking
>         Discussion List <[e-mail]>
>         *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 <[e-mail]>
>         *Sent:* Tuesday, August 25, 2026 2:56 PM
>         *To:* Barth, Colby <jonathan.barth=[e-mail]>
>         *Cc:* [e-mail]; Tony Li <[e-mail]>;
>         Marisol <[e-mail]>; Vishnu Pavan Beeram
>         <[e-mail]>; Gunter van de Velde (Nokia)
>         <[e-mail]>; Acee Lindem
>         <[e-mail]>; TEAS WG Chairs <[e-mail]>;
>         Christian Hopps <[e-mail]>; “[e-mail]”
>         <[e-mail]>; Les Ginsberg (ginsberg)
>         <[e-mail]>; lsr-chairs <[e-mail]>; lsr
>         <[e-mail]>; Getting Ready for Energy-Efficient Networking
>         Discussion List <[e-mail]>
>         *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=[e-mail]> 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: *[e-mail] <[e-mail]>
>             *Date: *Monday, August 24, 2026 at 4:55 PM
>             *To: *Tony Li <[e-mail]>
>             *Cc: *Marisol <[e-mail]>; Vishnu Pavan
>             Beeram <[e-mail]>; Gunter van de Velde
>             (Nokia) <[e-mail]>; Acee Lindem
>             <[e-mail]>; TEAS WG Chairs
>             <[e-mail]>; Christian Hopps
>             <[e-mail]>; “[e-mail]”
>             <[e-mail]>; Les Ginsberg <[e-mail]>;
>             lsr-chairs <[e-mail]>; lsr <[e-mail]>;
>             Getting Ready for Energy-Efficient Networking Discussion
>             List <[e-mail]>
>             *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 -- [e-mail]
>             To unsubscribe send an email to [e-mail]
>
>
> _______________________________________________
> Lsr mailing list [e-mail]
> To unsubscribe send an email [e-mail]