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]>
>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]
