Hi, Chris: Thanks for sharing your thoughts for the past discussions. The reason that the previous Big-TLV proposal doesn't win the debates in past is that it has the same "key" definitions requirements for every possible big IS-IS TLV, as that in the current approach of MP-TLV solution.
But, the above "key" definition for every possible big IS-IS TLV requirements DOESN'T EXIST now, then the updated Big-TLV proposal has the obvious advantage over the current MP-TLV solution. It's time to reevaluate the two approaches within the WG. The main challenge for the MP-TLV approach is that it still requires the specific "key" definition for each possible big IS-IS TLV, which is non-extensible, non-deployable/operational(considering its ambiguous declaration of "MP-TLV capabilities" is type independent instead). Best Regards Aijun Wang China Telecom -----邮件原件----- 发件人: [email protected] [mailto:[email protected]] 代表 Christian Hopps 发送时间: 2024年10月23日 10:57 收件人: Aijun Wang <[email protected]> 抄送: 【外部账号】Christian Hopps <[email protected]>; Yingzhen Qu <[email protected]>; lsr-chairs <[email protected]>; [email protected]; lsr <[email protected]> 主题: [Lsr] Re: It's time to find one general solution to Big-TLV problem Re: IETF 121 LSR Slot Requests Hi Aijun, [as-wg-member]: Perhaps you don't recall, but if you go review all the email threads and presentations/video you will see that I was a supporter of Huaimo's idea originally. [as-wg-member]: However, I also accepted that I was "in the rough" and the WG did not agree with using a new TLV for this problem. The WG has a different solution that you do not agree with, but that doesn't change the WG rough consensus. Thanks, Chris. Aijun Wang <[email protected]> writes: > 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]
