Les, > 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.
Again, I’m not seeing a downside. Yes, I’ll stipulate that there’s no significant functional benefit. However, I’m not seeing a problem with it. For the sake of generality and abstraction, it makes sense to allow all of the adjacency TLVs. What breaks if someone advertises a sleeping adjacency with TLV 2? AFAICT, nothing. > 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. They are certainly willing. The question is whether we should make them jump through pointless hoops. Will this registry ever change? If not, there’s no point. > 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. The point of early allocation is to allocate the code points before the draft is set in stone as an RFC. That means that the details may change while the WG discusses the draft. Allocation MUST NOT be gated by the details of the draft, that would completely defeat the point of early allocation. Regards, Tony
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
