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
