Hi Aijun, The chairs have declared rough consensus on this issue, you need to stop repeat posting this to the WG mailing list. Please respect the IETF process.
Thanks, Chris. [as wg-chair] > On Nov 1, 2024, at 23:00, Aijun Wang <wangai...@tsinghua.org.cn> wrote: > > Hi, Chris: > > Until now, I haven’t heard you, and also other experts for the technical > analysis of UPDATED big-TLV > solution(https://datatracker.ietf.org/doc/draft-wang-lsr-isis-big-tlv/) > > Lack of such technical analysis, any subjective conclusion is untenable. > > It’s same as declaring again and again the MP-TLV can solve the problem, even > in short term. > > If possible, I can argue with the authors, or you Chairs for the unsolved > issues that existing in MP-TLV proposal face to face during the IETF 121 > meeting time. > > Aijun Wang > China Telecom > >> On Oct 31, 2024, at 21:24, 【外部账号】Christian Hopps <cho...@chopps.org> wrote: >> >> Hi Aijun, >> >> [as wg-member] Please see Henk Smit’s response. I fully support what he >> said. We have a short term solution that the WG agrees is sufficient, and it >> is explicitly not Big TLV. Likewise container TLVs are not a long-term >> elegant solution. >> >> Thanks, >> Chris. >> >>> On Oct 28, 2024, at 09:22, Aijun Wang <wangai...@tsinghua.org.cn> wrote: >>> >>> Hi, Chris: >>> >>> Let’s discuss your proposal and Les’s responses more further. >>> >>> First, depending on RFC7356 to solve the potential problem is not >>> practicable—You must define all the new types for possible big IS-IS TLV, >>> and also their relevant sub-TLVs. >>> It’s obviously not the candidate solution. >>> >>> On the contrary, the updated Big-TLV >>> proposal(https://datatracker.ietf.org/doc/draft-wang-lsr-isis-big-tlv/) >>> needs only to define one new generic TLV to solve all possible big-TLV >>> problem, and also their sub-TLVs. >>> >>> Second, regarding to Les’s responses at >>> https://mailarchive.ietf.org/arch/msg/lsr/iL-3bd3LC9ZfYftZUyky3bWyX4E/: >>> >>> “ This is why some RFCs left the choice in such cases to the implementor. >>> I mention this only to avoid an argument about trying to retrofit this >>> model to codepoints where this choice was not made. It isn’t worth the >>> trouble and would instantly render some implementations non-conformant >>> without significant benefit.” >>> >>> It’s possible that there are in private negotiation among different vendors >>> when there are interoperability issues from such implicit “what constitutes >>> a key”, such situations will be deteriorated when these TLV/sub-TLVs are >>> sliced according to the MP-TLV proposal. >>> >>> The MP-TLV proposal will amplify such non-conformant issues. >>> >>> It’s time to find one general solution to Big-TLV problem. >>> >>> Aijun Wang >>> China Telecom >>> >>> >>> Aijun Wang >>> China Telecom >>>> >>>> >>>> On Oct 26, 2024, at 20:09, 【外部账号】Christian Hopps <cho...@chopps.org> wrote: >>>> >>>> >>>> Hannes Gredler <han...@gredler.at> writes: >>>> >>>>> Why are we having this discussion again ? >>>>> >>>>> My recollection is that we have a “good enough” solution that is >>>>> deployed and interoperable. >>>>> If you want the “generic solution” then the 16-bit TLVs described in >>>>> RFC7356 is the way to go forward and if there is concern about >>>>> incremental deployment then we should work on this aspect. >>>> >>>> I also believe the 16 bit solution is the way forward if people wish to do >>>> any more on this at this point. >>>> >>>> Thanks, >>>> Chris. >>>> [as wg-member] >>>> >>>> >>>>> >>>>> /hannes >>>>> >>>>> >>>>> >>>>> On 23.10.2024, at 00:50, Aijun Wang <wangai...@tsinghua.org.cn> >>>>> wrote: >>>>> >>>>> Hi,Chris: >>>>> >>>>> Please elaborate clearly your technical reviews for the updates >>>>> of the newly proposed Big-TLV solution. >>>>> >>>>> I can copy the updates again at here and state their effects >>>>> clearly.(https://mailarchive.ietf.org/arch/msg/lsr/ >>>>> dxK4Gy1WDR7QCXK6p58xgA0MdUc/ )Please give your analysis before >>>>> you make any conclusions: >>>>> >>>>> >>>>> A new version of Big-TLV document has been >>>>> posted(https://datatracker.ietf.org/doc/html/draft-wang-lsr-isis-big-tlv), >>>>> to try to give the community one general way to solve the Big TLV >>>>> problem. >>>>> >>>>> The main changes from the previous versions are the followings: >>>>> 1) Add one "Identification" field within the container TLV(type TBD1), >>>>> to function as the key for any sliced TLV, and is TLV code point >>>>> independent. >>>>> 2) Add one "Flag" field, define currently the "F" bit to indicate >>>>> whether the piece of container is the first piece(F bit is set to 1), or >>>>> not (F bit is unset) >>>>> 3) Put all the sliced pieces within the newly defined container >>>>> TLV(type TBD1). >>>>> 4) Define some rules for the "Split and Glue" procedures(may be >>>>> re-optimizer later after the WG discussions) >>>>> >>>>> The updated version erases the necessity of defining the "key" >>>>> information for every IS-IS (Possible Big) TLV code point, and also the >>>>> necessity of per-TLV capability announcement. >>>>> >>>>> >>>>> I would like to hear your detail analysis, especially as the WG chairs, >>>>> for the above statements. >>>>> >>>>> Aijun Wang >>>>> China Telecom >>>>> >>>>> >>>>> On Oct 22, 2024, at 20:15, 【外部账号】Christian Hopps >>>>> <cho...@chopps.org> wrote: >>>>> >>>>> >>>>> Those changes don't appear to address what the WG already >>>>> decided against. The view of the WG was that a new Big TLV >>>>> for doing this was not going to work. Given the name of this >>>>> work is Big TLV, that doesn't seem to have changed. So why >>>>> should the WG be spending even more time on a solution they >>>>> already discussed, debated and discarded? >>>>> >>>>> Thanks, >>>>> Chris. >>>>> [as wg chair] >>>>> >>>>> >>>>> >>>>> On Oct 22, 2024, at 06:47, Aijun Wang >>>>> <wangai...@tsinghua.org.cn> wrote: >>>>> >>>>> >>>>> >>>>> Hi, Chris: >>>>> >>>>> >>>>> >>>>> No, we have made some significant updates. >>>>> >>>>> Please refer to https://mailarchive.ietf.org/arch/msg/lsr >>>>> /dxK4Gy1WDR7QCXK6p58xgA0MdUc/ for more information. >>>>> >>>>> >>>>> >>>>> Aijun Wang >>>>> >>>>> China Telecom >>>>> >>>>> >>>>> >>>>> On Oct 22, 2024, at 17:04, 【外部账号】Christian >>>>> Hopps <cho...@chopps.org> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Is this the same thing that Huaimo has already >>>>> presented to the WG, that the WG decided was not the >>>>> way it wanted to go? >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Chris. >>>>> >>>>> >>>>> >>>>> "Aijun Wang" <wangai...@tsinghua.org.cn> writes: >>>>> >>>>> >>>>> >>>>> Hi, Yingzhen: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I would like to request 10-15minutes to make the >>>>> presentation for the >>>>> >>>>> “IS-IS Extension for Big TLV” >>>>> >>>>> >>>>> >>>>> The related information are the followings: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Draft Name: IS-IS Extension for Big TLV >>>>> >>>>> >>>>> >>>>> Link: https://datatracker.ietf.org/doc/ >>>>> draft-wang-lsr-isis-big-tlv >>>>> >>>>> / >>>>> >>>>> >>>>> >>>>> Presenter: Aijun Wang >>>>> >>>>> >>>>> >>>>> Desired Slot Length: 10-15minutes. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Best Regards >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Aijun Wang >>>>> >>>>> >>>>> >>>>> China Telecom >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> 发件人: forwardingalgori...@ietf.org >>>>> >>>>> [mailto:forwardingalgori...@ietf.org] 代表 >>>>> Yingzhen Qu >>>>> >>>>> 发送时间: 2024年10月12日 3:54 >>>>> >>>>> 收件人: lsr <lsr@ietf.org>; lsr-chairs >>>>> <lsr-cha...@ietf.org> >>>>> >>>>> 主题: [Lsr] IETF 121 LSR Slot Requests >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The draft agenda for IETF 121 has been posted: >>>>> >>>>> >>>>> >>>>> IETF 121 Meeting Agenda >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The LSR session is scheduled on Thursday Session >>>>> I 09:30-11:30, Nov 7th, 2024. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Please send slot requests to lsr-cha...@ietf.org >>>>> before the end of the day >>>>> >>>>> >>>>> >>>>> Wednesday Oct 23. Please include draft name and >>>>> link, presenter, desired >>>>> >>>>> >>>>> >>>>> slot length including Q&A. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> >>>>> >>>>> Yingzhen >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Lsr mailing list -- lsr@ietf.org >>>>> To unsubscribe send an email to lsr-le...@ietf.org >>>> >>>> <signature.asc> >>> >>> _______________________________________________ >>> Lsr mailing list -- lsr@ietf.org >>> To unsubscribe send an email to lsr-le...@ietf.org >> >> _______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
