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) 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 [email protected] <[email protected]> > 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 > > > --------------------------------------------- > > [email protected] mailto:[email protected] & > [email protected] mailto:[email protected] > > > > > > > From: Aijun Wang mailto:[email protected] > > Date: 2024-10-28 16:22 > > To: 【外部账号】Christian Hopps mailto:[email protected] > > CC: Hannes Gredler mailto:[email protected]; Aijun Wang > > mailto:[email protected]; Yingzhen Qu > > mailto:[email protected]; lsr-chairs mailto:[email protected]; > > draft-wang-lsr-isis-big-tlv mailto:[email protected]; > > lsr mailto:[email protected] > > 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 <[email protected]> > > > wrote: > > > > > > > > > > > > > > Hannes Gredler <[email protected]> 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 <[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/ )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] > > > > > > > <signature.asc> > > > > > > _______________________________________________ > 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]
