It is not clear that any extension is needed to use the proposed data in
conjunction with SR or multicast. At least for SR, any entity
performing path calculation can take this data into account. For SR or
BIER based multicast, similar conclusions seem to follow. It is not
clear that additional information related to power capability would be
helpful for other multicast control. It is difficult to come up with
ways to address your concerns without somewhat more details.
Yours,
Joel
On 8/19/2026 3:29 PM, Les Ginsberg (ginsberg) wrote:
Joel –
There are multiple examples in the comments I have made that – if
agreed to – would result in non-backwards compatible changes.
In addition, there are areas which have only been mentioned in passing
(e.g., extending to support SR and/or multicast and/or other non-TE
traffic) in the WG discussion that might result in changes to how
things are advertised.
I do not have to come up with a definition of how to address these
unexplored areas in order to be concerned.
Les
*From:*Joel Halpern <[email protected]>
*Sent:* Wednesday, August 19, 2026 10:51 AM
*To:* Les Ginsberg (ginsberg) <[email protected]>; Christian Hopps
<[email protected]>; [email protected]
*Cc:* [email protected]; [email protected];
[email protected]
*Subject:* Re: [Lsr] Re: WG adoption call for
draft-many-lsr-power-group-03 (Ends 2026-08-30)
Les, I am trying to understand your primary concern. Can you give an
example of what you would like this TLV to be able to handle so others
can evaluate whether there is indeed a shortfall? Preferably with
some indication of what sort of information would be needed to handle
the case?
Yours,
Joel
On 8/19/2026 1:43 PM, Les Ginsberg (ginsberg) wrote:
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. 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
o a child group might be advertised referencing a non-existent
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.
_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).
_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.
_References_
The reference section is missing many needed entries.
Les
>-----Original Message-----
>From: Christian Hopps via Datatracker <[email protected]>
<mailto:[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://datatracker.ietf.org/doc/draft-many-lsr-power-group/>
>
>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://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-many-lsr-power-group>
>power-group
<https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-many-lsr-power-group>
>
>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 [email protected]
_______________________________________________
Lsr mailing list -- [email protected]
To unsubscribe send an email to [email protected]
