Hi, Ron:
Since the TEAS WG has yet start the adoption call of draft-many-teas-power-group.(They are preparing for it now/IPR call), I would still suggest that we wait the conclusion of adoption call of the base document. And I think you have noticed, there is argument for the necessary of the distributed solution, given it can’t finish the overall power save aim itself(need information or control capabilities from the management plane), and overlap with the capabilities of management plane. Until now, I don’t see the promise of the distributed solution, only the confusion of these newly introduced capricious TLVs and their usages. Or, would you like to introduce the necessary, indispensable or even the benefits of the distributed solution? Some detail replies inline below. Best Regards Aijun Wang China Telecom 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-03 (Ends 2026-08-30) Hi Ajun, Thanks for the review. Response inline See [rb] Ron _____ From: Aijun Wang < <mailto:[email protected]> [email protected]> Sent: Monday, August 24, 2026 10:23 PM To: 'Christian Hopps' < <mailto:[email protected]> [email protected]>; <mailto:[email protected]> [email protected] < <mailto:[email protected]> [email protected]> Cc: <mailto:[email protected]> [email protected] < <mailto:[email protected]> [email protected]>; <mailto:[email protected]> [email protected] < <mailto:[email protected]> [email protected]>; <mailto:[email protected]> [email protected] < <mailto:[email protected]> [email protected]> Subject: RE: [Lsr] Re: WG adoption call for draft-many-lsr-power-group-03 (Ends 2026-08-30) 【Correct one typo: 】 I do not support its adoption. -----Original Message----- From: <mailto:[email protected]> [email protected] [ <mailto:[email protected]> mailto:[email protected]] On Behalf Of Aijun Wang Sent: Tuesday, August 25, 2026 10:19 AM To: 'Christian Hopps' < <mailto:[email protected]> [email protected]>; <mailto:[email protected]> [email protected] Cc: <mailto:[email protected]> [email protected]; <mailto:[email protected]> [email protected]; <mailto:[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_HdgTs4cfKq-wRonK1P2gT SQHdnS6G14eA4oW_y_OIb6VUvnFZwy4DJlK0_xuExEoZ2KnHSBwyHIjSsao3c$> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-many-teas -power-steering/__;!!NpxR!iPWTa_HdgTs4cfKq-wRonK1P2gTSQHdnS6G14eA4oW_y_OIb6V UvnFZwy4DJlK0_xuExEoZ2KnHSBwyHIjSsao3c$ , has not been adopted as the TEAS WG document, it is too early to determine whether the IGP protocol extension is necessary or not. [rb] I think that Gunther 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 distributed solution. 2) There is no any description, or argument to describe the reason that accomplish 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.) [rb] The current drafts describe a distributed Power Conserving Path Placement Solution. They do not preclude a centralized solution. Because we do not preclude a centralized solution, we don't feel the need to argue against one. [WAJ] I don’t see the benefits, or the indispensable necessary of such distributed solution. 3) Considering the mentioned interfaces can only be switched on/off via the management, I am wondering why bother IGP to accomplish the path calculation work then? [rb] Are you sure that interfaces can only be switched on/off via a network management interface? Is it possible that the platform might offer an API through which an interface can be switched on/off? Might that API be made available to multiple network management applications (e.g., CLI, NETCONF)? Might that API also be made available to a local application that monitors interface utilization and powers interface on/off as needed? [WAJ] These are all possible, but currently there are no on/off signal communicated via the IGP protocol, then it must depend on other ways to accomplish the power save aim. Or, will you add some mechanism in your proposal later? Are you sure that the IGP does the path calculation work? According to draft-many-teas-power-steering, CSPF does the path calculation work. It uses the PCPPS metric to do so. It uses the TLVs described in draft-many-lsr-power-group to calculate the PCPPS metric. [WAJ] If the flooding of these TLVs is not let IGP does the path calculation work, then the necessary of such flooding became more unnecessary: The PCE know the services requirements, the PCE can collect the network conditions, the PCE can calculate the necessary topology/bandwidth/interfaces on/off, then why let 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 modifications, it's better to postpone to its adoption. [rb] This is a procedural issue, to be addressed by the chairs. Typically, at the end of a call 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 contents of this LSR draft are the definition of these TLVs, If they have not been solid, what’s the value, and legitimacy of the adoption call? 5) The document defines only some TLVs and there is no any procedures to describe how to utilize them, how to coordinate with other existing TLVs/sub-TLVs/Flooding mechanism etc., it will be difficult for other vendors to implement and will influence future interoperability. [rb] Which TLVs are missing? As per draft-many-teas-power-steering, these TLVs are used as inputs to the PCPPS metric 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 participate in If PCPPS is distributed, the procedure for consuming such newly defined TLVs should be described. Ron Best Regards Aijun Wang China Telecom -----Original Message----- From: <mailto:[email protected]> [email protected] [ <mailto:[email protected]> mailto:[email protected]] On Behalf Of Christian Hopps via Datatracker Sent: Monday, August 17, 2026 8:57 AM To: <mailto:[email protected]> [email protected] Cc: <mailto:[email protected]> [email protected]; <mailto:[email protected]> [email protected]; <mailto:[email protected]> [email protected] Subject: [Lsr] WG adoption call for draft-many-lsr-power-group-03 (Ends 2026-08-30) Hi Folks, This begins a 2 week WG Adoption Call for the following draft: <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-many-lsr- power-group/__;!!NpxR!iPWTa_HdgTs4cfKq-wRonK1P2gTSQHdnS6G14eA4oW_y_OIb6VUvnF Zwy4DJlK0_xuExEoZ2KnHSBwyHIv92BtCB$> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-many-lsr- power-group/__;!!NpxR!iPWTa_HdgTs4cfKq-wRonK1P2gTSQHdnS6G14eA4oW_y_OIb6VUvnF Zwy4DJlK0_xuExEoZ2KnHSBwyHIv92BtCB$ Please indicate your support or objections by August 30th, 2026. An IPR declaration has been made <https://urldefense.com/v3/__https:/datatracker.ietf.org/ipr/search/?submit= draft&id=draft-many-lsr-power-group__;!!NpxR!iPWTa_HdgTs4cfKq-wRonK1P2gTSQHd nS6G14eA4oW_y_OIb6VUvnFZwy4DJlK0_xuExEoZ2KnHSBwyHIpbPHXJm$> https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/search/?submit= draft&id=draft-many-lsr-power-group__;!!NpxR!iPWTa_HdgTs4cfKq-wRonK1P2gTSQHd nS6G14eA4oW_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 -- <mailto:[email protected]> [email protected] To unsubscribe send an email to <mailto:[email protected]> lsr-leave@ietf. org _______________________________________________ Lsr mailing list -- <mailto:[email protected]> [email protected] To unsubscribe send an email to <mailto:[email protected]> lsr-leave@ietf. org
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
