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
