Hi Ron,
Thank you for the response. I adjusted the cc list a bit to avoid
potential receiving duplications.
The “decoupling” argument mentioned here misses the architectural
dependency: PCPPS and IGP extensions define what to advertise, but
sleep management defines why and when. You cannot specify IGP
extensions without knowing the power state model, component
capabilities, and wake/sleep criteria. Again, operators won’t
reconcile independently defined power-saving mechanisms.
Therefore, adopt the LSR/TEAS IGP extensions/PCPPS drafts only after
the GREEN framework and YANG data models mature and the mapping to
routing advertisements is explicitly validated. Deferring now avoids
rework and ensures operational coherence.
BR,
Genchen
*From:*Bonica, Ron <[email protected]>
*Sent:* 2026年8月29日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-03 (Ends 2026-08-30)
Aijun, GenChen, Benoit, JinMing
Each of you have expressed concern regarding a distributed approach to
the 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 during
periods of low demand and redistributes traffic during periods of high
demand. 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
Management Component is configured with criteria that must be
satisfied before a network resource is powered down. It monitors
network 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
decoupled from one another. In the simplest case, one could run a Path
Placement Component without a Sleep Management Component. (Although I
can't imagine why). One could also run a Sleep Management Component
without a Path Placement Component. In some networks, and for some
power down criteria, this makes sense.
In a more complex case, the Sleep Management component may require
information from the Path Placement component to determine if an
interface satisfies the power-up/power-down criteria. For example, the
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 the 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 an instruction to power an interface up or down
in either of the current drafts
* The problem of oscillation due to frequent power-up/power-down
events is beyond the scope of the current documents, because they
do not power network resources up or down.
Finally, regarding the question of distributed versus centralized
implementation.....
Path Placement Strategies rely on CSPF and the CSPF relies on the
LSDB/TED. Each node must maintain an identical LSDB copy.
In the past, we have populated the LSDB/TED in a distributed manner,
using an IGP, or in a centralized manner, using a PCE and BGP-LS. Both
approaches work. Some customers prefer one while other customers
prefer the other. The Power Conserving Path Placement Strategy is no
different from legacy path placement strategies. There is no reason
why it should be limited to one approach or the other.
Ron
------------------------------------------------------------------------
*From:*Aijun Wang <[email protected]>
*Sent:* Tuesday, August 25, 2026 11:09 PM
*To:* 'Bonica, Ron' <[email protected]>;
'Christian Hopps' <[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-group-03 (Ends 2026-08-30)
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, indispensableor even
the benefits of the distributed solution?
Some detail replies inline below.
Best Regards
Aijun Wang
China Telecom
*From:*[email protected]
[mailto:[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 <[email protected]
<mailto:[email protected]>>
*Sent:* Monday, August 24, 2026 10:23 PM
*To:* 'Christian Hopps' <[email protected]
<mailto:[email protected]>>; [email protected]
<mailto:[email protected]><[email protected] <mailto:[email protected]>>
*Cc:* [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]
<mailto:[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: [email protected]
<mailto:[email protected]>[mailto:[email protected]
<mailto:[email protected]>] On Behalf Of Aijun Wang
Sent: Tuesday, August 25, 2026 10:19 AM
To: 'Christian Hopps' <[email protected] <mailto:[email protected]>>;
[email protected] <mailto:[email protected]>
Cc: [email protected] <mailto:[email protected]>; [email protected]
<mailto:[email protected]>; [email protected]
<mailto:[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-wRonK1P2gTSQHdnS6G14eA4oW_y_OIb6VUvnFZwy4DJlK0_xuExEoZ2KnHSBwyHIjSsao3c$
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-many-teas-power-steering/__;!!NpxR!iPWTa_HdgTs4cfKq-wRonK1P2gTSQHdnS6G14eA4oW_y_OIb6VUvnFZwy4DJlK0_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 PCPPSis distributed, the procedure for consuming such newly defined
TLVs should be described.
Ron
Best Regards
Aijun Wang
China Telecom
-----Original Message-----
From: [email protected]
<mailto:[email protected]>[mailto:[email protected]
<mailto:[email protected]>] On Behalf Of Christian Hopps
via Datatracker
Sent: Monday, August 17, 2026 8:57 AM
To: [email protected] <mailto:[email protected]>
Cc: [email protected] <mailto:[email protected]>; [email protected]
<mailto:[email protected]>; [email protected]
<mailto:[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_OIb6VUvnFZwy4DJlK0_xuExEoZ2KnHSBwyHIv92BtCB$
<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-many-lsr-power-group/__;!!NpxR!iPWTa_HdgTs4cfKq-wRonK1P2gTSQHdnS6G14eA4oW_y_OIb6VUvnFZwy4DJlK0_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-wRonK1P2gTSQHdnS6G14eA4oW_y_OIb6VUvnFZwy4DJlK0_xuExEoZ2KnHSBwyHIpbPHXJm$
<https://urldefense.com/v3/__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] <mailto:[email protected]>
To unsubscribe send an email to [email protected]
<mailto:[email protected]>
_______________________________________________
Lsr mailing list -- [email protected] <mailto:[email protected]>
To unsubscribe send an email to [email protected]
<mailto:[email protected]>
_______________________________________________
Teas mailing list [email protected]
To unsubscribe send an email [email protected]
