As this draft, draft-many-lsr-power-group, is related to what we are
working on the GREEN WG, I would like to highlight some points that
will require some kind of discussion/references, to my understanding,
before the work gets adopted:
1. Informative cross-reference to GREEN WG related work
<https://datatracker.ietf.org/wg/green/documents/>:
The draft currently carries no reference to any GREEN WG document. The
Power Group concept, Sleep Status, and PSP metric all directly relate
to the energy management model defined in the GREEN framework
(draft-ietf-green-framework) and GREEN YANG data model
(draft-ietf-green-power-and-energy-yang). We request to address: that
Power Group membership and PSP values are intended to be consistent
with what a device reports via the GREEN YANG model at the management
plane.
2. Power Group parent-child dependency maps to the GREEN YANG
Functional Enablement Relationship
draft-many-lsr-power-group defines: "One Power Group is the child of
another if any one of the child components depends upon any one of the
parent components." This is precisely the Functional Enablement
Relationship that GREEN WG has extended in its YANG model via the
'enabled-by' and 'enabling' identity pair. The draft
should acknowledge this mapping explicitly, so that implementations
can correlate IS-IS-advertised Power Group hierarchy with the
management-plane relationship model in GREEN YANG without ambiguity.
3. PSP (Power Savings Potential) is a gap in the GREEN YANG model
The PSP field (power saveable in milliwatts if a Power Group goes to
sleep) is a prospective metric with no equivalent in the current GREEN
YANG data model, which defines only actual and historical power
values. Before the draft is adopted, it should be considered
a prospective power metric leaf in a future revision of the YANG
model. We request that the LSR document note that PSP values SHOULD be
consistent with device-reported power data available via the GREEN
YANG model where such data is available, to establish a baseline for
interoperability between the IGP-distributed value and the
management-plane value. It will be good to address this requirement
from the LSR authors.
From my point of view, the three points above are requests for
alignment before the work is adopted.
The guidance that we are getting/adopting by the GREEN WG is to first
focus and prioritize the device level energy capabilities, monitoring
and settings, to later address other use cases, including collector
part, routing capabilities, etc.
Note: adding the GREEN WG to the thread
thanks,
Marisol
On Tue, Aug 18, 2026 at 1:13 PM Vishnu Pavan Beeram
<[email protected]> wrote:
Gunter,
Since I am a co-author of these drafts, I've recused myself from
initiating the adoption process. Oscar is currently on vacation
(as are many folks in Europe) and my understanding is that he will
initiate the process once he returns toward the end of this month.
Regards,
Pavan
On Tue, Aug 18, 2026 at 12:41 AM Gunter van de Velde (Nokia)
<[email protected]> wrote:
+teas-chairs
Hi Italo, Carlos & Vishnupavan,
Can you help understand lsr-chairs and authors of
draft-many-lsr-power-group when the TEAS WG plans to start an
adoption call for the companion draft -
https://datatracker.ietf.org/doc/draft-many-teas-power-steering/
Many thanks,
G/
------------------------------------------------------------------------
*From:* Acee Lindem <[email protected]>
*Sent:* Monday, August 17, 2026 9:34 PM
*To:* Gunter van de Velde (Nokia) <[email protected]>
*Cc:* Tony Li <[email protected]>; Christian Hopps
<[email protected]>; "“[email protected]”" <[email protected]>;
Les Ginsberg <[email protected]>; lsr-chairs
<[email protected]>; lsr <[email protected]>
*Subject:* Re: [Lsr] Adoption of draft-many-lsr-power-group
CAUTION: This is an external email. Please be very careful
when clicking links or opening attachments. See the URL
nok.it/ext <http://nok.it/ext> for additional information.
Speaking as WG Co-chair:
Gunter - given the amount of discussion the draft had
generated, I don't see that there has been any undo delay in
the adoption call.
One thing you could follow up on is when the TEAS WG plans to
start an adoption call for the companion draft -
https://datatracker.ietf.org/doc/draft-many-teas-power-steering/
I haven't seen it yet (although I get lots of Email).
Thanks,
Acee
> On Aug 17, 2026, at 4:41 AM, Gunter van de Velde (Nokia)
<[email protected]> wrote:
>
> Hi Tony, All,
>
> Message received.
> I observed that Chris requested a WG adoption call for
draft-many-lsr-power-group few hours ago.
>
> I believe we should, as Chris proposed, give the normal
route a chance. If that doesn’t work, we can unpack the
situation together and converge on the next steps.
>
> G/
>
>
>
>
>
> From: Tony Li <[email protected]>
> Sent: Friday, August 14, 2026 8:12 PM
> To: Christian Hopps <[email protected]>;
"“[email protected]”" <[email protected]>
> Cc: Les Ginsberg <[email protected]>; lsr-chairs
<[email protected]>; lsr <[email protected]>
> Subject: Re: [Lsr] Adoption of draft-many-lsr-power-group
> CAUTION: This is an external email. Please be very careful
when clicking links or opening attachments. See the URL
nok.it/ext <http://nok.it/ext> for additional information.
>
>
> Hi,
> We still seem stuck. Could I get some AD help, please?
>
> Thanks,
> Tony
>
>
> On Aug 7, 2026, at 8:53 AM, Tony Li <[email protected]>
wrote:
>
> Hi,
> It's now two weeks after the meeting. Could the chairs
please proceed?
>
> Thanks,
> Tony
>
>
> On Mon, Jul 20, 2026 at 2:30 PM Christian Hopps
<[email protected]> wrote:
> Can we please pause this discussion until after the meeting?
I don’t think anything helpful is going on here that benefits
the document or the WG.
>
> No one is raising bars on whims and no one is end running.
>
> Thanks,
> Chris.
>
>
> On Jul 20, 2026, at 22:47, Les Ginsberg (ginsberg)
<[email protected]> wrote:
>
> Tony –
>
> I think Chris and I have expressed the same point.
> I also think you seem to want to “pick a fight” – and I am
not interested in that.
>
> I will call your attention to the following from RFC 7120.
Although RFC 7120 is not directly applicable in this case, it
is related and the concern expressed there seems very relevant
to this case.
>
> From https://www.rfc-editor.org/rfc/rfc7120.html#section-5
>
> “There is a significant concern that the procedures in this
document
>
> could be used as an end-run on the IETF process to
achieve code point
> allocation when an RFC will not be published. For
example, a WG or a
> WG chair might be pressured to obtain an early allocation
for a
> protocol extension for a particular company or for
another Standards
> Development Organization even though it might be
predicted that an
> IETF LC or IESG Evaluation would reject the approach that is
> documented.”
>
> Les
>
>
> From: Tony Li <[email protected]>
> Sent: Monday, July 20, 2026 1:05 PM
> To: Christian Hopps <[email protected]>
> Cc: Les Ginsberg (ginsberg) <[email protected]>; lsr-chairs
<[email protected]>; lsr <[email protected]>
> Subject: Re: [Lsr] Re: Adoption of draft-many-lsr-power-group
>
> Chris, Les,
>
> I wrote that code points "do not require adoption". That is
accurate. A 'SHOULD' is not a 'MUST'. You don't get to
change it into one. What I wrote originally was correct.
>
> I respect the 'SHOULD' and the work the experts do, but the
fact of the matter is that we have code, and it is going to
ship regardless of adoption. At this point, I cannot stop it.
>
> So, this is really up to you. You can allocate, or we can
squat. Waiting is out of the question. Your choice?
>
> Regards,
> Tony
>
> On Mon, Jul 20, 2026 at 9:56 PM Christian Hopps
<[email protected]> wrote:
> Expert hat on: I do not believe Les is raising the bar. We
(reg experts) have followed the SHOULD advice rather
consistently. We have always pushed for WG adoption first.
It’s why I mentioned the order, adoption and then allocate,
during the presentation. Yes, SHOULD is not MUST, but it’s
also not MAY. :)
>
> I think it’s worth giving the normal route a chance here
before we look to the exceptional one.
>
> Thanks,
> Chris.
>
>
> On Jul 20, 2026, at 20:12, Tony Li <[email protected]>
wrote:Les,
>
> What I wrote is correct. Please read what you quoted.
That's a SHOULD, not a MUST.
>
> You don't get to raise the bar on a whim.
>
> Tony
>
>
> On Mon, Jul 20, 2026 at 6:36 PM Les Ginsberg (ginsberg) -
ginsberg at cisco.com
<http://cisco.com><[email protected]> wrote:
> Tony –
>
> I don’t want to start an argument – just want to set the
record straight.
>
>
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fisis-tlv-codepoints%2Fisis-tlv-codepoints.xhtml&data=05%7C02%7Cgunter.van_de_velde%40nokia.com%7Cf06d61d690364315423908defc968418%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C639225920576642649%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=O8wTJ%2FkbPXwKL%2FUzwoNmoHT4wYC8qDL5iagbj8fCwB0%3D&reserved=0
<https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml>
states:
>
> “Note
> For IS-IS registries and value ranges maintained via the "Expert
> Review" [RFC8126] registration procedure, guidance for
IESG-designated
> experts can be found in [RFC7370].”
>
> https://www.rfc-editor.org/rfc/rfc7370.html#section-4 states:
>
> “2. The Designated Experts SHOULD only consider requests
that arise
> from I-Ds that have already been accepted as Working
Group
> documents or that are planned for progression as AD
Sponsored
> documents in the absence of a suitably chartered
Working Group.”
>
> So what you say below is not correct.
>
> Les
>
> From: Tony Li <[email protected]>
> Sent: Monday, July 20, 2026 8:50 AM
> To: lsr-chairs <[email protected]>
> Cc: lsr <[email protected]>
> Subject: [Lsr] Adoption of draft-many-lsr-power-group
>
> Hi,
>
> I would like to formally request that we start an adoption
poll of draft-many-lsr-power-group.
>
> I would also like to formally request code point assignment
for this document. The relevant code points are all under
"Expert Review" and do not require formal adoption before code
point allocation. We would greatly prefer not to squat on
code point values if we do not have to.
>
> Regards,
> Tony
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
Green mailing list [email protected]
To unsubscribe send an email [email protected]
