[Green] Re: [Teas] Re: [Lsr] Re: WG adoption call for draft-many-lsr-power-group-03 (Ends 2026-08-30)

[[e-mail]]

Dear authors, green and lsr working groups,

I reviewed https://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 with https://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: [e-mail] <[e-mail]>
Sent: Wednesday, September 2, 2026 1:24 PM
To: [e-mail]; [e-mail]; chengen=[e-mail]; ronald.bonica=[e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
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: [e-mail]<mailto:[e-mail]> www.telekom.de<http://www.telekom.de/>

[Ein B=ld, das Schrift, Grafiken, Grafikdesign, Text enthält. =0A=utomatisch generierte Beschreibung]

[Stand=rtMünsterBanner]

Die gesetzlichen Pflichtangaben finden Sie unt=r:
www.telekom=de/pflichtangaben-dttechnik<http://www.tele=om.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 <ronald.boni=a=[e-mail]><mailto:ronald.bonica=[e-mail]>
Sent: 2026年8月29<=span>日 2:43
To: Aijun Wang <wang=[e-mail]><mailto:[e-mail]>; 'Bonica, Ron' <ronald.boni=a=[e-mail]><mailto:ronald.bonica=[e-mail]>; 'Christian Hopps' <[e-mail]><mailto:[e-mail]>; [e-mail]<3D%22mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:draft-many-lsr-power-group@ietf.=rg>
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=

  1.  You will not find =n instruction to power an interface up or down in either of the current dr=fts

  1.  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 <wangaijun@tsinghua.o=g.cn<mailto:[e-mail]>>
Sent: Tuesday, August 25, 2026 11:09 PM
To: 'Bonica, Ron' <ronald.bonica=[e-mail]<mailto:ronald.bonica=40hpe.com@dm=rc.ietf.org>>; 'Christian =opps' <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:lsr@=etf.org>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<3D%22mailto:[e-mail]>>; draft-many-lsr-power=[e-mail]<mailto:[e-mail]> <[e-mail]<mailto:draft-many-lsr-power-group@ietf.o=g>>
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 of draft-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: [e-mail]=<mailto:[e-mail]> [mailto:forwardingalg=[e-mail]<mailto:[e-mail]>] On Behalf Of Bonica, Ron
Sent: Wednesday, August 26, 2026 8:07 AM
To: Aijun Wang <wang=[e-mail]<mailto:[e-mail]>>; 'Christian Hopps' <[e-mail]<mailto:chop=[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:draft-many-lsr-power-group@ietf.=rg>
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 <[e-mail]<mailto=[e-mail]>>
Sent: Monday, August 24, 2026 10:23 PM
To: 'Christian Hopps' <chopps@chopps.=rg<mailto:[e-mail]=%3e%3cspan%20style=>>; [e-mail]<mailto:[e-mail]> <lsr@i=tf.org<mailto:lsr=ietf.org>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<3D%22mailto:[e-mail]>>; draft-many-lsr-power-group@=etf.org<mailto:[e-mail]> <draft-man=[e-mail]<mailto:draft-many-lsr-power-group@iet=.org>>
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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Aijun Wang
Sent: Tuesday, August 25, 2026 10:19 AM
To: 'Christian Hopps' <<mailto:[e-mail]>[e-mail]<mailto:[e-mail]>>; lsr=ietf.org<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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$<https://urldefense.com/v3/__https:/=atatracker.ietf.org/doc/draft-many-teas-power-steering/__;!!NpxR!iPWTa_Hdg=s4cfKq-wRonK1P2gTSQHdnS6G14eA4oW_y_OIb6VUvnFZwy4DJlK0_xuExEoZ2KnHSBwyHIjSs=o3c$> , 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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Christian Hopps via Datatracker
Sent: Monday, August 17, 2026 8:57 AM
To: <mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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$<https://urldefense.com/v3/__https:/datatracker.iet=.org/doc/draft-many-lsr-power-group/__;!!NpxR!iPWTa_HdgTs4cfKq-wRonK1P2gTS=HdnS6G14eA4oW_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$<https://urldefense.com/v3/__https:/datatracker.iet=.org/ipr/search/?submit=draft&id=draft-many-lsr-power-group__;!!Np=R!iPWTa_HdgTs4cfKq-wRonK1P2gTSQHdnS6G14eA4oW_y_OIb6VUvnFZwy4DJlK0_xuExEoZ2=nHSBwyHIpbPHXJm$>

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 -- [e-mail]<mailto:[e-mail]> To unsubscribe send an email to [e-mail]<mailto:[e-mail]=%3e%3cspan%20style=>

_______________________________________________
Lsr mailing list -- [e-mail]<mailto:[e-mail]> To unsubscribe send an email to [e-mail]<mailto:[e-mail]=%3e%3cspan%20style=>=/p>


_______________________________________________

Teas mailing list -- [e-mail]<mailto:[e-mail]>

To unsubscribe send an email to


_______________________________________________

Green mailing list -- [e-mail]=/a><mailto:[e-mail]>

To unsubscribe send an email to <mailto:[e-mail]>  <mailto:[e-mail]=[e-mail]%3c/a%3e%3co:p%3e%3c/o:p%3e%3c/pre%3e%3c/blockquote%3e%3cp%20class=>

 <mailto:[e-mail]=[e-mail]%3c/a%3e%3co:p%3e%3c/o:p%3e%3c/pre%3e%3c/blockquote%3e%3cp%20class=>

 <mailto:[e-mail]=[e-mail]%3c/a%3e%3co:p%3e%3c/o:p%3e%3c/pre%3e%3c/blockquote%3e%3cp%20class=>