Hi, Les:
“an implementation to correctly/reliably differentiate the objects described in two different TLVs of the same type” doesn’t represent it CAN concatenate the sliced IS-IS TLVs together, the necessary function of any sliced proposal requires. For example, for TLV type 22(“Extended IS Reachability TLV”): Link #1 of Router A can send some information regarding to its characteristic information in one traditional TLV 22 Link #2 of Router A can also send some information regarding to its characteristic information in another traditional TLV 22 The receiver, for example Router B, can correctly/reliably differentiate the above two traditional TLV 22, because they include different values of the sub-TLVs(for example, different IPv4 Interface Address sub-TLV). The IS-IS will not be broken certainly. But, if the information of Link #1 is large enough and can’t be contained within one traditional TLV 22, the sender of Router A must encapsulate these large amount information in several TLVs(Type 22). If there is no one explicitly defined information for “What constitutes a key“， then, Router A CANNOT assure the multiple occurrences of TLV 22 has the same “key” value, the receiver will treat these multiple occurrence of TLV 22 as from different links, not from Link #1, the result of IS-IS SPF will be incorrect. The above issue is arose only from the introduction of MP-TLV procedures, and can be eliminated only by defining clearly “What constitutes a key“. Just summarize the conclusions: The information of “What constitutes a key“ is necessary for any slice/glue solution. Lack of such information will let the IS-IS broken(as proposal in MP-TLV draft for the TLVs other than TLV 22 and TLV 135). Best Regards Aijun Wang China Telecom 发件人: [email protected] [mailto:[email protected]] 代表 Les Ginsberg (ginsberg) 发送时间: 2024年10月23日 15:36 收件人: Aijun Wang <[email protected]>; 'Christian Hopps' <[email protected]> 抄送: 'Yingzhen Qu' <[email protected]>; 'lsr-chairs' <[email protected]>; [email protected]; 'lsr' <[email protected]> 主题: [Lsr] Re: 答复: Re: It's time to find one general solution to Big-TLV problem Re: IETF 121 LSR Slot Requests Ahhh…well…I am reminded of why I stopped engaging in these discussions. Sigh… If it were true ( as Aijun claims) that existing RFCs do not clearly define the “key” for the codepoints defined in that document, then it would not be possible for an implementation to correctly/reliably differentiate the objects described in two different TLVs of the same type – even in the absence of MP. This would mean that IS-IS is completely broken. I am well past my quota for discussing nonsense – so no more from me. Les From: Aijun Wang <[email protected] <mailto:[email protected]> > Sent: Tuesday, October 22, 2024 11:31 PM To: Les Ginsberg (ginsberg) <[email protected] <mailto:[email protected]> >; 'Christian Hopps' <[email protected] <mailto:[email protected]> > Cc: 'Yingzhen Qu' <[email protected] <mailto:[email protected]> >; 'lsr-chairs' <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> ; 'lsr' <[email protected] <mailto:[email protected]> > Subject: 答复: [Lsr] Re: 答复: Re: It's time to find one general solution to Big-TLV problem Re: IETF 121 LSR Slot Requests Hi, Les and members of the WG: Let’s try to move forward and get more constructive results for the discussions. First, I want to emphasize that I fully understand the current MP-TLV solution(I think many experts have also understood), and know the mentioned “key” fields are existing(or optional existing) in the current encoding of each IS-IS TLV. But, as mentioned by Les, “What constitutes a key is codepoint specific”, and there is no any RFC document such information. Current MP-TLV proposal gives such information only (“What constitutes a key”) for two TLVs(“IS-Neighbor TLVs“ and “Prefix Reachability TLV“)，but none for others( for example “BFD Enabled TLV“ that provided by Les in this mail as another possible big IS-IS TLV example), let alone all the possible big IS-IS TLVs. Lacking the definition of “What constitutes a key” CANNOT certainly achieve the aim of “treating two TLVs for the same object as additive rather than as replacements for each other”, in other words, glue the sliced IS-IS TLVs together. The last sentence is my main argue point for the current MP-TLV proposal. Best Regards Aijun Wang China Telecom , 发件人: [email protected] <mailto:[email protected]> [mailto:[email protected]] 代表 Les Ginsberg (ginsberg) 发送时间: 2024年10月23日 13:23 收件人: Aijun Wang <[email protected] <mailto:[email protected]> >; 'Christian Hopps' <[email protected] <mailto:[email protected]> > 抄送: 'Yingzhen Qu' <[email protected] <mailto:[email protected]> >; 'lsr-chairs' <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> ; 'lsr' <[email protected] <mailto:[email protected]> > 主题: [Lsr] Re: 答复: Re: It's time to find one general solution to Big-TLV problem Re: IETF 121 LSR Slot Requests Soooo....for the benefit of the WG... Aijun has sent many messages making the same claims. In the past I (and others) have made attempts to explain to Aijun why he is mistaken. For one example see https://mailarchive.ietf.org/arch/msg/lsr/6PbU-KcARoELuYrrdrs3OnYKn5U/ None of these responses have convinced Aijun that he is mistaken - so I do not expect that this response will alter his opinion. In fact, I fully expect that in response to this email Aijun will send yet another email making the same mistaken claims. 😊 But I am not sending this in the hopes of altering Aijun's understanding. I am sending this only to reassure other members of the WG who might not be as familiar with the solution defined in https://datatracker.ietf.org/doc/draft-ietf-lsr-multi-tlv/ that what Aijun is claiming is incorrect. No encoding changes to any codepoint are required for the multi-tlv solution. This is a hallmark of the solution as it ensures that implementations can use existing code for encoding the TLVs they send and use existing code for parsing the TLVs they receive. The only implementation changes which are required have to do with treating two TLVs for the same object as additive rather than as replacements for each other. This is described in more detail in https://www.ietf.org/archive/id/draft-ietf-lsr-multi-tlv-06.html#section-5 What seems to have confused Aijun is the use of the generic term "key" to describe that portion of a given codepoint which uniquely identifies the object associated with a given TLV. This isn't the introduction of new information - it is simply a generic term for what is already being advertised in TLVs and in fact already being processed on receive even in the absence of MP. What constitutes a key is codepoint specific - but it is not new information that is required when MP is in use. For example: For IS-Neighbor TLVs the "key" is system-id and link identifiers (as described in https://www.ietf.org/archive/id/draft-ietf-lsr-multi-tlv-06.html#section-4.1 ) For Prefix Reachability TLVs the "key" is the prefix/length (as described in https://www.ietf.org/archive/id/draft-ietf-lsr-multi-tlv-06.html#section-4.2 ) For the BFD Enabled TLV the key is (MTID,NLPID). Etc. The fact that we did not describe in the draft the "key" for all codepoints for which MP-TLV is applicable does not mean that additional information is required to be sent in those codepoints when MP-TLV is in use. This is a fundamental misunderstanding. As I mentioned in a previous post, we have running code from multiple vendors which prove that what I say above is correct. Claims to the contrary indicate only that the person making those claims does not understand the draft. Thanx for listening. Les > -----Original Message----- > From: Aijun Wang <[email protected] > <mailto:[email protected]> > > Sent: Tuesday, October 22, 2024 8:53 PM > To: 'Christian Hopps' <[email protected] <mailto:[email protected]> > > Cc: 'Yingzhen Qu' <[email protected] <mailto:[email protected]> > >; 'lsr-chairs' <[email protected] <mailto:[email protected]> >; > [email protected] > <mailto:[email protected]> ; 'lsr' <[email protected] > <mailto:[email protected]> > > Subject: [Lsr] 答复: Re: It's time to find one general solution to Big-TLV > problem Re: IETF 121 LSR Slot Requests > > Hi, Chris: > > Thanks for sharing your thoughts for the past discussions. > The reason that the previous Big-TLV proposal doesn't win the debates in past > is that it has the same "key" definitions requirements for every possible big > IS- > IS TLV, as that in the current approach of MP-TLV solution. > > But, the above "key" definition for every possible big IS-IS TLV requirements > DOESN'T EXIST now, then the updated Big-TLV proposal has the obvious > advantage over the current MP-TLV solution. > It's time to reevaluate the two approaches within the WG. > > The main challenge for the MP-TLV approach is that it still requires the > specific > "key" definition for each possible big IS-IS TLV, which is non-extensible, > non- > deployable/operational(considering its ambiguous declaration of "MP-TLV > capabilities" is type independent instead). > > Best Regards > > Aijun Wang > China Telecom > > -----邮件原件----- > 发件人: <mailto:[email protected]> [email protected] [ > <mailto:[email protected]> mailto:[email protected]] > 代表 Christian Hopps > 发送时间: 2024年10月23日 10:57 > 收件人: Aijun Wang < <mailto:[email protected]> > [email protected]> > 抄送: 【外部账号】Christian Hopps < <mailto:[email protected]> [email protected]>; > Yingzhen Qu > < <mailto:[email protected]> [email protected]>; lsr-chairs < > <mailto:[email protected]> [email protected]>; > <mailto:[email protected]> draft-wang-lsr- <mailto:[email protected]> > [email protected]; lsr < <mailto:[email protected]> [email protected]> > 主题: [Lsr] Re: It's time to find one general solution to Big-TLV problem Re: > IETF 121 LSR Slot Requests > > > Hi Aijun, > > [as-wg-member]: Perhaps you don't recall, but if you go review all the email > threads and presentations/video you will see that I was a supporter of > Huaimo's idea originally. > > [as-wg-member]: However, I also accepted that I was "in the rough" and the > WG did not agree with using a new TLV for this problem. The WG has a > different solution that you do not agree with, but that doesn't change the WG > rough consensus. > > Thanks, > Chris. > > Aijun Wang < <mailto:[email protected]> [email protected]> > writes: > > > 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/> > > 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> > 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 > > < <mailto:[email protected]> [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 > > < <mailto:[email protected]> [email protected]> > > wrote: > > > > > > > > Hi, Chris: > > > > > > > > No, we have made some significant updates. > > > > Please refer to <https://mailarchive.ietf.org/arch/msg/lsr/> > > https://mailarchive.ietf.org/arch/msg/lsr/ > > dxK4Gy1WDR7QCXK6p58xgA0MdUc/ for more information. > > > > > > > > Aijun Wang > > > > China Telecom > > > > > > > > On Oct 22, 2024, at 17:04, 【外部账号】Christian Hopps > > < <mailto:[email protected]> [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" < <mailto:[email protected]> > > [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/> > > 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 > > > > > > > > > > > > > > > > 发件人: <mailto:[email protected]> > > [email protected] > > > > [ <mailto:[email protected]> > > mailto:[email protected]] 代表 Yingzhen > > Qu > > > > 发送时间: 2024年10月12日 3:54 > > > > 收件人: lsr < <mailto:[email protected]> [email protected]>; lsr-chairs > > < <mailto:[email protected]> [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 <mailto:[email protected]> > > [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 -- <mailto:[email protected]> [email protected] > To unsubscribe send an email to <mailto:[email protected]> > [email protected]
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
