Hi, Acee: I will try to draft one document to summarize and analyze the unsolved challenges of current MP-TLV, based on the back and forth discussions on the list. I think this draft can give the reader and experts more detail understandings of the existing unsolved issues. I read again carefully the version 10 of this draft. https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-10 and find it exists still many contradict statements, for example(detail analysis will be in the planned draft): 1) In particular, the "key" which is used to identify the set of TLVs which form an MP-TLV is the same key used in the absence of MP-TLV support. Also note the definition of the "key" exists in the specification(s) which define the TLV. --------Actually, there is no any definition of the "key" exists in the specification(s) which define the TLV. 2) NOTE: This document intentionally does not include a definition of the key for each codepoint. To do so would be redundant and risk unintentionally deviating from the definition which already exists in the relevant specifications. --------Actually, it is difficult to define the key for each codepoint. 3) This advertisement is for informational purposes only. Implementations MUST NOT alter what is sent or how what is received is processed based on these advertisements. ---------If the sender/receiver can ignore such information, who will care? The operator? Using some protocol analyzer to capture the signal in network? 4) It is presumed that if such support is provided that it applies to all relevant codepoints. It is understood that in reality, a given implementation might limit MP-TLV support to particular codepoints based on the needs of the deployment scenarios in which it is used. Therefore, diligence is still required on the part of the operator to ensure that configurations which require the sending of MP-TLV for a given codepoint are not introduced on any node in the network until all nodes in the network support MP-TLV for the relevant codepoints. ---------This is the Most contradict statements in this document.-------If the operator must "diligently" assure the all support of MP-TLV for one codepoint, what's the usage of such advertisement(MP-TLV Capability Advertisement) ---------Do you think it is feasible and deployable that let the operator to check the application of MP-TLV of each codepoint by configuration? 5) Given that MP-TLV support in a given implementation may vary on a per TLV basis, these controls SHOULD support per codepoint granularity. ---------Don’t you think this is another contradict statement for the advertisement of " MP-TLV Capability Advertisement" I understand, as experts from the vendors, you may think the "key" information may be your knob, or implicitly known by each vendor. But, the operator network are comprising by the devices from different vendors, the standard should make such "key" information EXPLICIT. I know also the discussion passed through the LSR WG, what you call "consensus". I am discussing with the experts that review this document now, remind them that some FALSE statements in the document, or the ignorance of the potential issues, from one more neutral viewpoint. If you don't want LSR WG included, I can omit them in future responses. But I prefer to discuss this topic transparently. We are near the final conclusions for the unsolved challenge, and wish to give your technical analysis for the example that provided by Les and enhanced by myself at https://mailarchive.ietf.org/arch/msg/lsr/27Jva6EwKAZBpCtv8LrnIY4l6Tw/ Best Regards Aijun Wang China Telecom -----邮件原件----- 发件人: Acee Lindem [mailto:acee.ietf@xxxxxxxxx] 发送时间: 2025年2月24日 23:38 收件人: Aijun Wang <wangaijun@xxxxxxxxxxxxxxx> 抄送: Les Ginsberg (ginsberg) <ginsberg=40cisco.com@xxxxxxxxxxxxxx>; Adrian Farrel <adrian@xxxxxxxxxxxx>; Joel Halpern <jmh@xxxxxxxxxxxxxxx>; Routing Directorate <rtg-dir@xxxxxxxx>; draft-ietf-lsr-multi-tlv.all@xxxxxxxx; last-call <last-call@xxxxxxxx>; lsr <lsr@xxxxxxxx>; The IESG <iesg@xxxxxxxx> 主题: Re: [Lsr] [Last-Call] Re: Re: 答复: 答复: Re: 【Can you concatenate several pieces together without one "explicit key" to identify them belong to the same segment】Re: Rtgdir last call review of draft-ietf-lsr-multi-tlv-08 Speaking as WG chair: Ajun, We have "rough consensus" that the IS-IS TLV and sub-TLV key existed well before this document and that IS-IS implementations already need to know the keys for TLVs and sub-TLVs in order to function correctly. Can you please cease and desist in taking WG list bandwidth by repeating the same arguments over and over again? If you believe the is a gap in specification for IS-IS, perhaps you could recruit some implementers to author an informational document on this subject. Thanks, Acee > On Feb 23, 2025, at 8:09 PM, Aijun Wang <wangaijun@xxxxxxxxxxxxxxx> wrote: > > Les： > Until now, I haven’t seen your responses for the following questions, even you updated your document to version 10. > It seems that Adrian wants to quit the discussions, with no clear answer for my questions https://mailarchive.ietf.org/arch/msg/lsr/VaTcicgyknAmLVBqEO4cDKMmn9w/), And, even the ongoing discussions of sub-TLV boundary doesn’t touch this key issues. > Let’s back to the main issues to be addressed? > Best Regards > Aijun Wang > China Telecom > 发件人: forwardingalgorithm@xxxxxxxx > [mailto:forwardingalgorithm@xxxxxxxx] 代表 Aijun Wang > 发送时间: 2025年2月21日 15:18 > 收件人: 'Les Ginsberg (ginsberg)' <ginsberg=40cisco.com@xxxxxxxxxxxxxx>; > adrian@xxxxxxxxxxxx; 'Joel Halpern' <jmh@xxxxxxxxxxxxxxx>; > rtg-dir@xxxxxxxx > 抄送: draft-ietf-lsr-multi-tlv.all@xxxxxxxx; last-call@xxxxxxxx; > lsr@xxxxxxxx; 'The IESG' <iesg@xxxxxxxx> > 主题: [Lsr] 答复: [Last-Call] Re: Re: 答复: 答复: Re: 【Can you concatenate > several pieces together without one "explicit key" to identify them belong to the same segment】Re: Rtgdir last call review of draft-ietf-lsr-multi-tlv-08 Hi, Les: > As I said before, if the sender and receiver are from the same vendor, it is easy to keep consistent for the selection of “key” for multiple pieces of one instances of one IS-IS TLV Type. > But, if the sender and receiver are from different vendors, they have their determination to select such “key”, because there is no any RFCs defining such information. > Then, how the receiver determine what’s the “key” part of one MP-TLV to be used to concatenate the pieces of one IS-IS TLV instance? > Must they guess? Comparing all of the received sub-TLVs and make some assumptions? > Take the example that you stated for TLV 22. > If vendor A send pieces of TLV 22 instance A <22, Neighbor System ID, > other possible sub-TLVs, IPv4 Local/Remote Address> + object info !!V4 > addresses only <22, Neighbor System ID, IPv4 Local/Remote Address> + object info !!V4 addresses only > vendor B send pieces of TLV 22 instance B: > <22, Neighbor System ID, other possible sub-TLVs, IPv6 Local/Remote > Address> + additional object info !!V6 addresses only <22, Neighbor > System ID, IPv6 Local/Remote Address> + additional object info !!V6 > addresses only How vendor A determine the “key” parts for concatenating the different pieces of TLV 22 instance B How vendor B determine the “key” parts for concatenating the different pieces of TLV 22 instance A? > Imaging there is another vendor C, receive both of these pieces for another two instances, how does vendor C determine such information solely from the ambiguous segmented pieces? > Will it a chaos for the interoperability within the operator’s network? > Best Regards > Aijun Wang > China Telecom > 发件人: forwardingalgorithm@xxxxxxxx > [mailto:forwardingalgorithm@xxxxxxxx] 代表 Les Ginsberg (ginsberg) > 发送时间: 2025年2月21日 13:59 > 收件人: Aijun Wang <wangaijun@xxxxxxxxxxxxxxx>; adrian@xxxxxxxxxxxx; > 'Joel Halpern' <jmh@xxxxxxxxxxxxxxx>; rtg-dir@xxxxxxxx > 抄送: draft-ietf-lsr-multi-tlv.all@xxxxxxxx; last-call@xxxxxxxx; > lsr@xxxxxxxx; 'The IESG' <iesg@xxxxxxxx> > 主题: [Last-Call] Re: [Lsr] Re: 答复: 答复: Re: 【Can you concatenate several > pieces together without one "explicit key" to identify them belong to the same segment】Re: Rtgdir last call review of draft-ietf-lsr-multi-tlv-08 The draft states (Section 4): > If a router advertises multiple TLV tuples with the same TLV type and > the same key (when applicable) in an IS-IS Hello (IIH) packet or in > the set of LSPs for a given level, they are considered a Multi-Part > TLV (MP-TLV). > In other words, for a given object if an implementation uses Codepoint/Key Tuple of <C1, K1>, that tuple is used in however many TLVs it takes to send all of the information associated with that object. > Let’s continue to use TLV 22 as an example. For a given link, an implementation uses the key: > <22, Neighbor System ID, IPv4 Local/Remote Address and IPv6 > Local/Remote Addresses> If all information about the link fits in one TLV the following is sent: > <22, Neighbor System ID, IPv4 Local/Remote Address and IPv6 > Local/Remote Addresses> + object info If all information about the link requires two TLVs the following is sent: > <22, Neighbor System ID, IPv4 Local/Remote Address and IPv6 Local/Remote Addresses> + object info > <22, Neighbor System ID, IPv4 Local/Remote Address and IPv6 > Local/Remote Addresses> + additional object info Etc. > It is true that in earlier versions of the draft, there was language that suggested that it was permissible (though not recommended) to do something like: > <22, Neighbor System ID, IPv4 Local/Remote Address and IPv6 Local/Remote Addresses> + object info > <22, Neighbor System ID, IPv4 Local/Remote Address> + additional > object info !!Omit IPv6 addresses The thought at the time was that receivers could still unambiguously identify the two TLVs as belonging to an MP-TLV set based on the IPv4 addresses and save some space when advertising the second TLV. > However, as the draft progressed, we realized this left some room for possible misinterpretation – implementors might have mistakenly thought they could do something like: > <22, Neighbor System ID, IPv4 Local/Remote Address> + object info !!V4 addresses only > <22, Neighbor System ID, IPv6 Local/Remote Address> + additional > object info !!V6 addresses only This clearly makes it impossible to recognize the two TLVs as describing the same link. > Therefore, in later versions we removed that ambiguity and simply state the key info (when present) MUST be the same in all TLVs in an MP-TLV set. > We also found, when examining multiple existing implementations, that this is in fact what implementors have done. > Claims that Aijun makes below that state that the key used for MP-TLV is or needs to be different than for the single TLV case are simply incorrect. > Les > From: Aijun Wang <wangaijun@xxxxxxxxxxxxxxx> > Sent: Thursday, February 20, 2025 8:34 PM > To: adrian@xxxxxxxxxxxx; 'Joel Halpern' <jmh@xxxxxxxxxxxxxxx>; > rtg-dir@xxxxxxxx > Cc: draft-ietf-lsr-multi-tlv.all@xxxxxxxx; last-call@xxxxxxxx; > lsr@xxxxxxxx; 'The IESG' <iesg@xxxxxxxx> > Subject: 答复: [Lsr] Re: 答复: [Last-Call] 答复: Re: 【Can you concatenate > several pieces together without one "explicit key" to identify them belong to the same segment】Re: Rtgdir last call review of draft-ietf-lsr-multi-tlv-08 Hi, Adrian: > “MP-TLV introduces no additional need for keys.” is one INCORRECT understanding for the difference of base TLV and MP-TLV. Here are the reasoning: > 1) You are correct that the base TLV need some fields to distinguish themselves among the multiple instances of one TLV type(Type T, let’s assumed for further discussions). But, such fields in these instances of one TLV type T NEED NOT be consistent. That is to say, one instance of Type T can have the field A to distinguish with others, another instance of Type T can have field B to accomplish the same aim. > 2) The sender need only keep the value of “distinguish field” are different among the multiple instance of Type T. > 3) But for MP-TLV, the situation is different. The sender MUST keep the “distinguish field” within different pieces of one instance of the Type T same. That is to say, if one piece of the instance of Type T use field A as the “distinguisher”, then all the pieces of this instance of Type T must use the same field. > 4) Until now, I think you should notice that the “distinguisher(let’s call it “D1”)” for multiple instances of Type T, is different from the “distinguisher(let’s call it “D2”)” for the multiple pieces of one instance of Type T. > 5) “D1” can be selected by the vendor, according to description of the related RFCs, “D2” doesn’t exist now, and must be defined, according to the current MP-TLV proposal. > Let’s take the TLV 22 as one example to illustrate again my above logic: > The sender can use “IPv4 Interface Address” sub-TLV, or “IPv4 Neighbor Address” sub-TLV, to distinguish the different instances of TLV 22. The receiver can decode them as different instances correctly. > But, for MP-TLV, the sender and receiver MUST agree with each other > which of the above sub-TLVs, or all of the these sub-TLVs(in addition other possible sub-TLVs), act as the “key” to segment and concatenate the different pieces together. Or else, there will be interoperability problem Wish the above explanation can correct you and also other expert’s ignore or misunderstanding of MP-TLV. > Best Regards > Aijun Wang > China Telecom > 发件人: forwardingalgorithm@xxxxxxxx > [mailto:forwardingalgorithm@xxxxxxxx] 代表 Adrian Farrel > 发送时间: 2025年2月20日 20:05 > 收件人: 'Aijun Wang' <wangaijun@xxxxxxxxxxxxxxx>; 'Joel Halpern' > <jmh@xxxxxxxxxxxxxxx>; rtg-dir@xxxxxxxx > 抄送: draft-ietf-lsr-multi-tlv.all@xxxxxxxx; last-call@xxxxxxxx; > lsr@xxxxxxxx; 'The IESG' <iesg@xxxxxxxx> > 主题: [Lsr] Re: 答复: [Last-Call] 答复: Re: 【Can you concatenate several > pieces together without one "explicit key" to identify them belong to > the same segment】Re: Rtgdir last call review of draft-ietf-lsr-multi-tlv-08 Just jumping in on this one before I respond to your email to me… I believe that the key MUST be present in MP-TLV only if it is already defined (and must be present) for the base TLV. Thus, this document does not change any key definitions and does not need to. It does not define any new keys or any requirement for new keys. > Why are keys used in base TLVs? > Because multiple TLVs of the same type may legitimately be present to describe different instances of an entity, so they must have a key to distinguish them, show what they are describing, and show they are not accidental duplicates. > MP-TLV introduces no additional need for keys. > Cheers, > Adrian > From: Aijun Wang <wangaijun@xxxxxxxxxxxxxxx> > Sent: 20 February 2025 04:35 > To: 'Joel Halpern' <jmh@xxxxxxxxxxxxxxx>; rtg-dir@xxxxxxxx > Cc: draft-ietf-lsr-multi-tlv.all@xxxxxxxx; last-call@xxxxxxxx; > lsr@xxxxxxxx; 'The IESG' <iesg@xxxxxxxx> > Subject: [Lsr] 答复: [Last-Call] 答复: Re: 【Can you concatenate several > pieces together without one "explicit key" to identify them belong to the same segment】Re: Rtgdir last call review of draft-ietf-lsr-multi-tlv-08 Hi, Joel: > We should notice the fact，or the difference between them---that----the “key“ information is not important or must-be part for the traditional IS-IS implementation, then there is no any definition in the current RFCs. > But, for MP-TLV, it is the MUST-BE present information. Then, it should be defined explicitly, or else, the interoperability can’t be assured from the implementation of different vendors. > The above is the main differences between the traditional IS-IS implementation and the implementation and deployment of MP-TLV in operator network. > We should exclude the deployment example that negotiated by the vendors offline. > Best Regards > Aijun Wang > China Telecom > 发件人: Joel Halpern [mailto:jmh@xxxxxxxxxxxxxxx] > 发送时间: 2025年2月20日 12:06 > 收件人: Aijun Wang <wangaijun@xxxxxxxxxxxxxxx>; rtg-dir@xxxxxxxx > 抄送: draft-ietf-lsr-multi-tlv.all@xxxxxxxx; last-call@xxxxxxxx; > lsr@xxxxxxxx; 'The IESG' <iesg@xxxxxxxx> > 主题: Re: [Last-Call] 答复: [Lsr] Re: 【Can you concatenate several pieces > together without one "explicit key" to identify them belong to the > same segment】Re: Rtgdir last call review of > draft-ietf-lsr-multi-tlv-08 Aijun, may I suggest another way of > phrasing what I am hearing people who disagree with your analysis are > asserting? (If I get it wrong, I am sure they will correct me.) > 1) We have working IS-ID > 2) In order to function, IS-IS implementations already must recognize > when they receive two conlicting dvertisements > 2') That is, for every advertisement that can possibly be duplicated > with variation, there already is a well-defined notion common to all > implementations of the key for those advertisements > 3) The multi-tlv effort you are objecting to uses that same keying to allow for the case where the two variations that are received are to be combined, instead of merely selecting one. > 4) Given that this necessary behavior has been operation for MANY years, the apparent conclusion is that it is already sufficiently specified. > Yours, > Joel > On 2/19/2025 10:56 PM, Aijun Wang wrote: >> >> >> Hi, Adrian: >> Thanks for your detail analysis and logical deduction! It help us to understand the arguments of each other. Let me give my thoughts to your analysis: >> First, I must point out that the base of your assumptions is NOT >> CORRECT: There is no such “Fixed part” that can be used as the “key” >> information for slicing the large TLV, defined in the related RFCs, >> for every possible MP-TLVs that are listed in >> draft-ihttps://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv >> -09#section-9 We should all know there are fixed fields defined in >> these TLVs/sub-TLVs, but that can’t be solely used as the “Fixed part” to concatenate the several pieces together. >> We can take the TLV 22(Extended IS Reachability) as one example(also in this WGLC document). For clarity, I extracted the related content from the document directly(https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-09#section-3.2.1): >> As an example, consider the Extended IS Reachability TLV (type 22). A neighbor in this TLV is specified by:¶ >> • 7 octets of system ID and pseudonode number¶ >> • 3 octets of default metric¶ >> • Optionally one or more of the following link identifiers:¶ >> • IPv4 interface address and IPv4 neighbor address as specified in [RFC5305]¶ >> • IPv6 interface address and IPv6 neighbor address as specified in [RFC6119]¶ >> • Link Local/Remote Identifiers as specified in [RFC5307]¶ >> The key consists of the 7 octets of system ID and pseudonode number plus the set of link identifiers which are present. >> We can check the original definition of RFC for TLV 22----RFC 5305----There is no any “key” definition information in this RFC----Verify what I have said above that there is no key definition for every possible MP-TLVs in current RFCs. >> What constitutes the key of TLV 22 is only mentioned in this WGLC document------“The key consists of the 7 octets of system ID and ……” >> Even we continuing our discussions based on such key definition information, can you tell me what is the “Fixed part” that you mentioned when slicing the TLV in your example? >> I think you should know, according to the description of this document, “the set of link identifiers” is optionally. I can image if the sender/receiver are from one vendor, they can keep the “Fixed part” in different pieces same, but, how to ensure they are same if the devices from different vendors? >> Comparing to this undefined and ambiguity of “Fixed part”, or “key” information for each possible MP-TLV, other issues that you raised(slicing not in the boundary of sub-TLV, temporarily duplicate of a TLV in two LSPs etc. can be easily mitigated). >> I think you admitted the “key” must be represented in every of piece of the sliced TLV/sub-TLVs(for the “keyed TLV” that you mentioned). Then, where is “key” definition for each of such TLV/sub-TLVs? >> Best Regards >> Aijun Wang >> China Telecom >> 发件人: forwardingalgorithm@xxxxxxxx >> [mailto:forwardingalgorithm@xxxxxxxx] 代表 Adrian Farrel >> 发送时间: 2025年2月19日 19:21 >> 收件人: 'Aijun Wang' <wangaijun@xxxxxxxxxxxxxxx>; 'Les Ginsberg >> (ginsberg)' <ginsberg@xxxxxxxxx>; rtg-dir@xxxxxxxx >> 抄送: draft-ietf-lsr-multi-tlv.all@xxxxxxxx; last-call@xxxxxxxx; >> lsr@xxxxxxxx; 'The IESG' <iesg@xxxxxxxx> >> 主题: [Lsr] Re: 【Can you concatenate several pieces together without >> one "explicit key" to identify them belong to the same segment】Re: Rtgdir last call review of draft-ietf-lsr-multi-tlv-08 The correct formation of a TLV includes certain fields that must be present and other fields (such as sub-TLVs) that may be present and may recur. All instances of a TLV must be formatted correctly. That means that when a TLV is repeated as part of an MP-TLV each component TLV must be correctly formatted. >> In other words, t is incorrect to read this document as simply >> saying that the “overflow” appears in a second TLV structure with the same Type, and with the data continuing. Consider (please enable non-proportional font) | T=t | L | Fixed part | sub-TLV1 | sub-TLV2 | sub-TLV3 | >> 1 ... ... 255 ... >> There is too much to fit into one TLV structure. >> The incorrect MP-TLV would be… >> | T=t | L | Fixed part | sub-TLV1 | >> | T=t | L | sub-TLV2 | sub-TLV3 | >> The correct MP-TLV would be >> | T=t | L | Fixed part | sub-TLV1 | >> | T=t | L | Fixed part | sub-TLV2 | sub-TLV3 | >> Note also, that the separation into component TLVs must happen at a >> segmentable boundary. E.g., at a sub-TLV. Thus, another incorrect >> MP-TLV would be… >> | T=t | L | Fixed part | sub-TLV1 | First part of sub-TLV2 | T=t | L >> | | Fixed part | Second part of sub-TLV2 | sub-TLV3 | >> There are two cases: >> • TLVs that have a key defined >> • TLVs that don’t have a key defined If the TLV has a key, that >> is usually found in the fixed part. >> Thus, the key is found in both component TLVs. >> What are the concerns? >> • That for a keyed TLV, the component TLVs will not be correctly associated. >> Not a problem because the key is present in each component TLV. >> • That the component TLVs will not be concatenated in the right >> order Not a problem because the sub-TLVs (i.e., the not fixed part) >> are allowed to be present in any order. >> • That fragments of a sub-TLV will be concatenated in the wrong order. >> Not a problem because partitioning must be at a sub-TLV boundary >> • That the fixed part will differ in component TLVs. >> This is identified as an error. >> • How do I know which fields in the fixed part comprise the key? >> If you have implemented support for a TLV, you must understand the key. >> If you have not implemented support for the TLV, you don’t care >> because you ignore the TLV. >> • Your question: >> Can you concatenate several pieces together without one “explicit key” to identify them belong to the same segment? >> I say “yes”. Because, without a key you know that the TLV is “one of a kind”. >> The only legitimate duplication of a TLV is when it includes a key. >> Note: There are two cases identified in the document where (without MP-TLV) an un-keyed TLV may be duplicated. >> • sender makes an error by including multiple versions of a TLV >> • the sender is transiting a TLV from one LSP to another (so >> it appears in both LSPs) These are both handled by allowing concatenation to proceed, and the composed TLV to be discovered to be incorrectly formatted. >> For the first case, this will result in the errored composed TLV being discarded. Good. >> For the second case, there will be a transitory case where the errored composed TLV is discarded, but when the LSP is refreshed, everything will resolve. My question back to you would be to ask you to give an example where this goes wrong? >> Thanks, >> Adrian >> From: Aijun Wang <wangaijun@xxxxxxxxxxxxxxx> >> Sent: 19 February 2025 02:40 >> To: adrian@xxxxxxxxxxxx; 'Les Ginsberg (ginsberg)' >> <ginsberg@xxxxxxxxx>; rtg-dir@xxxxxxxx >> Cc: draft-ietf-lsr-multi-tlv.all@xxxxxxxx; last-call@xxxxxxxx; >> lsr@xxxxxxxx; 'The IESG' <iesg@xxxxxxxx> >> Subject: 答复: [Lsr] 【Can you concatenate several pieces together >> without one "explicit key" to identify them belong to the same segment】Re: Rtgdir last call review of draft-ietf-lsr-multi-tlv-08 Hi, Adrian: >> I have read your Rtgdir reviews and update suggestions on the current document. Appreciate for your efforts! >> But, I don’t know why you ignore the issues that you have concerned previously also about the “explicit key” definition of each possible IS-IS TLV/sub-TLV.(Please refer to:https://mailarchive.ietf.org/arch/msg/lsr/Xga5YrD6ObbNDvFFK_nVDXlipJA/). >> Let’s try to don’t loop the past arguments and make the life better. >> Then, would you, and also other experts/reviewer that pass this document answer the following simple, straightforward question: >> Can you concatenate several pieces together without one “explicit key” to identify them belong to the same segment? >> If the answer is “can”, please tell me how? >> If the answer is “can’t”, then, where is necessary “explicit key” in this document? And, if there is none of such “explicit key” information, what’s the value of this document? >> Let’s be clear for the further discussion, the implicit negotiations solution to solve the interoperability is not STANDARD solution. >> I copied this discussions also to the IESG mail list for further evaluations of the IESG experts. >> Best Regards >> Aijun Wang >> China Telecom >> 发件人: forwardingalgorithm@xxxxxxxx >> [mailto:forwardingalgorithm@xxxxxxxx] 代表 Adrian Farrel >> 发送时间: 2025年2月14日 18:10 >> 收件人: 'Les Ginsberg (ginsberg)' <ginsberg@xxxxxxxxx>; rtg-dir@xxxxxxxx >> 抄送: draft-ietf-lsr-multi-tlv.all@xxxxxxxx; last-call@xxxxxxxx; >> lsr@xxxxxxxx >> 主题: [Lsr] Re: Rtgdir last call review of draft-ietf-lsr-multi-tlv-08 >> Many thanks for your responsiveness, Les. >> V9 addresses all of my nits adequately. I will update the status of my review in the Datatracker. >> As to… >> > That said, after posting V9, I thought maybe something like what I >> show below >> > might be added to Section 4. I am not convinced it is needed – but >> > let me know what you think. >> > >> > “Each TLV that is part of an MP-TLV MUST be parsable independent of >> > other TLVs in the MP-TLV. Breaking of a single sub-TLV or other >> > data unit across TLVs MUST NOT be done.” >> I agree with you that this is “not needed.” I do believe it would be somewhat helpful to avoid people falling into error. >> I leave it to you and your co-authors to decide. >> Cheers, >> Adrian -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
