Hi, Mike: I agree with you that " it would be nice to have a crisper definition of the "key" for each TLV," but not the " the WG consensus that the key for each relevant TLV is sufficiently clear to implementers in practice."
Let me state the logic/reasoning more clearly(wish it will also help other experts to understand. If there is any mistake for the following statements, ANYONE can standout make it more clear, or correct me): 1) There is no 'key' definition on 'each relevant TLV(include also sub-TLV, sub-sub-TLV) in current related IS-IS RFCs. If there is any, please show the community the pointer. 2) The latest version(version 16) states the above point clearly: " Also, the term "key" is a generic term which is not used in the relevant specifications."----I MUST point out, other equivalent descriptions that have the same function don't exist also. 3) Only this under-reviewed MP-TLV document provides the ‘key’ definition for two TLVs： TLV 22 and TLV 135. 4) Even for these newly defined 'key' information for TLV 22 and TLV 135, there is ambiguous( I have given the example at https://datatracker.ietf.org/doc/html/draft-wang-lsr-unsolved-challenge-of-mp-tlv-01#section-3.1) And, when I read carefully again the newest (version 16) MP-TLV document and RFC 5305(which defines the TLV 22 and TLV 135 firstly) again, I found another ambiguous, even for TLV 135: 1) In MP-TLV document, it states(newly defines) that " The key consists of the 6 bits of prefix length plus 0-4 octets of IPv4 prefix.", 2) But in RFC 5305, it states: " The prefix is encoded in the minimal number of octets for the given number of significant bits. The remaining bits of prefix are transmitted as zero and ignored upon receipt." 3) Then comes the ambiguous: if the "significant bits" is 27, the prefix must be encoded in 4 Octets. 4) What the remaining bit should be encoded?-----The sender can encode it in any way, even for the pieces of the same MP-TLV instance, does not violate the guideline of MP-TLV and RFC 5305. 5) This will not arise interoperability issues for the non-MP-TLV scenario. But for the MP-TLV scenario, the receiver can't ignore the remaining bits upon receipt if such remaining bit is also the parts of the 'key' for the MP-TLV pieces. Here is the summary for the overall discussions until now: For every raised issue, I give the very detail example, analysis and reasoning for the unsolved challenges, but there is no any experts stand out to answer them in the same detail, analysis and reasoning. This shouldn't be the style of IETF community, which always focus on the discussions on technical arguments, although there are other non-technical issues that want to dominate/change the IETF traditional traits. I don‘t want to repeat in detail other unsolved challenges again, just list them here for reminder(nest encapsulation efficiency, unlimited boundary attack, misguided MP-TLV capabilities advertisement) If the IESG pass this document even notice these unsolved challenges, I will try to raise it to IAB for the discussions of these technical arguments, according to the procedures described in https://datatracker.ietf.org/doc/html/rfc1603#section-3.4 I will not argue the overall process of this document, only the above technical arguments. If ANY expert can STAND OUT to give the "detail example, analysis and reasoning" about these points, I would like to hear. I would like also the IESG/IAB hold one public hearing meeting(it will be more efficient) in future for these arguments to this MP-TLV proposal. Best Regards Aijun Wang China Telecom -----邮件原件----- 发件人: [email protected] [mailto:[email protected]] 代表 Mike Bishop via Datatracker 发送时间: 2025年4月17日 0:10 收件人: The IESG <[email protected]> 抄送: [email protected]; [email protected]; [email protected]; [email protected] 主题: [Lsr] Mike Bishop's No Objection on draft-ietf-lsr-multi-tlv-16: (with COMMENT) Mike Bishop has entered the following ballot position for draft-ietf-lsr-multi-tlv-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-multi-tlv/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I had previously reviewed this document, as well as another objecting to it, in the course of understanding the appeal that was raised. While it would be nice to have a crisper definition of the "key" for each TLV, I understand and agree with the WG consensus that the key for each relevant TLV is sufficiently clear to implementers in practice. This document acknowledges and formalizes an existing workaround actively being used, and existing successful interoperation is the best evidence that this is clear to implementers. _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
