Hi, Les: I missed this mail and notice it in just several minutes ago. To distinguish this discussion with other threads, I update the title to make it more outstanding and relevant. I copy it also to IESG mail list for further discussions. Let me give you the information you want for the discussions, it is also one example in your document, but you try to shun it when we compare the discussed version 06 and your latest Last-Call version of 07 and 08: a) Specific codepoint “Extended IS Reachability”(type 22) b) Specific information that is underspecified “The key information”. Currently, in your document, you described just as “The key consists of 7 octets of system ID and pseudocode number plus the set of link identifiers which are present” But there is no any description for the “key” in its original RFC document for this IS-IS TLV(type 22). And, in your document at the same section, you described(I don’t know is there any RFC document it, if you can point out, I appreciate your information): “Optionally one or more of the following link identifiers: Then, come the question, as that I raised to Ops area experts Giuseppe at https://mailarchive.ietf.org/arch/msg/lsr/Fv7U9msEm9-sUrzOOm0iO7RoIVY/: For the sender, which link identifiers should be included? If different part of the MP-TLV uses the different link identifiers, they will all be valid “Extended IS Reachability” TLV, should the receiver threat them as MP-TLV to concatenate them together, or treat them as multi occurrence of the same TLV, replace the previous one with the newest occurrence? c) An explanation as to why this issue has not been seen in the field in the last 25 years For Non MP-TLV scenario, there will be no problem----Normally, different link can use different link identifier set, the sender/receiver can associate the related link parameter sub-TLV to the link that identified by the identifier. But, for MP-TLV scenario, it is different story, the sender/receiver MUST agree on the “key” of the link identifier, which is emphasized in your version 6 document (https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-06#name-example-extended-is-reachab), but delete it in the newer version. Or else, the attributes information for one link can’t be associated together. I expect we, or the IESG experts, or other interested experts to join in the technical discussions, to solve the ambiguity and potential challenges for its possible deployment in operator network. I know, from the POV of the vendor, such protocol can be implemented, but we should consider its possible deployment challenges, or else, it will be just shelved in the IETF repository. Network Protocol Standard/RFC Should Consider more its Deployment Challenges. Best Regards Aijun Wang China Telecom 发件人: Les Ginsberg (ginsberg) [mailto:ginsberg@xxxxxxxxx] 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
