Hi Les, Thanks for your quick responses and please check inline below for follow-ups with KT.
For the points where I haven't responded, I agree and have nothing further to add. On Fri, Apr 11, 2025 at 12:24 PM Les Ginsberg (ginsberg) <ginsb...@cisco.com> wrote: > Ketan - > > Thanx for the thorough review. > Please see my responses inline. > > > -----Original Message----- > > From: Ketan Talaulikar via Datatracker <nore...@ietf.org> > > Sent: Thursday, April 10, 2025 1:07 AM > > To: The IESG <i...@ietf.org> > > Cc: draft-ietf-lsr-multi-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org > ; > > yingzhen.i...@gmail.com; yingzhen.i...@gmail.com > > Subject: Ketan Talaulikar's Discuss on draft-ietf-lsr-multi-tlv-14: > (with DISCUSS > > and COMMENT) > > > > 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? > > > [LES:] The scope of this document is quite intentionally limited to > specifying > MP-TLV. It does not introduce any encoding changes or new limitations > to the protocol. Nesting level of sub-TLVs is a legitimate concern, but is > independent of MP-TLVs. Your comment about "overhead" is applicable to a > single TLV as well. I do not see that a discussion of this concern is > appropriate in this draft. > KT> The document does specify a mechanism on how TLV space is expanded and it indicates the replication of the fixed and "keys" part at every TLV/sub-TLV/sub-sub-TLV level (i.e., it takes away more space in doing so). Therefore, as an extension, at least some text that touches upon its implications for multiple nested TLV/sub-TLV usage is warranted in my view. Such text will provide guidance to future developers working on ISIS extensions and is something that can be quoted/pointed to. E.g., when some extension is buried too deep in the TLV hierarchy, there may be a case to "pull it up" at the top-level even if it might not be the best choice from a pure data model perspective. Please consider this as an effort towards providing guidance to new participants in a standards track ISIS document. > > > 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. > > > [LES:] Order has never mattered in IS-IS. Whether an advertisement is > present > in LSP #1 or LSP #200 has no impact on processing of that information. > Similarly, order of sub-TLVs within a TLV is of no significance. > > The recommendation to use "the first occurrence in the lowest numbered LSP" > is addressing pathological/transient cases where information is duplicated. > It provides a deterministic resolution for such cases, but it does not > guarantee that the choice is "correct" i.e., that it is the latest > information. > No rule will guarantee that in such cases. > KT> This isn't about correctness. It is about consistency across routers in the network. > > > <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? > > > [LES:] We are not specifying normative behavior here - that is left to the > document which defines the codepoint. And there are existing examples of > different strategies > specified. This document is not the place for such normative statements. > KT> Well, the document is specifying normative behavior for those TLVs where the respective spec is not already explicitly on this aspect. I am not getting into the past. Neither should it be the responsibility of this document to try to grandfather all the myriad ways in which things are being handled by old/current implementations. The point is to move implementations forward towards interoperability, and hence the MUST instead of SHOULD will help achieve that goal in this regard. To me, this is in the same spirit as RFC8918. > > > 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. > > > [LES:] As an author of RFC 7356 I appreciate your interest. 😊 > But this document is dealing with the current version of the protocol with > its > current limitations. It is not a position paper on what the future of the > protocol should be. > KT> I disagree with your positioning of this document. There were more than one proposal in front of the WG, and this particular one was picked for the 8-bit TLV space encoding due to good reasons. It comes with its various challenges - space, interoperability, etc. - so it is not perfect but pragmatic. At the same time, during the WG discussion there were times when the topic of a long term solution has come up (a few of the threads below) that concluded with pointing to RFC7356 as a "clean" solution (albeit introducing in existing deployments is challenging). So, I am wondering why the WG (not just the authors) would not want to at least mention that RFC7356 provides the long term solution? I will leave the recommendation part to the WG (though I personally strongly favor it). https://mailarchive.ietf.org/arch/msg/lsr/rCHObOHT18sg61Dn60SJlvUWodU/ https://mailarchive.ietf.org/arch/msg/lsr/987n5mHQptaPpmc0EjnJ-p9yZGM/ > > > > > ---------------------------------------------------------------------- > > 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. > > > [LES:] I don't find your suggestion grammatically appealing. How about: > > "The original TLV definition limits each TLV to a maximum of 255 octets of > payload, a limitation which is becoming increasingly problematic." > > ?? > KT> Sounds good to me. I had trouble with "stressful" :-) > > > 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. > > > [LES:] How about "for many currently defined TLVs"..." > KT> Ack > > > 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. > > > [LES:] This text is in the "Introduction". > It therefore is expected that the text here is meant to introduce what > follows. > The substance of the draft is - and is expected to be - in the subsequent > sections. > > I do not understand your objection. > KT> A text suggestion to clarify my point: The mechanism described in this document has not been documented for all TLVs previously. The associated interoperability challenges are described in Sections 7 and 8. > > > 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? > > > [LES:] It is discussing a single TLV instance. > MP-TLV is two or more related "single instance TLVs". > I am at a loss as to your concern. > KT> Let us consider the TLV for TE Default Metric. Which subsection of section 3 does it belong to? I am referring to covering non-MP TLVs since the section title says "Overview of TLVs" (as in all types of ISIS TLVs). > > > 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. > > > [LES:] I am OK with your revised text - except for the phrase "is outside > the scope". The point being made here is that definition already exists in > other > documents. > "scope" is a non-issue. > KT> If there are no strong objections, I would prefer that this gets called out of scope. It will help. > > > 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. > > > [LES:] Yes - it covers "ordering". > Rereading the text, that seems very clear to me. > I do not understand your confusion. > KT> My point is that ordering is relevant when dealing with non-MP sub-TLVs spread across multiple parts of a MP-TLV. So, the receiver cannot just ignore the ordering. If it does so, it will not be able to pick the "right" (e.g., the first instance in the lowest number LSP) non-MP sub-TLV instance for consistency across routers. > > > 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. > > > [LES:] Sure. But this is only an example of problems which may occur, > not a comprehensive list of all possible problems - which could fill many > pages. > KT> It is important to specify the scope as ISIS calculations. That would help address this comment. The current text refers to "constrained path calculations" which could be construed as covering something that a TE controller does as well. > > > 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. > > > [LES:] This has been answered previously. > Here is my earlier reply to Eric: > > <snip> > 1)There are existing implementations which support MP-TLV for some > codepoints - requiring this advertisement would introduce backwards > compatibility issues > > 2)Given that this sub-TLV is for informational purposes only, requiring it > to be sent seems inappropriate. Implementations which want to be helpful to > operators will likely choose to send it, but if they do not claiming that > such an implementation is non-conformant serves no useful purpose. > <end snip> > KT> I am with Eric on this. The purpose of this document should not be to grandfather existing implementation choices that were made in the absence of this spec. If some implementation is claiming compliance to this spec, then I don't see why it cannot be mandated to advertise the capability as well. There is no harm in adding text that there MAY be implementations which support MP-TLV before this specification but do not advertise the capability. On the second point, we should not preclude how this information is used by the operator (or other systems) - the goal of ISIS > > > > 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. > > > [LES:] I am not at all convinced that a controller is free to ignore > portions > of an MP-TLV. Doing so risks the controller operating on faulty or > incomplete information. Nevertheless, I will change: > > "Implementations" to "IS-IS protocol implementations" > KT> Thanks that change works. > > > 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? > > > [LES:] I prefer not to do this - though I understand your motivation. > The PICS work may well proceed slowly - or not proceed at all depending on > WG interest. That remains to be seen. > KT> I agree. However, following the WG discussions, I sense the interest from operators in finding this information (in a management plane). And while it is out of scope of this document, a pointer to that work will (optimistically) generate interest in PICS work. More importantly, it conveys that the IETF has not abandoned this operator requirement, just that it is solving it outside in the management plane. > > > 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. > > > [LES:] As you may recall, the use of SHOULD here is a compromise. Some > WG members wanted a MUST, but the authors pushed back on this because > we felt strongly that it is not in the purview of an RFC to mandate > behaviors which are unenforceable and undetectable. > > I would appreciate if you did not reopen this debate. > KT> Hmm ... I am suggesting changing SHOULD -> should (not talking about MUST here ... that is further below). > > > 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. > > > [LES:] OK > > > 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? > > > [LES:] Once again, you are trying to reopen something which was debated > at considerable length previously. The authors feel strongly that it is not > within the purview of an RFC to mandate how implementations implement > configuration. It is also unenforceable. The choice to use RECOMMENDED was > intentionally made and we do not want to revisit this choice. > KT> This is only about a global control for MP-TLV (not the TLV specific one) that we are talking about. You are of course correct that IETF cannot enforce the choices that implementations make. However, there is always a balance to strike. In this case, in my view, the global control knob is something that can be made a MUST. Again, there is no requirement on this document having to grandfather everything that implementations are doing currently, but to set an appropriate future direction. > > > 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. > > > [LES:] This also was discussed at length in the WG. > The maxim of "be strict in what you send but generous in what you receive" > is > being applied here. > We are describing the most efficient way to encode MP-TLVs and indicating > implementations SHOULD follow this behavior. > If the information is encoded correctly - but just packed sub-optimally - > it is not a benefit to network operation to have receivers ignore it - > which would be required in order for MUST to be appropriate. > It also could lead to some petty debates as to what is optimally packed > and what isn't. > KT> OK. Thanks. I caught up on that thread in the WG and I am good with what is in the document currently. Thanks, Ketan > > > > 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. > > > [LES:] OK - thanx for catching this. > > > 534 > +-----------+----------------------------------------+----+ > > 535 | 21 | Flooding Parameters TLV | > N | > > > > <major> This has sub-TLVs and its own sub-TLV registry that is missing. > > > [LES:] OK - thanx for catching this. > > Les > > > <EoR v14> > > > > > >
_______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
