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? > > > > > <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/ > > > 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. > > > > > > > ---------------------------------------------------------------------- > > 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. > > > > 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. > > > > > 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. > > > > > 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. > > > 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. Thanks, Ketan
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
