Hi Aijun, I will once again (and for the last time) politely decline to engage on this topic of "keys" (and TLV 22) with you. I do not have anything further to add besides the copious efforts undertaken by various people (including yours truly) during and after the WG phase of this document to explain this topic to you.
Regarding the rest of your email, I have nothing further to say regarding my IESG Evaluation review of this document besides the ongoing discussion with the authors (and the WG). Thanks, Ketan On Fri, Apr 11, 2025 at 4:09 PM Aijun Wang <wangai...@tsinghua.org.cn> wrote: > Hi, Ketan: > > Regarding to your position described in the previous link, you stated: > > “If there is something really unclear, we can solve those individual issues > rather than stalling this work.” > > And, I have given you in advance that we can discuss the ambiguous only for > TLV 22 as one example. > > Can we focus on this code point then? > > Can you answer the problem scenario that is described in > https://datatracker.ietf.org/doc/html/draft-wang-lsr-unsolved-challenge-of-mp-tlv-01#section-3.1? > > Until now, there is no IESG reviewers answered it. I think you have the > responsibility and capability to solve the challenges. > > I noticed that you raised also another unsolved challenge—the nested > encapsulation of the current MP-TLV proposal—You are correct, if there is one > sub-sub-TLV has to be encapsulated in several instances pieces of the same > type, all of the these pieces MUST replicate its parent’s, and also its > grandparents’ fixed part, which will be the nightmares for the sender, and > also the receiver. > > From the author’s response, we can know there is no decent way to solve it. > And I want to point out it is not the guilty of the original sub-sub-TLV > definition. > > Such unsolved challenges should be incorporated into the future version of > https://datatracker.ietf.org/doc/html/draft-wang-lsr-unsolved-challenge-of-mp-tlv-01 > > I read carefully the description in > https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, > and find the following statements: > > “The goal of the IESG Evaluation is to ensure operability, readability and > clarity” > > But until now, I see the ADs focus mainly on the “readability and clarity”, > not the “operability”, which is more important for the implementation and > deployment of the IETF standard. > > IESG is the last phase to review the document in technical viewpoints. Please > focus on the unsolved challenges, not others. > > If you, as RTG AD, think these “unsolved challenges” have been solved, please > give the explicit answers then we can pass this document. > > Or else, it will be very pity the IETF can pass such proposal that has so > many issues—-as I said before, deploy such proposal within the operator > network can only lead more chaos, nothing else. > > We can revisit my attitude toward this document (Please ABANDON it) several > years later. The IETF repository can remember our discussions on this issue. > > > Aijun Wang > China Telecom > > On Apr 10, 2025, at 19:51, Ketan Talaulikar <ketant.i...@gmail.com> wrote: > > > Hi Aijun, > > From a technical perspective, I have not seen anything new that would > cause me to re-evaluate this topic and change my position. My position (as > well as suggestion) on this topic remains as it was here: > https://mailarchive.ietf.org/arch/msg/lsr/U3ImXcT5yDgvFCb3VLa5t9C4As4/ > > Arguments that are repeated continuously and more loudly do not become > "rigorous" in my opinion. They do, however, start to become disruptive to > the WG and IETF's consensus driven standards definition process. > > Thanks, > Ketan > > > On Thu, Apr 10, 2025 at 4:55 PM Aijun Wang <wangai...@tsinghua.org.cn> > wrote: > >> Hi, Ketan: >> >> As your recommendation, “ The definition of the "key" for a given TLV is >> outside the scope of this document and has to be part of the >> specification(s) that define(s) the TLV.” >> >> Then, do you admit also that there is no definition of “key” for a given >> TLV? >> >> If so, as I asked several times to our experienced ADs for the same >> question, but no one stated it clearly: how can you segment and concatenate >> the pieces of MP-TLV without the explicit defined key, especially among the >> implementations from different vendors? >> >> If you think there is already the “key” definition for these MP-TLVs, >> please give the reference? >> >> We need take only the TLV 22 as one example. >> >> You are the RTG AD, and should know the ‘rigorous’ arguments along its >> path until now. >> >> >> Aijun Wang >> China Telecom >> >> > On Apr 10, 2025, at 16:07, Ketan Talaulikar via Datatracker < >> nore...@ietf.org> wrote: >> > >> > Ketan Talaulikar has entered the following ballot position for >> > draft-ietf-lsr-multi-tlv-14: Discuss >> > >> > When responding, please keep the subject line intact and reply to all >> > email addresses included in the To and CC lines. (Feel free to cut this >> > introductory paragraph, however.) >> > >> > >> > Please refer to >> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ >> > for more information about how to handle DISCUSS and COMMENT positions. >> > >> > >> > The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/draft-ietf-lsr-multi-tlv/ >> > >> > >> > >> > ---------------------------------------------------------------------- >> > DISCUSS: >> > ---------------------------------------------------------------------- >> > >> > Thanks to the authors, first for taking up this work, and next for >> taking it >> > through a "rigorous" WG process while focusing on technical aspects. >> > >> > However, there are still some aspects in the document that I would like >> to have >> > a discussion on (inline using idnits output of v14): >> > >> > 152 This document specifies a means for extending TLVs where no >> extension >> > 153 mechanism has been previously explicitly specified, and >> defines this >> > 154 mechanism as the default extension mechanism for future >> TLVs. The >> > 155 mechanism described in this document is applicable to top >> level TLVs >> > 156 as well as any level of sub-TLVs which may appear within a >> top level >> > 157 TLV. >> > >> > <discuss-1> Given that a TLV is bounded at 255 bytes, by definition its >> > sub-TLVs (at first and subsequent levels) are bounded to an even >> smaller limit. >> > This implies that if > 255 bytes need to be encoded in a 1st level >> sub-TLV, >> > then we would need two parts of the parent TLV as well. While this is >> > implicit, some text on this would be helpful - I would not be surprised >> if >> > this gets missed by people working on future specifications. Taking it >> further, >> > this aspect imposes some design restriction on the level of >> > sub-TLV/sub-sub-TLV/... that can be designed for future extensions due >> to the >> > reducing bounds as we go deeper. At some point, the overhead of the >> > "process of breaking into parts" may start to bring in higher overheads >> than >> > the actual information being conveyed. This brings in challenges in >> protocol >> > encoding design (specifically with many layer of sub-TLVs). I would >> like to >> > discuss why this document isn't providing such a guidance as well (or >> at least >> > touching upon this aspect). Perhaps a recommendation would be to not go >> more >> > than 2-3 level deep as there is a risk of hiting these limits? >> > >> > 289 For example, suppose that a router receives an LSP with a >> Multi-Part >> > 290 Extended IS Reachability TLV. The first part contains key >> > 291 information K with sub-TLVs A, B, and C. The second part >> contains >> > 292 key information K with sub-TLVs D, E, and F. The receiving >> router >> > 293 must then process this as having key information K and >> sub-TLVs A, B, >> > 294 C, D, E, F, or, because ordering is irrelevant, sub-TLVs D, >> E, F, A, >> > 295 B, C, or any other permutation. >> > >> > <Discuss-2> What if there is a single instance sub-TLV within an >> MP-TLV? In >> > this case, the ordering would be important if for some reason (or >> error) the >> > sender were to send multiple copies of that single instance sub-TLV and >> the >> > guidance is to 'use the first, ignore the rest'. Therefore, should the >> receiver >> > not have to process based on the ordering in the LSP(s) and that the >> sender >> > also is deliberate about the ordering of the parts in the LSP(s)? >> > >> > 310 Specifying how to handle such cases is the responsibility of >> the >> > 311 document which defines the TLV. If such a document is not >> explicit >> > 312 in how to handle such cases, it is RECOMMENDED that the first >> > 313 occurrence in the lowest numbered LSP be used. In the case >> of IIHs, >> > 314 it is RECOMMENDED that the first occurrence in the IIH be >> used. >> > >> > <Discuss-3> Why RECOMMENDED (as in SHOULD) and not a MUST to ensure we >> arrive >> > at interoperable implementations down the line? Was there a proposal >> placed >> > before the WG to make this a MUST and some objection received on it? >> > >> > 399 8. Deployment Considerations >> > >> > <Discuss-4> I would like to discuss why this document is not >> recommending that >> > implementations and deployments move to RFC7356 as a long term approach >> to >> > scaling IS-IS to carry more information. RFC7356 is referenced in the >> > introduction, but some (short) additional text with references to its >> specific >> > sections may be a helpful guide. I see that the authors (and some other >> WG >> > members) had pointed to this work as "the long term solution", but the >> > document has not captured that aspect. >> > >> > >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > Please find below some comments provided inline in the idnit output of >> v14. >> > Would appreciate a response and some clarifications on the same. >> > >> > 110 The original TLV definition limits each TLV to a maximum of >> 255 >> > 111 octets of payload, which is becoming increasingly stressful. >> > >> > <minor> How about the following? >> > >> > CURRENT >> > The original TLV definition limits each TLV to a maximum of 255 octets >> of >> > payload, which is becoming increasingly stressful. >> > >> > SUGGEST >> > The original TLV definition limits each TLV to a maximum of 255 octets >> of >> > payload are being increasingly stressed. >> > >> > 113 Some TLV definitions have addressed this by explicitly >> stating that a >> > 114 TLV may appear multiple times inside of a Link State PDU >> (LSP). >> > 115 However, this has not been done for many legacy TLVs, >> leaving the >> > 116 situation somewhat ambiguous. >> > >> > <minor> s/legacy/other - I am not sure the use of the term "legacy" >> > is appropriate here since those TLVs are very much in use today and >> likely in >> > the future as well. >> > >> > 147 The mechanism described in this document has not been >> documented for >> > 148 all TLVs previously, so there is risk that interoperability >> problems >> > 149 could occur. This document provides the necessary protocol >> > 150 definition. >> > >> > <major> The above text is incomplete. I would suggest that this >> paragraph >> > simply puts forward references to document sections that are dealing >> with >> > interoperability challenges and backwards compatibility aspects. >> > >> > 167 3. Overview of TLVs >> > >> > 169 A TLV is a tuple of (Type, Length, Value) and can be >> advertised in >> > 170 IS-IS packets. Both Type and Length fields are one octet in >> size, >> > 171 which leads to the limitation that a maximum of 255 octets >> can be >> > 172 sent in a single TLV. >> > >> > <major> To do justice to the title of this section, why isn't it >> covering a >> > single-instance TLV as well? >> > >> > 247 The encoding of TLVs is not altered by the introduction of >> MP-TLV >> > 248 support. In particular, the "key" which is used to identify >> the set >> > 249 of TLVs which form an MP-TLV is the same key used in the >> absence of >> > 250 MP-TLV support. Also note the definition of the "key" >> exists in the >> > 251 specification(s) that define(s) the TLV. >> > >> > <minor> Perhaps >> > >> > CURRENT >> > Also note the definition of the "key" exists in the specification(s) >> that >> > define(s) the TLV. >> > >> > SUGGEST >> > The definition of the "key" for a given TLV is outside the scope of this >> > document and has to be part of the specification(s) that define(s) the >> TLV. >> > >> > 265 5. Procedure for Receiving Multi-Part TLVs >> > >> > 267 A router that receives a MP-TLV MUST accept all of the >> information in >> > 268 all of the parts. The order of arrival and placement of the >> TLV >> > 269 parts in LSP fragments is irrelevant. Multiple TLV parts >> MAY occur >> > 270 in a single LSP or parts MAY occur in different LSPs. >> > >> > 272 The placement of the TLV parts in an IIH is irrelevant. >> > >> > <major> Does "placement" here also cover "ordering"? Is the intention >> > here that it is not required that all parts be encoded consequtively in >> an >> > LSP (or across LSP fragments), and that no specific ordering is >> expected? Please >> > also see my discussion point 2. >> > >> > 351 For example, if there are mutiple TLVs associated with the >> > 352 advertisement of a neighbor and some routers do not use all >> of the >> > 353 link attributes advertised, then constrained path >> calculations based >> > 354 on those attributes are likely to produce inconsistent >> results and >> > 355 produce forwarding loops or dropped traffic. >> > >> > <minor> More specifically, this is for a distributed constraints path >> > calculation (as in FlexAlgo)? For P2P TE computations, this may not >> present a >> > loop but yes results might be not what is desired. >> > >> > 365 Routers which support MP-TLV for codepoints for which >> existing >> > 366 specifications do not explicitly define such support, but >> for which >> > 367 MP-TLV is applicable, SHOULD include this sub-TLV in a Router >> > 368 Capability TLV. >> > >> > <major> Why is this not a MUST even if it is for informational purposes? >> > Likely someone is relying on this information to be accurate. Please >> also see >> > the next comment. >> > >> > 373 This advertisement is for informational purposes only. >> > 374 Implementations MUST NOT alter what is sent or how what is >> received >> > 375 is processed based on these advertisements. >> > >> > <major> By implementations, I assume the reference here is to IS-IS >> protocol >> > behavior? Because a controller should be free to use this information >> an adapt >> > its behavior? Please clarify. >> > >> > 382 deployment scenarios in which it is used. Therefore, >> diligence is >> > 383 still required on the part of the operator to ensure that >> > 384 configurations which require the sending of MP-TLV for a >> given >> > 385 codepoint are not introduced on any router in the network >> until all >> > 386 routers in the network support MP-TLV for the relevant >> codepoints. >> > >> > <minor> Perhaps an informative reference here to the PICS YANG work >> would >> > help? >> > >> > 401 Sending of MP-TLVs in the presence of routers that do not >> correctly >> > 402 process such advertisements can result in interoperability >> issues, >> > 403 including incorrect forwarding of packets. This section >> discusses >> > 404 best practices which SHOULD be used when a deployment >> requires the >> > >> > <minor> Perhaps s/SHOULD/should since there isn't anything that is being >> > specified in this sentence. >> > >> > 416 Network operators SHOULD NOT enable MP-TLVs until ensuring >> that all >> > 417 implementations that will receive the MP-TLVs are capable of >> > 418 interpreting them correctly as described in Section 5. >> > >> > <minor> The above sentence is better placed towards end of section 8.1 >> where >> > those controls to enable/disable MP-TLVs are introduced. >> > >> > 420 8.1. Recommended Controls and Alarms >> > >> > 422 It is RECOMMENDED that implementations which support the >> sending of >> > >> > <major> Why not MUST instead of RECOMMENDED (i.e., SHOULD) for the >> global >> > control knob? This would be the bare minimum control that is required >> for the >> > operator? >> > >> > 423 MP-TLVs provide configuration controls to enable/disable >> generation >> > 424 of MP-TLVs. Given that MP-TLV support in a given >> implementation may >> > 425 vary on a per TLV basis, these controls SHOULD support per >> codepoint >> > 426 granularity. >> > >> > 444 Sending a single TLV with all the information about an >> object is >> > 445 preferable to sending multiple TLVs. It is simpler and more >> > 446 efficient to parse information from a single TLV than to >> combine the >> > 447 information from multiple TLVs. Implementations SHOULD NOT >> send >> > 448 multiple TLVs unless MP-TLV is applicable to the TLV and the >> amount >> > 449 of information which is required to be sent exceeds the >> capacity of a >> > 450 single TLV. For example, when additional space is required >> in an >> > 451 existing TLV, as long as there is space in the TLV, >> information >> > 452 SHOULD NOT be split into multiple TLVs. If there is no >> space in the >> > 453 current LSP to fit the now larger TLV, the TLV SHOULD be >> moved to a >> > 454 new LSP. >> > >> > <major> All of these are SHOULD instead of MUST. What would be the >> conditions >> > in which they cannot be followed by implementations? Please consider >> adding >> > some short explanatory text. >> > >> > 531 | 19 | IS-IS Flooding Request TLV | >> N | >> > 532 >> +-----------+----------------------------------------+----+ >> > 533 | 20 | Area Proxy | >> N | >> > >> > <major> This has sub-TLVs and its own sub-TLV registry that is missing. >> > >> > 534 >> +-----------+----------------------------------------+----+ >> > 535 | 21 | Flooding Parameters TLV | >> N | >> > >> > <major> This has sub-TLVs and its own sub-TLV registry that is missing. >> > >> > <EoR v14> >> > >> > >> > >> > _______________________________________________ >> > 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
