Hi all,
I support the use-case being targeted by this document and
draft-many-teas-power-steering.
While I understand that this document is for the IGP TE extensions, I would
still like to see:1) How the exchanged data would be "managed" (I agree with
Nils) e.g. if I'm troubleshooting what info should I expect to find for a Power
Group on a node. An operational considerations section would really help.2)
Alignment with the work in GREEN i.e. making sure that similar data and
semantics exist in GREEN.
The above could be done before adoption but to me it would also be acceptable
if the authors agree to do it post-adoption.
Regards,Reshad.
On Wednesday, September 2, 2026 at 07:27:52 PM EDT, Robert Raszuk
<[email protected]> wrote:
Hi Thomas,
> Through routing protocols I have the ability to re-route when links fail.
I think you must have not been following too closely the last 20+ years of TE
work which went into routing protocols - mainly in a fully distributed fashion.
With TE (to narrow the scope just focus on IGP TE extensions) today's networks
have the ability to automatically compute LSP placement which would allow to
meet required traffic distribution graphs/patterns/SLAs.
What draft-many-lsr-power-group does is extend the current TE (well mainly one
flavor of it) with additional constraints. Yes the actual link's narcosis could
be administered by NOC so could bring it alive - I think Ron or Tony already
mentioned that. What they are doing here is just preparing the patient for it.
Of course there are some questions around this entire proposal, but I have not
noticed so far anyone saying that routing protocols should limit their role to
reroute around a failed link.
Cheers,
R.
On Wed, Sep 2, 2026 at 8:23 PM <[email protected]> wrote:
Dear authors, green and lsr working groups,
I reviewedhttps://datatracker.ietf.org/doc/html/draft-many-lsr-power-group-03
and came to a similar conclusion than Nils. I share his and the concerns of
others in this thread.
Routing protocols are not intended for network management, provision an intend
configuration. Today network management decides which paths are available at
design time where routing protocols decide at runtime which of them are usable
and should be preferred in terms of bandwidth and distance how. With this
document we would extend routing protocols to act based on power usage, and
power down redundant links, thus interfere potentially with network management
intend configuration.
Before continuing any discussions, please consider first to add an operational
considerations section
withhttps://datatracker.ietf.org/doc/html/draft-ietf-opsawg-rfc5706bis
guidance. As an operator I have the control through network management
interfaces how the network should be provisioned. Through routing protocols I
have the ability to re-route when links fail. The section should clearly
outline what change in this paradigm this document introduces and how
manageability still can be maintained in a closed loop operated network.
Starting from there, a network operator can judge wherever proposed approach is
manageable or not and propose corrections or alternative solutions.
Therefore I believe this document is not ready yet for working group adoption.
Best wishes
Thomas
From: [email protected] <[email protected]>
Sent: Wednesday, September 2, 2026 1:24 PM
To: [email protected]; [email protected];
[email protected]; [email protected]
Cc: [email protected]; [email protected]; [email protected]
Subject: [Green] Re: [Teas] Re: [Lsr] Re: WG adoption call for
draft-many-lsr-power-group-03 (Ends 2026-08-30)
Hi Ron,<=p>
As an operator, I share th= concern that energy-saving capabilities cannot be
viewed solely through t=e lens of routing extensions.
While I understand the arg=ment that the current LSR and TEAS drafts focus only
on the path placement=component and not on sleep management, operators
ultimately deploy a complete solution rather than individual protocol
comp=nents. The operational value of the proposed mechanisms depends on how
rou=ing decisions, device capabilities, power-state models, management systems=
and automation frameworks work together.
Hence, one of the most imp=rtant requirements is consistency across planes and
across working groups.=We should avoid a situation where GREEN defines one set
of assumptions and abstractions while routing extensions evolve in=ependently
with a different interpretation of power-saving behavior. Such =ivergence would
increase implementation complexity and complicate interope=ability across
vendors.
For operators, the key que=tion is not whether a function is located in the
routing plane, the manage=ent plane, or a centralized controller. The key
question is whether all components can be deployed and operated coherently=as
part of the same energy-efficiency strategy – and if they use the=same
semantic. Having to do transformations in a middleware to normalize t=e output
is a burden for operational use, too.
Therefore, I support stron=er coordination between GREEN, TEAS, and LSR to
ensure that the resulting =pecifications form a consistent operational
framework.
Best regards,
Nils.
Deut=che Telekom Technik GmbH
E-Mail: [email protected]
Die gesetzlichen Pflichtangaben finden Sie unt=r:
www.telekom=de/pflichtangaben-dttechnik
----------------------------- =span lang="DE"
style="font-size:8.0pt;font-family:"Arial",sa=s-serif;color:#7F7F7F;text-transform:uppercase;mso-ligatures:standardconte=tual;mso-fareast-language:EN-US">
On 9/1/2026 4:08 AM, Chengen(GenChen) wrote:
Hi Ron,
Thank you for the response. I adjusted the cc list a bit to avoid=potential
receiving duplications.
The “decoupling” argument mentioned here mi=ses the architectural dependency:
PCPPS and IGP extensions define what to advertise, but sleep management defines
why and when. You cannot specif= IGP extensions without knowing the power state
model, component capabilit=es, and wake/sleep criteria. Again, operators won’t
reconcile i=dependently defined power-saving mechanisms.
Therefore, adopt the LSR/TEAS IGP extensions/PCPPS drafts only af=er the GREEN
framework and YANG data models mature and the mapping to routing advertisements
is explicitly validated. Deferri=g now avoids rework and ensures operational
coherence.
BR,
Genchen
From: Bonica, Ron<[email protected]>
Sent: 2026年8月29<=span>日 2:43
To: Aijun Wang <[email protected]>; 'Bonica,
Ron'<[email protected]>; 'Christian
Hopps'<[email protected]>; [email protected]
Cc: [email protected]; [email protected]; [email protected]
Subject: [Lsr] Re: WG adoption call for draft-many-lsr-power-group-0= (Ends
2026-08-30)
Aijun, GenChen, Benoit, JinMing
Each of you have expressed concern regarding a distributed approach to t=e
Power Conserving Path Placement Strategy (PCPPS). The following is a response.
A Power Conservation Strategy includes many components. First among them=is the
Path Placement Component. The Path Placement Component concentrates traffic
onto relatively few network resources durin= periods of low demand and
redistributes traffic during periods of high de=and. It *does not* power
interfaces up and down. Its only function is path=computation. When it computes
paths, it optimizes for energy efficiency, leaving some network resources idle
or=nearly idle.
Another component is the Sleep Management Component. The Sleep Managemen=
Component is configured with criteria that must be satisfied before a network
resource is powered down. It monitors networ= resources and powers them down
when they satisfy the configured criteria.=It also powers them up again when
the power up criteria are satisfied.
The Power Placement Component and Sleep Management Component are decoupl=d from
one another. In the simplest case, one could run a Path Placement Component
without a Sleep Management Component. (Alth=ugh I can't imagine why). One could
also run a Sleep Management Component =ithout a Path Placement Component. In
some networks, and for some power do=n criteria, this makes sense.
In a more complex case, the Sleep Management component may require infor=ation
from the Path Placement component to determine if an interface satisfies the
power-up/power-down criteria. For example, t=e Sleep Management algorithm may
prevent interfaces that support LSPs from=being powered down.
Draft-many-teas-power-steering and draft-many-lsr-power-groups describe =he
Path Placement Component. They *do not* describe the Sleep Management function.
This is beyond their scope.
Many of your comments address the Sleep Management function. For example=
- You will not find =n instruction to power an interface up or down in
either of the current dr=fts
- The problem of osc=llation due to frequent power-up/power-down events is
beyond the scope of =he current documents, because they do not power network
resources up or do=n.
Finally, regarding the question of distributed versus centralized
implem=ntation.....
Path Placement Strategies rely on CSPF and the CSPF relies on the LSDB/T=D.
Each node must maintain an identical LSDB copy.
In the past, we have populated the LSDB/TED in a distributed manner, usi=g an
IGP, or in a centralized manner, using a PCE and BGP-LS. Both approaches work.
Some customers prefer one while other cu=tomers prefer the other. The Power
Conserving Path Placement Strategy is n= different from legacy path placement
strategies. There is no reason why i= should be limited to one approach or the
other.
=nbsp; &nb=p; =nbsp; &nb=p; Ron
From: Aijun Wang <[email protected]=g.cn>
Sent: Tuesday, August 25, 2026 11:09 PM
To: 'Bonica, Ron' <[email protected]>; 'Christian =opps'
<[email protected]>;[email protected] <[email protected]>
Cc: [email protected] <[email protected]>;[email protected]
<[email protected]>;[email protected]
<[email protected]>
Subject: RE: [Lsr] Re: WG adoption call for draft-many-lsr-power-gro=p-03 (Ends
2026-08-30)
=i, Ron:
=nbsp;
=ince the TEAS WG has yet start the adoption call
ofdraft-many-teas-power-group.(They are preparing for =t now/IPR call), I would
still suggest that we wait the conclusion of adop=ion call of the base document.
=nd I think you have noticed, there is argument for the necessary of the
di=tributed solution, given it can’t finish the overall power save aim
itself(need information or control capab=lities from the management plane), and
overlap with the capabilities of ma=agement plane.
=nbsp;
=ntil now, I don’t see the promise of the distributed solution, only the
confusion of these newly introduced<=span>capricious TLVs and thei= usages.
=r, would you like to introduce the necessary,indispensable or =ven the
benefits of the distributed solution?
=nbsp;
=ome detail replies inline below.
=nbsp;
=nbsp;
Best Regards
Aijun Wang=o:p>
China Telecom
=nbsp;
From:[email protected]= [mailto:[email protected]] On
Behalf Of Bonica, Ron
Sent: Wednesday, August 26, 2026 8:07 AM
To: Aijun Wang <[email protected]>; 'Christian Hopps'
<[email protected]>;[email protected]
Cc: [email protected]; [email protected]; [email protected]
Subject: [Lsr] Re: WG adoption call for draft-many-lsr-power-group-0= (Ends
2026-08-30)
Hi Ajun,
Thanks for the review. Response inline See [rb]
&=bsp; Ron
From: Aijun Wang <[email protected]>
Sent: Monday, August 24, 2026 10:23 PM
To: 'Christian Hopps' <chopps@chopps.=rg>;[email protected] <lsr@i=tf.org>
Cc: [email protected] <[email protected]>;[email protected]
<[email protected]>;draft-many-lsr-power-group@=etf.org
<[email protected]>
Subject: RE: [Lsr] Re: WG adoption call for draft-many-lsr-power-gro=p-03 (Ends
2026-08-30)
―Correct one typo:】
I do not support its adoption.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Aijun Wang
Sent: Tuesday, August 25, 2026 10:19 AM
To: 'Christian Hopps' <[email protected]>;lsr=ietf.org
Cc: [email protected]; [email protected]; [email protected]
Subject: [Lsr] Re: WG adoption call for draft-many-lsr-power-group-03
(Ends=2026-08-30)
Hi, All:
I do not support is adoption.
The reason are the followings:
1) The base document,
https://urldefense.com/v3/__https:/=datatracker.ietf.org/doc/draft-many-teas-power-steering/__;!!NpxR!iPWTa_Hd=Ts4cfKq-wRonK1P2gTSQHdnS6G14eA4oW_y_OIb6VUvnFZwy4DJlK0_xuExEoZ2KnHSBwyHIjS=ao3c$
, has not been adopted as the TEAS WG document, it is too early to determi=e
whether the IGP protocol extension is necessary or not.
=/o:p>
[rb] I think that =unther addressed this issue. In any event, the TEAS WG is
currently having=a call for adoption on draft-many-teas-power-group.
[WAJ] Let’s wait the conclusion of the adoption call of the base document, then
the necessary of this dist=ibuted solution.
2) There is no any description, or argument to describe the reason that
acc=mplish the power saving via the distributed IGP protocol and the
challenge=for the network operation etc. when comparing with the solution
solely via=the management plane(NETCONT/YANG etc.)
=/o:p>
[rb] The current d=afts describe a distributed Power Conserving Path Placement
Solution. They=do not preclude a centralized solution. Because we do not
preclude a centr=lized solution, we don't feel the need to argue against one.
[WAJ] I don=span lang="ZH-CN"
style="font-size:11.0pt;mso-fareast-language:ZH-CN">=1B$B!Gt see the benefits,
or =he indispensable necessary of such distributed solution.
=/o:p>
3) Considering the=mentioned interfaces can only be switched on/off via the
management, I am =ondering why bother IGP to accomplish the path calculation
work then?
=/o:p>
[rb] Are you sure =hat interfaces can only be switched on/off via a network
management interf=ce? Is it possible that the platform might offer an API
through which an i=terface can be switched on/off? Might that API be made
available to multiple network management applications (e.=., CLI, NETCONF)?
Might that API also be made available to a local applica=ion that monitors
interface utilization and powers interface on/off as nee=ed?
[WAJ] These are al= possible, but currently there are no on/off signal
communicated via the I=P protocol, then it must depend on other ways to
accomplish the power save=aim. Or, will you add some mechanism in your
proposal later?
=/o:p>
Are you sure that =he IGP does the path calculation work? According to
draft-many-teas-power-=teering, CSPF does the path calculation work. It uses
the PCPPS metric to =o so. It uses the TLVs described in
draft-many-lsr-power-group to calculate the PCPPS metric.
[WAJ] If the flood=ng of these TLVs is not let IGP does the path calculation
work, then the n=cessary of such flooding became more unnecessary:
The PCE know the s=rvices requirements, the PCE can collect the network
conditions, the PCE c=n calculate the necessary topology/bandwidth/interfaces
on/off, then why l=t the IGP do extraordinary work?
4) Given the discussions for the encoding of proposed TLVs, and the authors=
responses for the updating them later, which are all non-trivial modifica=ions,
it's better to postpone to its adoption.
=/o:p>
[rb] This is a pro=edural issue, to be addressed by the chairs. Typically, at
the end of a ca=l for adoption, authors are given a chance to produce a new
version of the=draft that addresses issues raided during the call for adoption.
[WAJ] The core con=ents of this LSR draft are the definition of these TLVs, If
they have not =een solid, what’= the value, and legitimacy of the adoption call?
5) The document defines only some TLVs and there is no any procedures to
de=cribe how to utilize them, how to coordinate with other existing
TLVs/sub-=LVs/Flooding mechanism etc., it will be difficult for other vendors
to imp=ement and will influence future interoperability.
=/o:p>
[rb] Which TLVs are missing? As per draf=-many-teas-power-steering, these TLVs
are used as inputs to the PCPPS metr=c calculation. Which interactions are
missing? Should the addition of any TLV or sub-TLV change the flooding
mechanism?
[WAJ] In the base document, it mentioned=there may be centralized, or
distributed.
If PCPPS is=centralized, as I mentioned above, there is no necessary for the
IGP to pa=ticipate in
If PCPPS is distributed, the procedure for consuming such newly defined TLVs
should=be described.
= &nb=p; Ron
Best Regards
Aijun Wang
China Telecom
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf Of Christian Hopps via Datatracker
Sent: Monday, August 17, 2026 8:57 AM
To:
Cc: [email protected]; [email protected]; [email protected]
Subject: [Lsr] WG adoption call for draft-many-lsr-power-group-03 (Ends
202=-08-30)
Hi Folks,
This begins a 2 week WG Adoption Call for the following draft:
https://urldefense.com/v3/__https://datatracker.ietf.=rg/doc/draft-many-lsr-power-group/__;!!NpxR!iPWTa_HdgTs4cfKq-wRonK1P2gTSQH=nS6G14eA4oW_y_OIb6VUvnFZwy4DJlK0_xuExEoZ2KnHSBwyHIv92BtCB$
Please indicate your support or objections by August 30th, 2026.
An IPR declaration has been made
https://urldefense.com/=3/__https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft=many-lsr-power-group__;!!NpxR!iPWTa_HdgTs4cfKq-wRonK1P2gTSQHdnS6G14eA4oW_y=OIb6VUvnFZwy4DJlK0_xuExEoZ2KnHSBwyHIpbPHXJm$
Authors, please respond to the list indicating whether you are aware of
any=other IPR that applies to this draft.
Thanks,
Chris.
[Call for adoption end date (2026-08-30)]
_______________________________________________
Lsr mailing list -- [email protected] To unsubscribe send an email
[email protected]
_______________________________________________
Lsr mailing list -- [email protected] To unsubscribe send an email
[email protected]=/p>
_______________________________________________Teas mailing list --
[email protected] unsubscribe send an email to
_______________________________________________Green mailing list --
[email protected]=/a>To unsubscribe send an email to
_______________________________________________
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]
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
