Ron - Thanx for your reply. Your suggested updates sound good to me.
A few responses inline. From: Bonica, Ron <[email protected]> Sent: Thursday, August 20, 2026 10:27 AM To: Les Ginsberg (ginsberg) <[email protected]>; Christian Hopps <[email protected]>; lsr <[email protected]>; [email protected]; lsr-chairs <[email protected]>; [email protected] Subject: RE: [Lsr] WG adoption call for draft-many-lsr-power-group-03 (Ends 2026-08-30) 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]<mailto:[email protected]>> Sent: Wednesday, August 19, 2026 1:43 PM To: Christian Hopps <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[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. [LES:] OK - that is sensible. Two-way check should be sleeping-adjacency to neighbor sleeping adjacency - not sleeping adjacency to adjacency. And some expected transition time should be allowed since the two neighbors may not transition at the same moment. Which raises another question: If one side of the adjacency goes into sleep mode - but the other does not - then the two way check will fail. Which means this only works when both sides of the adjacency are put to sleep - although power savings are still achieved when only one node goes to sleep. Perhaps this deserves some discussion? [rb] A sleeping adjacency and a non-sleeping adjacency for the same adjacency should not be advertised simultaneously. [LES:] Agreed. Some text to clarify how this should be handled would be helpful. Do you prefer the sleeping adjacency or the non-sleeping adjacency? Or ignore both? Which relates to the comment I made for the preceding point. 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. [LES:] OK - rereading the section I sort of get that. But clarification would help. If you make the change you say you will do in Section 3.1, I think you could also advertise many power groups in this sub-TLV as well (rather than many sub-TLVs)? [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. [LES:] OK - so this meant to appear in neighbor TLVs - not sleeping neighbor TLVs. References The reference section is missing many needed entries. [rb] Which? I would be glad to add them. [LES:] This is an editorial comment - and as such may get addressed naturally in later versions. But any codepoint you reference would seem to require a reference to the RFC that defines it. "Link Attribute Sub-TLV (19)" is mentioned in Section 3.3.4 and therefore requires a reference to RFC5029. I was thinking you had references to the various neighbor TLVs - but currently you don't other than in the IANA section. If that changes as a result of your edits, then additional references may be required. You may also need some explanation of what sub-TLVs are allowed in the new Sleeping Adjacency TLV. Not sure how IANA will view this since the new TLV is currently simply a container for the existing neighbor TLVs. And your responses above suggest that you are not restricting what sub-TLVs may be in the contained Neighbor TLVs - but you might want a discussion of which ones are "significant" and which ones are not. This gets into nitty-gritty details which might impact interoperability. I respect the fact that it may a bit early for this level of specification - but probably will be needed eventually. Les 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/<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]
