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 <[email protected]>
*Sent:* 2026年8月27日 18:10
*To:* Vishnu Pavan Beeram <[email protected]>
*Cc:* Les Ginsberg (ginsberg) <[email protected]>; Barth, Colby
<[email protected]>; Barth, Colby
<[email protected]>; Tony Li <[email protected]>; Marisol
<[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
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
<[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 [email protected]
