Speaking as WG chair: My recollection is that there were few that wanted the Big-TLV solution as it offered no advantages over the currently deployed multi-part TLV solution.
I don’t see that adding an identifier changes the prior consensus and, if anything, makes the Big-TLV more complex and costly to implement and test. Since my implementation and deployment experience is primarily in OSPFv(2|3) I’d appreciate those with more IS-IS experience (both implementation and deployment) to chime in. Thanks, Acee > On Oct 22, 2024, at 18: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/ > > <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) > <http://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]
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
