Hi Aijun, Feel free to escalate to IESG. Let me know if you need help with the process.
Best Regards, G/ -----Original Message----- From: Aijun Wang <[email protected]> Sent: Wednesday, November 6, 2024 8:07 AM To: Gunter van de Velde (Nokia) <[email protected]> Cc: [email protected] Subject: Re: [Lsr] Re: 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: Thanks for your lengthy reply. Two simple question: 1) Assuming every vendor has their understanding of “what constitutes a key” for the specific IS-IS code point , how can you 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 you 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(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? If you can answer the above questions reasonably, I will withdraw my appeal. Or else, I think the appeal should be escalated to IESG. Aijun Wang China Telecom > On Nov 6, 2024, at 00:50, Gunter van de Velde (Nokia) > <[email protected]> wrote: > > 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] _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
