Hi Aijun, Thank you for bringing your concerns regarding draft-ietf-lsr-multi-tlv to my attention. I have now reviewed the extensive email exchanges-hundreds of them-stemming from the WGLC [1] initiated by Yingzhen.
Throughout the WGLC, the topic of "keys" was explored from multiple angles and perspectives. From what I have gathered, it appears that the discussion around "keys" has reached convergence. Here are a few key highlights from the WGLC: * ... this draft has not introduced any modification to the encoding of any existing TLV. The format and the set of sub-TLVs associated with a given codepoint are defined in the respective RFCs for each codepoint and are not altered by this draft. [2] * ... That is why I've said that these points are non-blocking - the document clearly states that these are outside the scope as well. I hope we (the WG) will tackle those aspects in separate document(s). [3] * ... it is not the job of this draft to resolve existing problems in every single TLV in IS-IS. If nothing else, that would turn this document into more of an encyclopedia than it already is. That is simply not practical and not in keeping with how the IETF works. Scalability dictates that issues with specific TLVs should be handled in documents that are specific to the TLV. [4] * ... There always is a key. It is part of each TLV sent even when multi-tlv is not in use. It is processed on receive even when multi-tlv is not in use. It hasn't been changed by multi-tlv. (NOTE: No encoding changes introduced by multi-tlv.) Any interoperability issue related to key processing exists even in the absence of multi-tlv. That understanding is fundamental to understanding how multi-tlv works... [5] * ... It is true that you won't find the word "key" in any of the RFCs which define the existing codepoint formats - but that does not mean we have introduced anything new. Obviously, what uniquely identifies the object of a particular codepoint advertisement differs based on the advertisement type. We introduced the term "key" as a generic term for these codepoint unique values - but as I have been emphasizing this in no way alters the encoding of any TLV/sub-TLV nor does it alter the processing on reception.[6] * ... The only issue I see is if for some existing TLV there were some chance of ambiguity in identifying what data this would be -- and worst case is that we are no better off than before. [7] Here are my takeaways from the WGLC regarding your claims (1), (2), and (3): * The Working Group disagrees with the assertion that no one can understand the keys. * The WG reached consensus that the intent of this document is to clearly describe the generic Multi-TLV mechanism, rather than delve into the specifics of each codepoint. Expanding the scope in that way would make the document unmanageably broad. * The WG agreed that the draft does not introduce any modifications to existing TLVs. Its purpose is to define the general aspects of Multi-TLV, without addressing the nuances of individual codepoints. * The WG concluded that repeating TLV key information within this draft would be, at best, redundant and, at worst, potentially conflicting. Moreover, it would not scale effectively given the large number of codepoints (hundreds) to which Multi-TLV can be applied. * The WG agreed that the examples provided, "Extended IS Reachability" and "Extended IP Reachability," are sufficient to illustrate the intent of what is referenced as a key. These examples are not intended to be exhaustive. * The WG agreed that if a significant interoperability issue arises with a specific codepoint, a separate document would need to be written or updated to address it. Consequently, the WG understands these concerns as non-blocking. Based upon the process guidelines outlined in section 3.3 of "RFC2418 - IETF Working Group Guidelines and Procedures" [8] "Working groups make decisions through a "rough consensus" process. IETF consensus does not require that all participants agree although this is, of course, preferred. In general, the dominant view of the working group shall prevail. (However, it must be noted that "dominance" is not to be determined on the basis of volume or persistence, but rather a more general sense of agreement.) Consensus can be determined by a show of hands, humming, or any other means on which the WG agrees (by rough consensus, of course). Note that 51% of the working group does not qualify as "rough consensus" and 99% is better than rough. It is up to the Chair to determine if rough consensus has been reached." During the Working Group Last Call of draft-ietf-lsr-multi-tlv, I observed a thorough and well-executed discussion, free of any consensus-building errors. The debate was constructive, with relevant technical questions addressed appropriately. As the responsible AD, I see no reason to formally overrule the working group's decision should they choose to forward this document to the IESG for publication. The WGLC was initiated and overseen by Yingzhen, and I have seen no evidence of any unhealthy bias from the LSR chairs. I take accusations made without supporting evidence seriously, particularly when they appear to be unfounded. It is unreasonable and concerning to witness such public accusations that seem aimed at character attacks. I consider this discussion now closed. Kind Regards, Gunter Van de Velde Routing Area Director [1] https://mailarchive.ietf.org/arch/msg/lsr/wumkQrT8CakzJr93M1p-AM3QzT8/ [2] https://mailarchive.ietf.org/arch/msg/lsr/uEY0HEzW4hzxZQhN9adIywwkl1Q/ [3] https://mailarchive.ietf.org/arch/msg/lsr/ZI096yBQWqz_aFz16qGJfNphcCg/ [4] https://mailarchive.ietf.org/arch/msg/lsr/oV_uQMB4JthC0PcZCig7okKeppk/ [5] https://mailarchive.ietf.org/arch/msg/lsr/6PbU-KcARoELuYrrdrs3OnYKn5U/ [6] https://mailarchive.ietf.org/arch/msg/lsr/4cl8AjgcZdj2k6bfo2x2qCd6--Q/ [7] https://mailarchive.ietf.org/arch/msg/lsr/TFsATc3FmJ5QyyntlJGjde7qJHM/ [8] https://datatracker.ietf.org/doc/html/rfc2418#section-3.3 From: Aijun Wang <[email protected]> Sent: Saturday, November 2, 2024 8:57 PM To: Gunter van de Velde (Nokia) <[email protected]> Cc: [email protected] Subject: Request AD to step in to solve the issues that existing in MP-TLV proposal CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi, Gunter: Here I request formally that AD to step in to resolve the issues that existing in MP-TLV proposal https://datatracker.ietf.org/doc/draft-ietf-lsr-multi-tlv/ Along the discussions on the LSR mail list, we can know there are following issues for the MP-TLV proposal: 1) It defines only "what constitutes a key" for two IS-IS TLVs(TLV 22 and TLV 135), there is no such information for other IS-IS TLVs, and also their respective sub-TLVs. 2) The information about "what constitutes a key" is important for any method that segments the packet and concatenate them together. It's even impossible to assure the interoperability from the implementation of different vendors when the standard is lack of such information. 3) Current MP-TLV proposal illustrates also in its section 8.2 (https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-06#section-8.2) that there are other IS-IS TLVs and their respective sub-TLVs may have value length that exceeds 255 bytes, but the authors of this draft admitted publicly that it is impossible to illustrate all the information about "what constitutes a key" for all these TLVs and sub-TLVs. Based on the above information, we can conclude that MP-TLV proposal is one error prone, full of pitfalls solution. I ask the AD to step in to stop to forward this proposal, for the value of IETF community. I ask also AD to restrain the Chair's preference for any proposal from some limited group, but reluctant to give chance for other new UPDATED proposals to make presentation. I want to point out here what the Chair's call WG consensus often come only from the authors of the respective document, not from the most part of LSR WG, even there is unsolved, obvious technical issues existing. Doing so within the LSR WG is not constructive for the discussions and the fruitful output of LSR WG, we expect there will be necessary changes for the administrative of LSR WG. TWO of Chairs of LSR WG come from the same Company, I think it is not helpful for the diversity organization principle of the IETF organization(As I known, there is no such bias WG within IETF). We should make some change for the administrative of LSR WG, to facilitate the active discussions of this WG. Aijun Wang China Telecom _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
