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 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:* [email protected] <[email protected]> > *Sent:* Wednesday, September 2, 2026 1:24 PM > *To:* [email protected]; [email protected]; chengen= > [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] <[email protected]>* *www.telekom.de > <http://www.telekom.de/>* > > > > *[image: Ein B=ld, das Schrift, Grafiken, Grafikdesign, Text enthält. > =0A=utomatisch generierte Beschreibung]* > > > > *[image: 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 <[email protected]> > <[email protected]> Sent: 2026**年**8**月**29<=span>* > *日* > > > * 2:43 To: Aijun Wang <[email protected]> > <[email protected]>; 'Bonica, Ron' > <[email protected]> > <[email protected]>; 'Christian Hopps' > <[email protected]> <[email protected]>; [email protected] Cc: [email protected] > <[email protected]>; [email protected] <[email protected]>; > [email protected] <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* > > > 2. *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 <[email protected]>> Sent: > Tuesday, August 25, 2026 11:09 PM To: 'Bonica, Ron' > <[email protected] > <ronald.bonica=40hpe.com@dm=rc.ietf.org>>; 'Christian =opps' > <[email protected] <[email protected]>>; [email protected] <[email protected]> > <[email protected] <lsr@=etf.org>> Cc: [email protected] <[email protected]> > <[email protected] <[email protected]>>; [email protected] > <[email protected]> <[email protected]>; > [email protected] <[email protected]> > <[email protected] <[email protected]=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:* > > > > * [email protected]= <[email protected]> > [mailto:[email protected] <[email protected]>] On > Behalf Of Bonica, Ron Sent: Wednesday, August 26, 2026 8:07 AM To: Aijun > Wang <[email protected] <[email protected]>>; 'Christian > Hopps' <[email protected] <[email protected]>>; [email protected] <[email protected]> > Cc: [email protected] <[email protected]>; [email protected] > <[email protected]>; [email protected] > <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 <**[email protected] > <http://[email protected]>* > > *> Sent: Monday, August 24, 2026 10:23 PM To: 'Christian Hopps' > <**chopps@chopps.=rg > <[email protected]=%3e%3cspan%20style=>**>; **[email protected] <[email protected]>** > <* > *lsr@i=tf.org <lsr=ietf.org>> Cc: [email protected] <[email protected]> > <**[email protected] > <[email protected]>**>; **[email protected] <[email protected]>** <* > *[email protected]**>; **draft-many-lsr-power-group@=etf.org > <[email protected]>** <**[email protected] > <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: * > > *[email protected] <[email protected]> > [mailto:[email protected]] On Behalf Of Aijun Wang Sent: > Tuesday, August 25, 2026 10:19 AM To: 'Christian Hopps' < > <[email protected]>* > > > > > > > > > *[email protected] <[email protected]>>; lsr=ietf.org <[email protected]> Cc: > [email protected] <[email protected]>; [email protected] > <[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$ > <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!G**t 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 PCP**PS** 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] <[email protected]> > [mailto:[email protected]] On Behalf Of Christian Hopps via > Datatracker Sent: Monday, August 17, 2026 8:57 AM To: > <[email protected]>* > > > > > > > > > > > > > > > > > > > > > > > > > > > * Cc: [email protected] <[email protected]>; [email protected] > <[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$ > <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 -- [email protected] <[email protected]> To unsubscribe send an email to > [email protected] <[email protected]=%3e%3cspan%20style=> > _______________________________________________ Lsr mailing list -- > [email protected] <[email protected]> To unsubscribe send an email to > [email protected] <[email protected]=%3e%3cspan%20style=>**=/p> * > > > > *_______________________________________________* > > *Teas mailing list -- [email protected] <[email protected]>* > > *To unsubscribe send an email to * > > > > *_______________________________________________* > > *Green mailing list -- [email protected]=/a> <[email protected]>* > > *To unsubscribe send an email to <[email protected]>** > <[email protected]=%[email protected]%3c/a%3e%3co:p%3e%3c/o:p%3e%3c/pre%3e%3c/blockquote%3e%3cp%20class=>* > > * > <[email protected]=%[email protected]%3c/a%3e%3co:p%3e%3c/o:p%3e%3c/pre%3e%3c/blockquote%3e%3cp%20class=>* > > * > <[email protected]=%[email protected]%3c/a%3e%3co:p%3e%3c/o:p%3e%3c/pre%3e%3c/blockquote%3e%3cp%20class=>* > > > > _______________________________________________ > 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]
