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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>> >>> >>> Hannes Gredler <[email protected]> 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 <[email protected]> >>>> 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 >>>> <[email protected]> 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 >>>> <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> 发件人: [email protected] >>>> >>>> [mailto:[email protected]] 代表 >>>> Yingzhen Qu >>>> >>>> 发送时间: 2024年10月12日 3:54 >>>> >>>> 收件人: lsr <[email protected]>; lsr-chairs >>>> <[email protected]> >>>> >>>> 主题: [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 [email protected] >>>> 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 -- [email protected] >>>> To unsubscribe send an email to [email protected] >>> >>> <signature.asc> >> >> _______________________________________________ >> 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]
