Les,
Thanks for your careful review.
I see that you and Joel are engaging regarding the first part of your comment.
I will respond to the rest, inline [rb].
Ron
________________________________
From: Les Ginsberg (ginsberg) <[email protected]>
Sent: Wednesday, August 19, 2026 1:43 PM
To: 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)
Regarding WG adoption...
This draft is certainly relevant to the WG.
But the current definition addresses the needs of only one type of traffic - TE
unicast traffic (as has been pointed out by others). I think the solution has
the potential to be applicable to other types of traffic. But the current TLV
definitions are so TE focused that extending the solution to other scenarios
would be likely to require non-backwards compatible changes. WG adoption makes
it more likely that early implementations will be deployed - as reinforced by
the authors' publicly stated intent to "ship this version". Which means that
introduction of non-backwards compatible changes as work continues will meet
resistance (for practical reasons).
If the draft were in a more mature state, the risks would be less.
Which is why I would prefer that the document remain an individual contribution
until it becomes more encompassing.
Putting that aside, here are some comments on the current content of the
document.
Section 3.1
Defines a new Power Group TLV.
As defined it allows for only a single power group to be defined/TLV - not the
most efficient encoding.
[rb] Good point. In the next version, I will change the syntax of the Power
Group TLV so that it can carry multiple Power Groups
Also, given that Power Groups can be defined in a hierarchy (see
draft-many-teas-power-steering) it suggests that the Power Group TLV could
define a (sub)tree of the power group hierarchy. Whether this change is made or
not, there are potential ambiguities:
o the same child power group might be advertised referencing multiple parents
[rb] I will add some text here. The syntax does not allow for a node to
advertise a Power Group with multiple parents.
o a child group might be advertised referencing a non-existent parent
[rb] I will add some text here. If a node advertises a child with a
non-existent parent, it is out of protocol. If a node receives such an
advertisement, it should assume that the child has no parent.
Handling of these cases is not discussed.
Section 3.2
Defines a new Sleeping Adjacencies TLV
The very cryptic definition suggests that it is simply a wrapper which contains
potentially multiple (previously) non-sleeping adjacencies. Which raises
multiple questions/concerns.
Is the format of the contained "TLVs" simply a copy of the TLV as it was
previously advertised when it was non-sleeping?
If so, how can the MP flag be defined as "N" (as it is in the IANA section)?
The encoding, if it is indeed just a copy of the non-sleeping state, results in
considerable unnecessary duplication e.g., the link endpoints are independent
of the MTID.
While it is understandable that it may be desirable/necessary for some link
attributes to be advertised in the sleeping state, there are a number of link
attributes for which advertisement while in the sleeping state is unnecessary.
For example, advertisements of dynamic performance measurements (Unidirectional
Link Delay, Min/Max Unidirectional Link Delay, Unidirectional Delay Variation,
Unidirectional Link Loss) have no real meaning in the powered off state.
There is also no discussion as to how the identity of the neighbor on a
sleeping link remains valid across events such as reloads - when post reload
the neighbor link might still be in a sleeping state and so not discoverable.
Presumably Sleeping Adjacency TLVs are ignored when a matching non-sleeping
adjacency is also advertised?? There is no discussion of this.
[rb] I will add some text here. For generality, we accept all of the neighbor
sub-TLVs, however, they are not necessarily semantically significant. This
makes copying the previous adjacency legal. The MP flag should be “Y”.
[rb] A sleeping adjacency is not guaranteed to be valid. The neighbor may have
crashed, for example. A two-way check is still advisable.
[rb] A sleeping adjacency and a non-sleeping adjacency for the same adjacency
should not be advertised simultaneously.
Section 3.3
Defines a Power Group Member sub-TLV - and allows multiple such TLVs to account
for LAGs. But in the absence of information identifying which LAG member is
associated with which power group, it seems difficult to use this at Layer 3
interface level in other than an all or nothing manner - which suggests a
single sub-TLV with a list of Power Group Identifiers is more appropriate.
Power Group Identifiers advertised in TLV 25 (L2 bundle members) naturally
associate the bundle member with the Power Group. Which suggests that the Power
Group advertised at Layer 3 would be the parent of all the Layer 2 member power
groups - and that would be expressed in the Power Group TLV (Section 3.1).
[rb] I will add some text. The purpose of this TLV is not to advertise the
mapping between a LAG and its members. To do so would break the Layer 3
abstraction. The purpose of this TLV is to advertise the mapping between a
Layer 3 interface and the Power Group(s) that support it. If all of the Layer 3
interfaces that a Power Group supports are asleep, the Power Group can also be
put to sleep.
[rb] This TLV has nothing to do with putting individual members of a LAG to
sleep
Section 3.3.3
Defines a new Unidirectional Sleeping Bandwidth sub-TLV.
I would assume that this sub-TLV should be ignored if sent in a non-sleeping
Neighbor TLV advertisement?? (Text does not say)
Which is related to the earlier discussion about the Sleeping Adjacencies TLV
as to what link attribute information is actually required when advertising a
sleeping adjacency.
And given that a link cannot be "partially asleep", why wouldn't the bandwidth
sub-TLVs defined in RFC 8570 which indicate how much bandwidth is utilized be
sufficient to indicate "sleeping bandwith" when advertised in a sleeping
adjacency TLV.
[RB] The Unidirectional Sleeping Bandwidth TLV is useful for LAGs only. It
tells us how much sleeping bandwidth is available on the LAG (but not how many
or which members are asleep). RFC 8570 does not tell us anything about sleeping
bandwidth on a LAG.
References
The reference section is missing many needed entries.
[rb] Which? I would be glad to add them.
Les
>-----Original Message-----
>From: Christian Hopps via Datatracker <[email protected]>
>Sent: Sunday, August 16, 2026 5:57 PM
>To: [email protected]
>Cc: [email protected]; [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://datatracker.ietf.org/doc/draft-many-lsr-power-group/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-many-lsr-power-group/__;!!NpxR!k_7ivKHhXlD8IMcb4mau5zBd52Ibq2rZa9enanUC5tYVhOutGumiwv8KB1VdZgb1XfiW7Fsc9qOgVjoU$>
>
>Please indicate your support or objections by August 30th, 2026.
>
>An IPR declaration has been made
>
>
> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-many-lsr-<https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-many-lsr-power-group__;!!NpxR!k_7ivKHhXlD8IMcb4mau5zBd52Ibq2rZa9enanUC5tYVhOutGumiwv8KB1VdZgb1XfiW7Fsc9jVGksSO$>
>power-group<https://urldefense.com/v3/__https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-many-lsr-power-group__;!!NpxR!k_7ivKHhXlD8IMcb4mau5zBd52Ibq2rZa9enanUC5tYVhOutGumiwv8KB1VdZgb1XfiW7Fsc9jVGksSO$>
>
>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]
