Tony – The next step in this process (as per RFC 7370) is for the WG chairs to indicate to the designated experts that they feel that early allocation should be done at this time.
In the meantime, in the interest of being proactive – I provide the following observations/comments: 1)Regarding the new top level TLV for sleeping adjacencies: You say TLVs “2, 22 and 23” are permitted to be embedded inside the new TLV. Do you really want the legacy narrow metric neighbor TLV (2) to be permitted? Especially given it cannot have any sub-TLVs - like the new Power Group Member sub-TLV – which would seem necessary to make advertisement of the sleeping adjacency useful. Do you really mean to exclude the MT neighbor TLVs 222/223? Perhaps you have no use case now, but excluding them now might be regretted sometime down the road. Given that you have some limitations on what can be embedded I suggest you need a registry to define what TLVs can be embedded. Are there restrictions on what sub-TLVs of the allowed embedded neighbor TLVs are permitted in the embedded advertisement? You have specified “N” for MP – but it seems quite possible that a given embedded neighbor advertisement might be too long to fit within a single Sleeping Adjacency TLV – in which case you would have multiple sleeping adjacency TLVs associated with the same neighbor – which makes it seem like the MP setting ought to be “Y”. ??? 2)In Section 6 you specify the TLVs in which the new sub-TLVs for neighbor advertisements are permitted. But that table is inconsistent with the TLVs that you have specified as allowed to be embedded in the new Sleeping Adjacency TLV. For example, you allow the new sub-TLVs in TLV 222 – but you don’t allow TLV 222 to be embedded in a Sleeping Adjacency TLV. Is this inconsistency intended? If any changes are needed based on these observations, it would be helpful to the early allocation process if an updated version of the draft could be posted. Thanx. Les From: Tony Li <[email protected]> On Behalf Of Tony Li Sent: Tuesday, October 27, 2026 4:10 PM To: Acee Lindem <[email protected]>; lsr-chairs <[email protected]> Cc: lsr <[email protected]> Subject: [Lsr] Re: New Version Notification for draft-ietf-lsr-pcpps-00.txt Hi all, The authors would like to request early allocation of code points as outlined in this draft. Thanks, Tony On Oct 27, 2026, at 4:02 PM, Acee Lindem - acee.ietf at gmail.com <[email protected]<mailto:[email protected]>> wrote: Note that the draft "IS-IS Support For The Power Conserving Path Placement Strategy (PCPPS)" - draft-ietf-lsr-pcpps has been adopted by LSR to support of advertisement of power groups required for the TEAS WG draft "A Power Conserving Path Placement Strategy (PCPPS)" - draft-ietf-teas-power-steering-00. Thanks, Acee Begin forwarded message: From: [email protected]<mailto:[email protected]> Subject: New Version Notification for draft-ietf-lsr-pcpps-00.txt Date: October 27, 2026 at 6:55:16 PM EDT To: "Colby Barth" <[email protected]<mailto:[email protected]>>, "Colby Barth" <[email protected]<mailto:[email protected]>>, "Ron Bonica" <[email protected]<mailto:[email protected]>>, "Ronald Bonica" <[email protected]<mailto:[email protected]>>, "Tony Li" <[email protected]<mailto:[email protected]>>, "Vishnu Beeram" <[email protected]<mailto:[email protected]>>, "Vishnu Pavan Beeram" <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>> A new version of Internet-Draft draft-ietf-lsr-pcpps-00.txt has been successfully submitted by Ron Bonica and posted to the IETF repository. Name: draft-ietf-lsr-pcpps Revision: 00 Title: IS-IS Support For The Power Conserving Path Placement Strategy (PCPPS) Date: 2026-10-27 Group: lsr Pages: 12 URL: https://www.ietf.org/archive/id/draft-ietf-lsr-pcpps-00.txt Status: https://datatracker.ietf.org/doc/draft-ietf-lsr-pcpps/ HTML: https://www.ietf.org/archive/id/draft-ietf-lsr-pcpps-00.html HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-lsr-pcpps Abstract: [I-D.many-teas-power-steering] introduces a Power Conserving Path Placement Strategy (PCPPS). When possible, PCPPS concentrates traffic onto a small set of network resources. When traffic is concentrated onto a small set of network resources, other network resources become idle and can be powered down until they are needed again. This conserves energy and reduces environmental impact. PCPPS uses information that is distributed by an IGP. This document specifies the IS-IS encoding for that information. The IETF Secretariat _______________________________________________ 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]
