This is not a technical discussion and I think it's time for the chairs to step in. Once the WG has made a decision, based upon rough consensus, you can't simply reiterate the same unsuccessful arguments forever as you have done multiple times in the past in hopes of changing the WG consensus. On Thursday, October 31, 2024 at 06:37:58 AM PDT, Aijun Wang <wangai...@tsinghua.org.cn> wrote: Hi, John: Do you some technical arguments?Or please reply the technical issues that raised at https://mailarchive.ietf.org/arch/msg/lsr/p0BCxfjCVo7Pjb9hK_Ot1hQgJHY/I would like to hear. I think you have noticed that we ignore your non senses response before several times. If you have no any fruitful arguments, please stop response on other persons’ technical arguments.
Aijun WangChina Telecom On Oct 31, 2024, at 21:13, 【外部账号】John Drake <je_dr...@yahoo.com> wrote: Why are we still discussing this? The WG has decided that the Big-TLV draft is not where want to go, so continued discussion is simply a DoS attack on the WG's mailing list. On Wednesday, October 30, 2024 at 10:34:38 PM PDT, 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 RegardsZongpeng Du duzongp...@foxmail.com & duzongp...@chinamobile.com From: Aijun WangDate: 2024-10-28 16:22To: 【外部账号】Christian HoppsCC: Hannes Gredler; Aijun Wang; Yingzhen Qu; lsr-chairs; draft-wang-lsr-isis-big-tlv; lsrSubject: [Lsr] Re: [Further Discussion]It's time to find one general solution to Big-TLV problem Re: IETF 121 LSR Slot RequestsHi, 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 WangChina Telecom Aijun WangChina 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
_______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
