GenChen,
There would be no costly data model integration because the Path Placement
function is decoupled from the Sleep Management function. Therefore, the Path
Placement data model is decoupled from the Sleep Management data model.
The Path Placement function might need to exchange data with the Sleep Manager
function, but this is not data model integration. It is just read/write access.
Ron
________________________________
From: Chengen(GenChen) <[email protected]>
Sent: Friday, August 28, 2026 3:50 AM
To: Robert Raszuk <[email protected]>; 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: [Lsr] Re: [Green] Re: Re: Re: Adoption of draft-many-lsr-power-group
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]<mailto:[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]<mailto:[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]<mailto:[email protected]>>
Sent: Wednesday, August 26, 2026 5:49 AM
To: Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>>;
Robert Raszuk <[email protected]<mailto:[email protected]>>; Barth, Colby
<[email protected]<mailto:[email protected]>>
Cc: Tony Li <[email protected]<mailto:[email protected]>>; 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]>>; 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: 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]<mailto:[email protected]>>
Date: Wednesday, August 26, 2026 at 1:58 AM
To: Robert Raszuk <[email protected]<mailto:[email protected]>>; Barth, Colby
<[email protected]<mailto:[email protected]>>
Cc: Tony Li <[email protected]<mailto:[email protected]>>; 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]>>; 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: [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]<mailto:[email protected]>>
Sent: Tuesday, August 25, 2026 2:56 PM
To: Barth, Colby
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>; Tony Li
<[email protected]<mailto:[email protected]>>; 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 (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: 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]<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!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]<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]
