Hi Aijun! Acknowledging receipt on behalf of the IESG.
Regards, Roman (As IETF Chair for the IESG) From: Aijun Wang <[email protected]> Sent: Wednesday, November 6, 2024 11:31 AM To: [email protected] Cc: [email protected] Subject: Appeal to the IESG re WGLC of draft-ietf-lsr-multi-tlv)(Aijun Wang) Warning: External Sender - do not click links or open attachments unless you recognize the sender and know the content is safe. IESG, As I had promised to the LSR WG, I am contacting you to formally appeal the declaration of WG consensus to progress https://datatracker.ietf.org/doc/draft-ietf-lsr-multi-tlv/ (I am cc'ing the LSR WG for the sake of transparency and openness). * Appellants: Aijun Wang [email protected]<mailto:[email protected]> * Description of the Dispute Draft https://datatracker.ietf.org/doc/draft-ietf-lsr-multi-tlv/ is passing its WGLC, although there are obvious technical issues unsolved. I had summarized the still existing issues within the LSR WG list[https://mailarchive.ietf.org/arch/msg/lsr/ZBf0hBj-oeCWxsztAEXzjIxAaMU/ <https://mailarchive.ietf.org/arch/msg/lsr/ZBf0hBj-oeCWxsztAEXzjIxAaMU/> ]and expected the authors or the WG chairs could response them from technical viewpoints, but there was none, the Chairs just declared that there was already WG consensus. Actually, during the WGLC process, only two non-author-experts expressed explicitly to forward this document. This certainly can’t be called WG consensus. I asked our AD to step in to solve the existing technical issues (https://mailarchive.ietf.org/arch/msg/lsr/PbYIOaF_Jo3lWaOKEn8x8ILxhrA/) and list clearly again the existing issues as the following: ================================= 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. ================================= Our AD responded my request after his laborious review of the overall discussions (https://mailarchive.ietf.org/arch/msg/lsr/Km0Sre4gyrkEubTndBnzt5NqqqU/), quoted some past discussions, but failed to answer the key issues that I raised. I summarized two simple questions regarding to our AD’s responses, and expected he could give some reasonable explanations, but there is no such technical responses. I can only ask the IESG to step in to solve the existing technical issues before forwarding this document, or abandon it if these issues can’t be solved. * Requested Action The WGLC draft(MP-TLV https://datatracker.ietf.org/doc/draft-ietf-lsr-multi-tlv/ <https://datatracker.ietf.org/doc/draft-ietf-lsr-multi-tlv/> )is one simple document, here I want the experts within IESG to review it independently, regardless of the past amounts of discussions, and give us some answers for the following questions: 1) Assuming every vendor has their understanding of “what constitutes a key” for the specific IS-IS code point(because current MP-TLV draft doesn’t provide such information), how can we assure that different vendors have exact the same context for “what constitutes a key”? Lack of such explicit information for “what constitutes a key”, how can we concatenate together correctly the segmented packets that may sent by different vendors? 2) If “what constitutes a key” should be defined in the relevant specific RFCs, or revised RFCs(As the author argued, but both are impossible), what’s the value of this draft then?——the general segmentation/concatenate procedures for one large packet is the well known knob, why bother the IETF to describe (not) new one? 3) If there is no reasonable explanation for the above questions, and there are no other way from MP-TLV proposal to bypass these questions, we should stop to approach such direction to solve the problem. We should instead find other general approaches to solve the problems. If the experts in IESG have any questions need me further clarification, please contact me directly. As the person from the operator, we are worrying extremely the chaos that may be arose in the network if MP-TLV proposal can’t provide “what constitutes a key” information explicitly in their document. Wish to get your professional explanations for the above questions. Aijun Wang
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
