|
Folks – Speaking as a WG member – not as an author of this draft… The discussion of “key information” and what is required in this draft has a long history. For those of you who have not followed this discussion and/or need a way to catch up, I highly recommend the excellent document shepherd’s report written by Yingzhen. https://datatracker.ietf.org/doc/draft-ietf-lsr-multi-tlv/shepherdwriteup/ This writeup includes extensive references to relevant emails from the WG list. Regarding continued claims that the draft is underspecified, a few key points: 1)The protocol has 25 years of history of successful deployments from multiple vendors of features which are dependent on accurate processing of TLVs which support advertisement
of multiple objects. Specifically, but not exclusively, correct identification of IS Neighbor advertisements to not only a specific neighbor but also a specific link is essential to the operation
of features like RSVP-TE, SR-TE, Flex-Algo, and BGP-LS – as well as correct operation of the base SPF calculation. Other examples (prefixes, capability advertisements) exist. Anyone who claims that the protocol (not just this document) is underspecified in this regard is ignoring (or unaware of) successful use of the protocol for the past 25 years. 2)This draft makes no changes to the encoding of any TLV. It only changes what actions a node takes when receiving multiple TLVS associated with the same object. This is explicitly stated in
https://www.ietf.org/archive/id/draft-ietf-lsr-multi-tlv-08.html#name-multi-part-tlvs . It therefore does not need to update existing TLV definitions. Claims that further specification of key information is required do not stand up to scrutiny based on the above. Anyone claiming there is underspecification MUST provide detail as to: a)Specific codepoint b)Specific information that is underspecified c)An explanation as to why this issue has not been seen in the field in the last 25 years If there is a claim which passes the above scrutiny, it should be addressed in some fashion by the WG – though the most appropriate means is likely to be to update the existing
RFC which defined the codepoint as such an issue affects deployments independent of the use of MP-TLV. However, thus far, in all the discussion of this document, no claim has passed such scrutiny. Les |
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
