Speaking as WG Chair: > On Oct 31, 2024, at 10:17 AM, John Drake > <[email protected]> wrote: > > 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.
The chairs have made it clear that we aren't going to allow presentation of the Big-TLV draft. I don't believe that recalcitrance in itself is justification for more stringent action. Thanks, Acee > > On Thursday, October 31, 2024 at 06:37:58 AM PDT, Aijun Wang > <[email protected]> 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 Wang > China Telecom > >> On Oct 31, 2024, at 21:13, 【外部账号】John Drake <[email protected]> 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, [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 RegardsZongpeng Du >> [email protected] & [email protected] >> 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 <[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 > > _______________________________________________ > 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]
