Speaking as WG member: I also agree totally with this technical summary on the preferred short and long term solutions.
I'd add that the motivation for a cleaner long-term solution hasn't heretofore been strong enough to override the backward compatibility and effort. Given that we haven't move forward on a "good" long-term solution, we certainly aren't going to accept a bad one. > On Oct 31, 2024, at 9:26 AM, Henk Smit <henk.i...@xs4all.nl> wrote: > > Please stop. > > I suggest we can have a container TLV No. There are two types of > problems. > 1) Short-term problems. Which have to be fixed asap. 2) Long-term problems. > Which need a proper solution. Container TLVs are not a good short-term > solution, and not a good long-term solution. The split TLV problem has been > solved for the short term. The multipart-TLV fix has been implemented by > multiple vendors. It has been deployed in multiple production networks. > It works. There is no need for a 2nd short-term solution. Your 2nd solution > also is not backwards compatible. So it has no benefits of the multipart-TLV > solution. > I see 0 benefit of having container TLVs over the multipart-TLV solution. > Neither do most other people here in the working-group. Can you not clearly > see that when you read the responses? If we want to think of a better > solution, we should fix this properly. > As Hannes already suggested: the proper fix is to bump the IS-IS protocol > version, and have 16-bit Type and 16-bit Value TLVs. > This is a huge change. And not backwards compatible. I am a fan of rule #12 > in RFC 1925. Keep your protocols simple. 16-bit Types and 16-bit Value TLVs > are a simple concept. They don't change anything to the algorithms or > behaviour of IS-IS. It's just "a small matter of programming" to implement > them. My countryman Edsger Dijkstra (you might have heard of him) Perhaps not everyone.... Thanks, Acee > has said this: > ".Elegance is not a dispensable luxury but a factor that decides between > success and failure." > Elegance means: simple and yet effective. Multipart TLVs are an ugly hack, > imho. But so are container TLVs. > We already have a (working and deployed) short-term solution. > If we're gonna have a 2nd solution, it should be elegant. Not yet another > hack. > Just my own opinion. > Not my employer's. But I think both my colleagues, as well as most other > people on this list, agree with me. > Kind regards, > henk. > >> >> On 10/31/2024 6:28 AM CET duzongp...@foxmail.com <duzongp...@foxmail.com> >> wrote: >> Hi, Aijun and Chiris >> Some personal understanding to share. If any misunderstanding, please >> correct me. Thanks in advance. >> I agree that the MP-TLV in draft-ietf-lsr-multi-tlv can work here. >> However, I agree that we also need a more general way. In addition, I >> suggest we can have a container TLV with a CSN (container sequence number). >> Therefore, it create anther layer for the encapsulation of the big TLV. >> Perhaps it has similar function to the Identification in the current >> draft-wang-lsr-isis-big-tlv . I do not think they are very completed. >> Perhaps more discussion is needed here. For example, we have a TLV >> type 16 and length 16, we can encapsulate it in several container TLVs with >> type 8 and length 8. Figure1: A type 16 and length 16 TLV >> 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type (T) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --+ >> | Piece 1 (less than 248 octets)| | >> ~ ~ | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> | Piece 2 (less than 252 octets)| | >> ~ ~ Bigger than >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 octets >> ~ : ~ | >> ~ . ~ | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | >> | Piece n (less than 252 octets)| | >> ~ ~ | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --+ >> >> After encapsulation >> 0 1 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --+ >> | Type (TBD1) | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --+ >> | container sequence number =1 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type (T) =16 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Length =16 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - >> | Piece 1 (less than 248 octets)| | >> ~ ~ | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> 0 1 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --+ >> | Type (TBD1) | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --+ >> | container sequence number =2 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - >> | Piece 2 (less than 252 octets)| | >> ~ ~ | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> 0 1 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --+ >> | Type (TBD1) | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --+ >> | container sequence number =n | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - >> | Piece n (less than 252 octets)| | >> ~ ~ | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> Best Regards >> Zongpeng Du >> duzongp...@foxmail.com & duzongp...@chinamobile.com From: Aijun Wang >> Date: 2024-10-28 16:22 >> To: 【外部账号】Christian Hopps CC: Hannes Gredler; Aijun Wang; Yingzhen Qu; >> lsr-chairs; draft-wang-lsr-isis-big-tlv; lsr Subject: [Lsr] Re: [Further >> Discussion]It's time to find one general solution to Big-TLV problem Re: >> IETF 121 LSR Slot Requests >> 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
