Hi, Acee and Henk: Thanks for your acknowledgements that current MP-TLV is one short term solution.
I want to point out that even the “short term” solution solves only partially only two TLVs(TLV 22 and TLV 135), because it defines “what constitutes a key” for these two TLVs. It doesn’t give the information of “what constitutes a key” for other IS-IS codepoints, and from the overall discussions on the list, it is impossible to define such information for all of the possible big IS-IS TLVs codepoints, and their possible big sub TLVs code point. Then, the description within the IANA considerations of section 8.2 SHOULD be removed. And, the last point I want to emphasize is that—-Even for the two IS-IS TLVs(22 and 135), current MP-TLV proposal solves only partially the problem, because it doesn’t define “what constitutes a key” for their respective sub-TLVs, for example, the “key” information for Application-Specific Link Attributes sub-TLV. Different vendors may decide to use different “key” for these TLVs or sub-TLVs, it is error prone in the large scale operator network. And before you declare some proposal is not “good enough”, please state your reasoning. For back compatibility, if the receiver doesn’t adopt or agree “what constitutes a key” for the TLV 22 and TLV135, there will be incompatibility's issues arose. As one operator, we need to find the long term solution, not the pitfall short term solution that leads the operator busy to coordinate with different vendors because the vague and error prone definitions. Aijun Wang China Telecom > On Oct 31, 2024, at 23:17, 【外部账号】Acee Lindem <acee.i...@gmail.com> wrote: > > 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
_______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
