Tony – FWIW, I am disappointed in your responses – but how you choose to respond is obviously up to you. Some clarifying remarks inline.
From: Tony Li <[email protected]> On Behalf Of Tony Li Sent: Tuesday, October 27, 2026 5:30 PM To: Les Ginsberg (ginsberg) <[email protected]> Cc: Acee Lindem <[email protected]>; lsr-chairs <[email protected]>; lsr <[email protected]>; Hannes Gredler <[email protected]>; Christian Hopps <[email protected]> Subject: Re: [Lsr] New Version Notification for draft-ietf-lsr-pcpps-00.txt Hi Les, 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? Sure, why not? I’m not seeing a downside. [LES:] A given area can operate either using narrow metric TLVs or wide metric TLVs – not a mixture of both. If you are using narrow metric TLVs, you have no sub-TV support for any neighbor advertisements – which means you cannot advertise any of the link attributes which the PCPPS CSPF (as defined in https://datatracker.ietf.org/doc/draft-ietf-teas-power-steering/) requires. It is therefore difficult for me to see how this protocol extension can be used with TLV 2. 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. If someone is still using narrow metrics, then I see no reason to preclude it. I much prefer to permit too much rather than too little. Would TLV 2 break anything? 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. Yeah, that’s probably a bug. We can discuss. [LES:] I take this to mean you will (at some point) correct this in the draft. Thanx. Given that you have some limitations on what can be embedded I suggest you need a registry to define what TLVs can be embedded. I try to minimize the work that we make IANA do. Is this something that’s likely to change over time? If not, let’s not create overhead. [LES:] What is needed is an accurate definition of what is permitted/prohibited. This bears directly on interoperability. As far as IANA goes, I have never experienced any reluctance on their part to do work that results in a more complete and accurate specification. Are there restrictions on what sub-TLVs of the allowed embedded neighbor TLVs are permitted in the embedded advertisement? Nope. Why tie people’s hands? 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”. ??? Well, I was hoping that people were going to be reasonable and not bother advertising tons of subTLVs for a sleeping link. But theoretically, you are correct. [LES:] I interpret this to mean that you will (at some point) correct this in the draft. Thanx. 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? Bugs are never intended. [LES:] I take this to mean you will (at some point) correct this in the draft. Thanx. 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. I’m failing to see the logic behind that statement. It seems like an excuse not to allocate code points. Those code points will not depend on the nuances that you’ve described. Please allocate the code points and we can haggle about the details later. [LES:] The task of the designated experts and IANA is to make changes to the IANA registries which are deemed compatible with correct protocol operation and are as accurate as possible. Though these allocations are “temporary” – in practice code points once allocated are almost never reused - even if the associated document is abandoned - out of fear of colliding with released code in the wild. Further, changes which sometimes occur as a draft evolves which are incompatible with early definitions are problematic to deal with. We therefore do our best to minimize the chance that this can occur. Having a draft which is as accurate and clear as possible is helpful to this process. Your support in that is appreciated. Les Regards, Tony
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
