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]<mailto:[email protected]> >Cc: [email protected]<mailto:[email protected]>; >[email protected]<mailto:[email protected]>; >[email protected]<mailto:[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/ > >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]<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]
