Hi Les, Indeed, all open issues have been addressed and I have updated my ballot.
Thanks for your (and your co-authors) patience as we went through these discussions and I hope it helped improve the document in a small way. Thanks, Ketan On Fri, Apr 25, 2025 at 11:44 PM Les Ginsberg (ginsberg) <[email protected]> wrote: > Ketan – > > > > I have uploaded V18 of the draft which reverts the changes in Section 8.1. > > I believe all open issues you have raised have now been addressed. > > Please let me know if that is not correct. > > > > Les > > > > > > *From:* Ketan Talaulikar <[email protected]> > *Sent:* Friday, April 25, 2025 10:11 AM > *To:* Les Ginsberg (ginsberg) <[email protected]> > *Cc:* The IESG <[email protected]>; [email protected]; > [email protected]; [email protected]; [email protected] > *Subject:* Re: Ketan Talaulikar's Discuss on draft-ietf-lsr-multi-tlv-14: > (with DISCUSS and COMMENT) > > > > 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]> 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]> > > Sent: Tuesday, April 22, 2025 10:50 AM > > To: Les Ginsberg (ginsberg) <[email protected]> > > Cc: The IESG <[email protected]>; [email protected]; lsr- > > [email protected]; [email protected]; [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]> 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] To unsubscribe send an email to [email protected]
