Hi, Ketan:
I know once the IESG can’t address the unsolved challenge, according to https://datatracker.ietf.org/doc/html/rfc2026#section-6.5.2, I can only ask the IAB to step in. I have summarized again the unsolved challenges with the updated “Unsolved Challenges of MP-TLV” draft( [1]) I am not arguing with you the procedure, but the technical responses. For anyone think/declare this document is ready, please response the issues described in section 3, section 4 and section 5 of [1] [1] Unsolved Challenges of MP-TLV-02: https://datatracker.ietf.org/doc/html/draft-wang-lsr-unsolved-challenge-of-mp-tlv-02. Best Regards Aijun Wang China Telecom 发件人: [email protected] [mailto:[email protected]] 代表 Ketan Talaulikar 发送时间: 2025年4月26日 11:58 收件人: Aijun Wang <[email protected]> 抄送: [email protected]; Les Ginsberg <[email protected]>; The IESG <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] 主题: [Lsr] Re: Ketan Talaulikar's Discuss on draft-ietf-lsr-multi-tlv-14: (with DISCUSS and COMMENT) Hi Aijun, In case you were not familiar with the process, I would like to update you that my review as part of the IESG Evaluation of this document is now complete. The result is reflected in the ballot and the discussions are on the mailer. Beyond that, I do not have anything further to add/respond to your repeated (and IMHO disruptive) interventions. Thanks, Ketan On Sat, Apr 26, 2025 at 2:34 AM Aijun Wang <[email protected] <mailto:[email protected]> > wrote: Hi, Ketan: It seems that you don’t want to break the Loop here: 1) The responses from the chair of IESG for the previous appeal of “WG consensus” is there will be IESG evaluation to this document. 2) Until now, even you, as the routing AD, state that “with responses (where we ultimately go with the WG consensus).” Then, I MUST ask the chair of IESG return this document to the WG, if the unsolved technical challenges can’t be addressed even by IESG’s experts. I have given you and the community another detail example at https://mailarchive.ietf.org/arch/msg/lsr/Yy4yVfhp20J2L-1sG7ebLopORl8/ together with the descriptions in draft [1]. [1] https://datatracker.ietf.org/doc/draft-wang-lsr-unsolved-challenge-of-mp-tlv/ Aijun Wang China Telecom On Apr 26, 2025, at 01:12, Ketan Talaulikar <[email protected] <mailto:[email protected]> > wrote: Hi Les, Thanks to you and your co-authors for the patience and diligence as we discuss through my comments/suggestions. I believe all of my concerns in DISCUSS are addressed - as in either with updates to the document, or with responses (where we ultimately go with the WG consensus). However, there is one change in section 8.1 below where I have some concerns about the proposed text - more details below. I will update my ballot shortly after we close that one outstanding thing. Please also check inline below with KT3 for responses on some of the points. On Fri, Apr 25, 2025 at 8:26 AM Les Ginsberg (ginsberg) <[email protected] <mailto:[email protected]> > wrote: Ketan - Thanx very much for your time and diligence in working to close on the remaining issues. I have posted V17 of the draft which I hope addresses all of the open DISCUSS points. Please see my responses inline below. "LES3" > -----Original Message----- > From: Ketan Talaulikar <[email protected] <mailto:[email protected]> > > Sent: Tuesday, April 22, 2025 10:50 AM > To: Les Ginsberg (ginsberg) <[email protected] <mailto:[email protected]> > > Cc: The IESG <[email protected] <mailto:[email protected]> >; > [email protected] <mailto:[email protected]> > ; lsr- > [email protected] <mailto:[email protected]> ; [email protected] <mailto:[email protected]> > ; [email protected] <mailto:[email protected]> > Subject: Re: Ketan Talaulikar's Discuss on draft-ietf-lsr-multi-tlv-14: (with > DISCUSS and COMMENT) > Hi Les, Thanks for your quick response and also for your patience while I was away. I've trimmed out the parts where we have reached an agreement. Please check inline below with KT2 for further follow ups. I'll update the ballot once we've reached a conclusion on the open points. On Sat, Apr 12, 2025 at 3:00 AM Les Ginsberg (ginsberg) <[email protected] <mailto:[email protected]> > wrote: > > ---------------------------------------------------------------------- > 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. [LES2:] Hopefully I can say this without offending you… IS-IS has always been frugal as regards the space used for encoding information. This is because we have always been conscious both of the 255 octet TLV limit and the overall limit of LSP space. You may recall examples of this in cases where some other protocol (e.g., BIER) proposes an encoding for advertising information in the IGPs and uses the same format for OSPF and IS-IS. We always insist this be revised for IS-IS. Your major experience is with OSPF – and so you may think that the introduction of MP-TLV would require extra diligence in this regard – but I am telling you this is not the case. As a WG member, I would not allow inefficient encoding to progress – completely independent of any MP-TLV considerations. And I think you can examine the output of IS-IS RFCs over that last 25 years as proof that the WG is already diligent in this regard. So your well intentioned concern is simply not appropriate. KT2> Les, you are preaching to the choir :-) ... I am familiar with the importance of efficient encoding in ISIS. I also agree that this consideration applies even outside of MP TLV. I was looking for a reference to these considerations for the benefit of new participants but I didn't find them - this is "ISIS tribal knowledge" so I'll leave it to the WG wisdom. That said, this isn't really a DISCUSS criteria anymore. We can consider this closed. > 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. [LES2:] Well, you started this discuss asserting that: “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)?...” And I repeat that order does not matter. Now you seem focused on trying to standardize behavior in the event of duplicate/conflicting information. Please be more precise in your comments. As regards the use of RECOMMENDED in this paragraph, individual codepoints can choose to specify a different deterministic method to handle duplicate/conflicting information for that codepoint. I am not suggesting that they should (quite the contrary) – but if they have some reason to do so and they specify it clearly this is not an issue for the protocol. That is why we chose RECOMMEND here. I stand by that choice. KT2> We have a disconnect. Let me take a step back to clarify. When the text is referring to the sub-TLVs A, B, C, D, E, F are they unique ones (i.e., different codepoints)? If so, I think the text is correct. However, I can read the same text as just 6 different sub-TLVs where B and E may be of the same type - and in that case, the rules of using the first instance in the lowest LSP ID still applies for non-MP types (before concatenation happens). Can you please clarify? [LES3:] I have revised the text to indicate all of the codepoints (A,B,C...) are unique. KT3> Thank you for that clarification. This taken along with the text about the default normative behavior for TLVs where MP-TLV applicability is "N" takes care of my concerns. > <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. [LES2:] RFC 8918 addressed a behavior that was clearly broken. That is not the case here. Please do not use this analogy. I believe my response above applies. KT2> It is important that we have a default normative behavior for such cases that is solid. I would encourage you to consider using a MUST in this case. Also, refer to this: https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ [LES3:] I have removed "RECOMMENDED" and stated the behavior in a normative manner consistent with the IESG link you provided. Thanx. KT3> Thank you. I believe this will help us achieve consistency in the handling of such (error or transient) conditions. > 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/ [LES2:] Thanx for the email pointers – but they only reinforce my point. Those emails were an attempt to separate the discussion of what we need to do to address the 255 octet limit using the current version of the protocol from a discussion of how a new /not backwards compatible version of the protocol would address the issue. My argument was – and continues to be – that is a separate topic – does not belong in the MP-TLV specification. RFC 7356 is mentioned in the draft – so that request from you is already met. Further discussion of how RFC 7356 (or some other solution) would address the issues is out of scope. The draft is focused on what needs to be done with the current version of the protocol. KT2> Yes, RFC 7356 is indeed referenced and it also talks about 16-bit length values. Like I said, I will leave this to the authors if you would like to add something further. In any case, please consider this as a general comment and not a DISCUSS. [ LES3:] I added some text to clarify that RFC 7356 is not backwards compatible and therefore there is still a need to address the problem using the current 8-bit TLVs. KT3> This is much better text. Thanks. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 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. [LES2:] I have added some text – not quite as you suggested – but hopefully meets your goal. KT2> My concern was with the text that says "so there is risk that interoperability problems could occur" - can this be taken off as well? The further sections in the document do cover the challenges along with the solution. [LES3:] I removed the text as you suggested. > 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. [LES2:] I still cannot understand your point. The statement as you write it is incorrect. Order of sub-TLVs at a given level of hierarchy does not matter. Perhaps a specific example of what is troubling you would help?? KT2> Please see my latest response on Discuss-2 above. That clarification should cover this comment as well. [ LES3:] Hopefully the clarification about "unique" codepoints also addresses this issue. KT3> Yes, it does. > 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. [LES2:] This seems to me to be another aspect of your belief that controllers don’t have to understand MP-TLVs – which I think is misguided. Controllers have to correctly parse all of the information advertised by IS-IS. They may choose, based on local policy, to ignore some attributes – but if they cannot correctly parse the information advertised then they are applying that policy on incomplete or incorrect information. KT2> There is perhaps another disconnect here. I am not making any statements about controllers not having to parse/support all TLVs (including MP-TLVs). My point was about distributed constrained path calculations vs a non-distributed (could be controller or local TE compute on a router) constrained path calculation. Here is a suggestion: CURRENT For example, if there are multiple TLVs associated with the advertisement of a neighbor and some routers do not use all of the link attributes advertised, then constrained path calculations based on those attributes are likely to produce inconsistent results and produce forwarding loops or dropped traffic. SUGGEST For example, if there are multiple TLVs associated with the advertisement of a neighbor and some routers do not use all of the link attributes advertised, then distributed constrained path calculations by IS-IS implementations based on those attributes are likely to produce inconsistent results and produce forwarding loops or dropped traffic. This is just a suggestion. I hope my point is clarified and will leave it to the authors to wordsmith as appropriate. [LES3:] I have reworded the text in a way that I think applies to any implementation (router or controler). KT3> This works. > 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 [LES2:] There is a fundamental disagreement here. The advertisement says “This implementation might have MP-TLV support for a codepoint you are interested in.” As such, it is merely a hint to the operator. Making this mandatory would mean that an implementation that actually has MP-TLV support for a given codepoint would be considered unusable/non-compliant simply because it did not advertise the sub-TLV which says “I have MP-TLV for some codepoint.” I do not agree to this. KT2> This is a comment so we go with the WG consensus. However, I am leaning on the IESG statement on BCP14 keywords usage here. Perhaps adding some text that suggests that this is a recommendation since there are implementations that already do support the MP TLV processing but do not advertise this capability - therefore, it would be problematic to assume non support of MP Capability implies non support of MP TLV processing? I leave this to the authors. [LES3:] I left this text unchanged. KT3> Sure. We will go with the WG consensus on this one. > 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. [LES2:] We are not in agreement. Don’t have much new to say. KT2> Similar response as before. Please consider adding some reason or if not changing to MUST. To be clear, this is a non-blocking comment. [LES3:] I revised the wording (and the section title) - removing "RECOMMENDED" . I think the language is now consistent with the updated IESG guidance you highlighted. KT3> I have some concerns with this change. The term "useful" may be seen as dilution from the WG consensus that was "RECOMMENDED". I think it is best to revert the text in the body of section 8.1 also to what came from the WG (same as what we decided for the previous comment) rather than trying to wordsmith it based on the IESG guidance. As a reminder, this was a non-blocking comment in the first place. Thanks, Ketan Thanx again for the thorough review. Les Thanks, Ketan _______________________________________________ Lsr mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]>
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
