> On Feb 25, 2025, at 7:49 PM, Aijun Wang <wangaijun@xxxxxxxxxxxxxxx> wrote: > > Hi, Acee: > > We are trying to solve the limitation of traditional IS-IS TLV, that the length of the TLV can't exceed 255 bytes. > Then you support the proposal that unleashes the unlimited boundary length of such TLV. > Please tell me in which protocol, in which LSP, or in which TLV's definition, there is no "length" field associated the packet format? OSPFv3 allows multiple router-LSAs (with a different Link State IDs) to be advertised and these are concatenated during the SPF computation. There is no aggregate LSA length and given that the Link State ID space is far larger than the LSP ID space and that LSPs are limited in length by the link MTU (IS-IS doesn't run over IP as asserted in your "challenges" draft), this could potentially result in a much greater amount of protocol state. This is just one example. Note that the IETF Last Call has ended so please quit repeating your points or further action will be required. Thanks, Acee > > Please don't blame the implementation, but just rectify the proposal. > > > Best Regards > > Aijun Wang > China Telecom > > -----邮件原件----- > 发件人: Acee Lindem [mailto:acee.ietf@xxxxxxxxx] > 发送时间: 2025年2月26日 1:33 > 收件人: Aijun Wang <wangaijun@xxxxxxxxxxxxxxx> > 抄送: lsr <lsr@xxxxxxxx>; The IESG <iesg@xxxxxxxx>; last-call <last-call@xxxxxxxx> > 主题: Re: [Lsr] New Version Notification for draft-wang-lsr-unsolved-challenge-of-mp-tlv-00.txt【Relate to Last Call of draft-ietf-lsr-multi-tlv】 > > Again speaking as WG chair: > > Note that we're not going to spend any more LSR WG time these "challenges" as they have already been discussed. The WG is done with IS-IS MP TLV and we are moving on to other work. > > With respect to memory exhaustion, obviously if an implementation has a bug, then this can be a problem. Similar to packet corruption, implementations should defensively protect themselves from exhausting memory due to a buggy implementation sending too much protocol state. > > Thanks, > Acee > > >> On Feb 25, 2025, at 4:32 AM, Aijun Wang <wangaijun@xxxxxxxxxxxxxxx> wrote: >> >> Hi, All experts: >> >> I drafted one document to summarize the unsolved challenges for the proposal of https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-10 >> Wish it can help the reviewer and IESG experts to evaluate this document in more neutral mode. >> Let's stop the forwarding of this document that can lead only the chaos within the operator's network. >> >> >> Best Regards >> >> Aijun Wang >> China Telecom >> >> -----邮件原件----- >> 发件人: internet-drafts@xxxxxxxx [mailto:internet-drafts@xxxxxxxx] >> 发送时间: 2025年2月25日 17:26 >> 收件人: Aijun Wang <wangaj3@xxxxxxxxxxxxxxx> >> 主题: New Version Notification for draft-wang-lsr-unsolved-challenge-of-mp-tlv-00.txt >> >> A new version of Internet-Draft >> draft-wang-lsr-unsolved-challenge-of-mp-tlv-00.txt has been successfully submitted by Aijun Wang and posted to the IETF repository. >> >> Name: draft-wang-lsr-unsolved-challenge-of-mp-tlv >> Revision: 00 >> Title: Unsolved Challenges of IS-IS MP-TLV Proposal >> Date: 2025-02-25 >> Group: Individual Submission >> Pages: 8 >> URL: https://www.ietf.org/archive/id/draft-wang-lsr-unsolved-challenge-of-mp-tlv-00.txt >> Status: https://datatracker.ietf.org/doc/draft-wang-lsr-unsolved-challenge-of-mp-tlv/ >> HTMLized: https://datatracker.ietf.org/doc/html/draft-wang-lsr-unsolved-challenge-of-mp-tlv >> >> >> Abstract: >> >> The IS-IS routing protocol uses TLV (Type-Length-Value) encoding in a >> variety of protocol messages. The original IS-IS TLV definition >> allows only for 255 octets of value in maximum. MP-TLV >> [I-D.ietf-lsr-multi-tlv] gives one proposal trying to solve this >> issue, but has some unsolved challenges for its implementations and >> deployment. This document analyzes in detail these challenges and >> proposes the community to find other better solution. >> >> >> >> The IETF Secretariat >> >> >> >> _______________________________________________ >> Lsr mailing list -- lsr@xxxxxxxx >> To unsubscribe send an email to lsr-leave@xxxxxxxx > > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
