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. > 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. > 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. > 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. > 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. > 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. Regards, Tony
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
