Zhangli,
You have a good point. In the draft, we tell you:
*
That CSPF uses a PCPPS metric to place paths
*
The inputs to PCPPS metric computation
But we never tell you how to compute the PCPPS metric.
On one hand, we don't want to dictate the algorithm. One vendor may have a
better algorithm than another. On the other hand, implementers need something
to work with.
Maybe we should add an appendix that suggests, but does not mandate an
algorithm. The appendix would say something like the following:
"To minimize the power consumption of the network, traffic needs to be
consolidated. The objective is to find a path that does not violate
constraints and has the lowest derived PCPPS metric. The PCPPS metric is a
function of the original IGP, TE or delay metric and cumulative power
consumption. The cumulative power on a path is the sum of the PSP for each
traversed interface on the path, plus the PSP of the interface’s parent power
groups, recursively. The cumulative power on a path is multiplied by a
configured constant and then added to the path’s metric. This produces an
overall metric that respects both power consumption and distance.
If two paths have identical overall metrics, then we break ties using the
symmetric max-fill criteria. Given two links, compare the bi-directional
bandwidth utilization on the links. Favor the link with the higher bandwidth.
This causes traffic to consolidate rather than disperse.
To avoid re-use of links that are already idle, we also filter links, rejecting
links with a utilization below a configured threshold. If it is not possible to
compute a path with this restriction, then we recompute without this
restriction. "
What do you think?
Ron
________________________________
From: zhangli (CE) <[email protected]>
Sent: Thursday, August 27, 2026 7:13 AM
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] WG adoption call for draft-many-lsr-power-group-03 (Ends
2026-08-30)
Hi Bonica,
Thanks for your response. You mentioned that the necessity and usage of these
IGP TLVs are introduced in Section 6 of draft-many-teas-power-steering.
However, I was unable to find this information in that section.
For example, the introduction for PSP states:
“Each TED interface entry includes a PSP value, measured in milliwatts. This
value represents the interface PSP. It does not include the PSPs of the Power
Groups to which it is a member.
For interfaces on the local node, this value is administratively assigned or
learned from hardware. It is advertised by an IGP. For interfaces on a remote
node, this value is learned from an IGP. See I-D.many-lsr-power-group.”
It only defines the meaning of these metrics and how to obtain their values,
but it does not explain why they are needed or how they should be used.
It would be helpful to provide more context to make it easier for readers to
understand the rationale and application of these metrics. This could be added
to either draft-many-lsr-power-group or draft-many-teas-power-steering.
Best regards
Li
发件人: Bonica, Ron <[email protected]>
发送时间: 2026年8月26日 8:17
收件人: zhangli (CE) <[email protected]>; Christian Hopps <[email protected]>;
[email protected]
抄送: [email protected]; [email protected]; [email protected]
主题: Re: [Lsr] WG adoption call for draft-many-lsr-power-group-03 (Ends
2026-08-30)
Hello Li,
Thanks for the review. Responses inline.....
Ron
________________________________
From: zhangli (CE) <[email protected]<mailto:[email protected]>>
Sent: Friday, August 21, 2026 4:09 AM
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] WG adoption call for draft-many-lsr-power-group-03 (Ends
2026-08-30)
Hi All,
I have reviewed this draft and have a few comments. Please let me know if I
have misunderstood anything.
1. General comment: This draft introduces several new TLVs/sub-TLVs but does
not clearly explain their necessity or usage. If this information is already
covered in draft-many-teas-power-steering, please add a reference to that
draft. Otherwise, it would be helpful to provide more context to make it easier
for readers to understand. For example, why is the Unidirectional Sleeping
Bandwidth Sub-TLV needed, and how should it be used?
[rb] Please see draft-many-teas-power-steering, Section 6.
2. Interface PSP Sub-TLV: The definition of the Interface PSP sub-TLV is
somewhat confusing. Section 2.1 defines PSP as "Power Saving Potential," this
concept is abstract. From the discussion on the mailing list, I understand it
is the power that may be saved if a power group goes to sleep. It is
recommended to provide more clarification on this point.
[rb] Please see draft-many-teas-power-steering, Section 3 and Section 6.3.
3. Unidirectional Sleeping Bandwidth Sub-TLV: The definition of sleeping
bandwidth in this draft is not aligned with draft-many-teas-power-steering.
In this draft, it is defined as: "the maximum bandwidth [RFC5305] minus the
bandwidth currently allocated to RSVP-TE label switched paths that was
transitioned to power-sleep."
While in draft-many-teas-power-steering, it is defined as: "this value
represents the sleeping bandwidth on a link."
It is recommended to align these definitions to avoid confusion.
[rb] Good catch. I will fix this to align with the
draft-many-teas-power-steering
I hope these comments can be addressed before the draft is adopted.
Best regards
Li
-----邮件原件-----
发件人: Christian Hopps via Datatracker <[email protected]<mailto:[email protected]>>
发送时间: 2026年8月17日 8:57
收件人: [email protected]<mailto:[email protected]>
抄送: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
主题: [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!g0n9IEp4Z5EWJR38fpoyS5T9s-SbPrKZnCvnWIh2mlrMYP6S8fgWrzaaBxTkP0gdEmfkLXBYm-jtQseIVmFG$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-many-lsr-power-group/__;!!NpxR!g0n9IEp4Z5EWJR38fpoyS5T9s-SbPrKZnCvnWIh2mlrMYP6S8fgWrzaaBxTkP0gdEmfkLXBYm-jtQseIVmFG$>
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!g0n9IEp4Z5EWJR38fpoyS5T9s-SbPrKZnCvnWIh2mlrMYP6S8fgWrzaaBxTkP0gdEmfkLXBYm-jtQkmKKmlx$<https://urldefense.com/v3/__https:/datatracker.ietf.org/ipr/search/?submit=draft&id=draft-many-lsr-power-group__;!!NpxR!g0n9IEp4Z5EWJR38fpoyS5T9s-SbPrKZnCvnWIh2mlrMYP6S8fgWrzaaBxTkP0gdEmfkLXBYm-jtQkmKKmlx$>
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]
To unsubscribe send an email to [email protected]
