Ballot for draft-ietf-lsr-multi-tlv
Discuss
Yes
No Objection
No Record
Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
Thanks to the authors, first for taking up this work, and next for taking it through a "rigorous" WG process while focusing on technical aspects. However, there are still some aspects in the document that I would like to have a discussion on (inline using idnits output of v14): 152 This document specifies a means for extending TLVs where no extension 153 mechanism has been previously explicitly specified, and defines this 154 mechanism as the default extension mechanism for future TLVs. The 155 mechanism described in this document is applicable to top level TLVs 156 as well as any level of sub-TLVs which may appear within a top level 157 TLV. <discuss-1> Given that a TLV is bounded at 255 bytes, by definition its sub-TLVs (at first and subsequent levels) are bounded to an even smaller limit. This implies that if > 255 bytes need to be encoded in a 1st level sub-TLV, then we would need two parts of the parent TLV as well. While this is implicit, some text on this would be helpful - I would not be surprised if this gets missed by people working on future specifications. Taking it further, this aspect imposes some design restriction on the level of sub-TLV/sub-sub-TLV/... that can be designed for future extensions due to the reducing bounds as we go deeper. At some point, the overhead of the "process of breaking into parts" may start to bring in higher overheads than the actual information being conveyed. This brings in challenges in protocol encoding design (specifically with many layer of sub-TLVs). I would like to discuss why this document isn't providing such a guidance as well (or at least touching upon this aspect). Perhaps a recommendation would be to not go more than 2-3 level deep as there is a risk of hiting these limits? 289 For example, suppose that a router receives an LSP with a Multi-Part 290 Extended IS Reachability TLV. The first part contains key 291 information K with sub-TLVs A, B, and C. The second part contains 292 key information K with sub-TLVs D, E, and F. The receiving router 293 must then process this as having key information K and sub-TLVs A, B, 294 C, D, E, F, or, because ordering is irrelevant, sub-TLVs D, E, F, A, 295 B, C, or any other permutation. <Discuss-2> What if there is a single instance sub-TLV within an MP-TLV? In this case, the ordering would be important if for some reason (or error) the sender were to send multiple copies of that single instance sub-TLV and the guidance is to 'use the first, ignore the rest'. Therefore, should the receiver not have to process based on the ordering in the LSP(s) and that the sender also is deliberate about the ordering of the parts in the LSP(s)? 310 Specifying how to handle such cases is the responsibility of the 311 document which defines the TLV. If such a document is not explicit 312 in how to handle such cases, it is RECOMMENDED that the first 313 occurrence in the lowest numbered LSP be used. In the case of IIHs, 314 it is RECOMMENDED that the first occurrence in the IIH be used. <Discuss-3> Why RECOMMENDED (as in SHOULD) and not a MUST to ensure we arrive at interoperable implementations down the line? Was there a proposal placed before the WG to make this a MUST and some objection received on it? 399 8. Deployment Considerations <Discuss-4> I would like to discuss why this document is not recommending that implementations and deployments move to RFC7356 as a long term approach to scaling IS-IS to carry more information. RFC7356 is referenced in the introduction, but some (short) additional text with references to its specific sections may be a helpful guide. I see that the authors (and some other WG members) had pointed to this work as "the long term solution", but the document has not captured that aspect.
Please find below some comments provided inline in the idnit output of v14. Would appreciate a response and some clarifications on the same. 110 The original TLV definition limits each TLV to a maximum of 255 111 octets of payload, which is becoming increasingly stressful. <minor> How about the following? CURRENT The original TLV definition limits each TLV to a maximum of 255 octets of payload, which is becoming increasingly stressful. SUGGEST The original TLV definition limits each TLV to a maximum of 255 octets of payload are being increasingly stressed. 113 Some TLV definitions have addressed this by explicitly stating that a 114 TLV may appear multiple times inside of a Link State PDU (LSP). 115 However, this has not been done for many legacy TLVs, leaving the 116 situation somewhat ambiguous. <minor> s/legacy/other - I am not sure the use of the term "legacy" is appropriate here since those TLVs are very much in use today and likely in the future as well. 147 The mechanism described in this document has not been documented for 148 all TLVs previously, so there is risk that interoperability problems 149 could occur. This document provides the necessary protocol 150 definition. <major> The above text is incomplete. I would suggest that this paragraph simply puts forward references to document sections that are dealing with interoperability challenges and backwards compatibility aspects. 167 3. Overview of TLVs 169 A TLV is a tuple of (Type, Length, Value) and can be advertised in 170 IS-IS packets. Both Type and Length fields are one octet in size, 171 which leads to the limitation that a maximum of 255 octets can be 172 sent in a single TLV. <major> To do justice to the title of this section, why isn't it covering a single-instance TLV as well? 247 The encoding of TLVs is not altered by the introduction of MP-TLV 248 support. In particular, the "key" which is used to identify the set 249 of TLVs which form an MP-TLV is the same key used in the absence of 250 MP-TLV support. Also note the definition of the "key" exists in the 251 specification(s) that define(s) the TLV. <minor> Perhaps CURRENT Also note the definition of the "key" exists in the specification(s) that define(s) the TLV. SUGGEST The definition of the "key" for a given TLV is outside the scope of this document and has to be part of the specification(s) that define(s) the TLV. 265 5. Procedure for Receiving Multi-Part TLVs 267 A router that receives a MP-TLV MUST accept all of the information in 268 all of the parts. The order of arrival and placement of the TLV 269 parts in LSP fragments is irrelevant. Multiple TLV parts MAY occur 270 in a single LSP or parts MAY occur in different LSPs. 272 The placement of the TLV parts in an IIH is irrelevant. <major> Does "placement" here also cover "ordering"? Is the intention here that it is not required that all parts be encoded consequtively in an LSP (or across LSP fragments), and that no specific ordering is expected? Please also see my discussion point 2. 351 For example, if there are mutiple TLVs associated with the 352 advertisement of a neighbor and some routers do not use all of the 353 link attributes advertised, then constrained path calculations based 354 on those attributes are likely to produce inconsistent results and 355 produce forwarding loops or dropped traffic. <minor> More specifically, this is for a distributed constraints path calculation (as in FlexAlgo)? For P2P TE computations, this may not present a loop but yes results might be not what is desired. 365 Routers which support MP-TLV for codepoints for which existing 366 specifications do not explicitly define such support, but for which 367 MP-TLV is applicable, SHOULD include this sub-TLV in a Router 368 Capability TLV. <major> Why is this not a MUST even if it is for informational purposes? Likely someone is relying on this information to be accurate. Please also see the next comment. 373 This advertisement is for informational purposes only. 374 Implementations MUST NOT alter what is sent or how what is received 375 is processed based on these advertisements. <major> By implementations, I assume the reference here is to IS-IS protocol behavior? Because a controller should be free to use this information an adapt its behavior? Please clarify. 382 deployment scenarios in which it is used. Therefore, diligence is 383 still required on the part of the operator to ensure that 384 configurations which require the sending of MP-TLV for a given 385 codepoint are not introduced on any router in the network until all 386 routers in the network support MP-TLV for the relevant codepoints. <minor> Perhaps an informative reference here to the PICS YANG work would help? 401 Sending of MP-TLVs in the presence of routers that do not correctly 402 process such advertisements can result in interoperability issues, 403 including incorrect forwarding of packets. This section discusses 404 best practices which SHOULD be used when a deployment requires the <minor> Perhaps s/SHOULD/should since there isn't anything that is being specified in this sentence. 416 Network operators SHOULD NOT enable MP-TLVs until ensuring that all 417 implementations that will receive the MP-TLVs are capable of 418 interpreting them correctly as described in Section 5. <minor> The above sentence is better placed towards end of section 8.1 where those controls to enable/disable MP-TLVs are introduced. 420 8.1. Recommended Controls and Alarms 422 It is RECOMMENDED that implementations which support the sending of <major> Why not MUST instead of RECOMMENDED (i.e., SHOULD) for the global control knob? This would be the bare minimum control that is required for the operator? 423 MP-TLVs provide configuration controls to enable/disable generation 424 of MP-TLVs. Given that MP-TLV support in a given implementation may 425 vary on a per TLV basis, these controls SHOULD support per codepoint 426 granularity. 444 Sending a single TLV with all the information about an object is 445 preferable to sending multiple TLVs. It is simpler and more 446 efficient to parse information from a single TLV than to combine the 447 information from multiple TLVs. Implementations SHOULD NOT send 448 multiple TLVs unless MP-TLV is applicable to the TLV and the amount 449 of information which is required to be sent exceeds the capacity of a 450 single TLV. For example, when additional space is required in an 451 existing TLV, as long as there is space in the TLV, information 452 SHOULD NOT be split into multiple TLVs. If there is no space in the 453 current LSP to fit the now larger TLV, the TLV SHOULD be moved to a 454 new LSP. <major> All of these are SHOULD instead of MUST. What would be the conditions in which they cannot be followed by implementations? Please consider adding some short explanatory text. 531 | 19 | IS-IS Flooding Request TLV | N | 532 +-----------+----------------------------------------+----+ 533 | 20 | Area Proxy | N | <major> This has sub-TLVs and its own sub-TLV registry that is missing. 534 +-----------+----------------------------------------+----+ 535 | 21 | Flooding Parameters TLV | N | <major> This has sub-TLVs and its own sub-TLV registry that is missing. <EoR v14>
Hi Parag, Tony L., Tony P., Shraddha, and Les, Many thanks for the effort put into this specification. I strongly support the objective of this effort and like the pragmatic approach followed here. So, thanks again. I have some comments that I’d like to be addressed/discussed, especially the ones marked with (*). # General ## (nit) Please use consistent wording MP-TLV vs. Multi-Part TLV through the document ## (nit) I may be old school, but I think the document should use “router”, instead of “node”. # Abstract (nit): not every technologies is adding info into IGP + split a long sentence: OLD: New technologies are adding new information into IS-IS while deployment scales are simultaneously increasing, causing the contents of many critical TLVs to exceed the currently supported limit of 255 octets. NEW: Deploying some new techniques relies upon adding new information into IS-IS while deployment scales are simultaneously increasing. This causes the contents of many critical TLVs to exceed the currently supported limit of 255 octets. # Introduction ## (nit) s/Some TLV definitions have addressed this by explicitly/Some TLV definitions have addressed this issue by explicitly ## Justification for alternate mechanisms (*) CURRENT: Any future document which proposes a different mechanism for scaling TLV contents for a given codepoint MUST provide justification. I’m not fun of normative language in an introduction (as the context is not yet well established), we may consider replacing “provide justification” with a more meaningful guidance, e.g., “identify the shortcomings of the multiple part approach and motivate the need for a another mechanism”. Also, you may consider: s/ Any future document which proposes/Any future document that proposes standardizing ## I would delete ", if they choose not to specify another extension mechanism". # Section 3.2.1 Please cite where type 22 is defined + remind how the identifiers are encoded: OLD: As an example, consider the Extended IS Reachability TLV (type 22). … * Optionally one or more of the following link identifiers: NEW: As an example, consider the Extended IS Reachability TLV (type 22) [RFC5305]. … * Optionally one or more of the following link identifiers encoded as sub-TLVs (0-244 octets): # Section 4: On Keys CURRENT: The encoding of TLVs is not altered by the introduction of MP-TLV support. In particular, the "key" which is used to identify the set of TLVs which form an MP-TLV is the same key used in the absence of MP-TLV support. Also note the definition of the "key" exists in the specification(s) which define(s) the TLV. NOTE: This document intentionally does not include a definition of the key for each codepoint. To do so would be redundant and risk unintentionally deviating from the definition which already exists in the relevant specifications. ## Maybe it is accurate to also remind in the note that term “key” is not used per se in these specs. ## (nit) BTW, please fix this part: s/specification(s) which define(s) the TLV/specification(s) that define(s) a TLV. # Section 5 (*) CURRENT: When processing MP-TLVs, implementations MUST NOT impose a minimum length check. Agree... however, should we have a max of MP-TLVs to be used as a guard for splitting the information into a large numbers of TLVs? # Section 6 ## I don’t parse what is meant by "advertised in a codepoint". I guess you meant advertised with or in a TLV with a type/codepoint. I suggest to make the following change: s/may be advertised in a single codepoint /may be advertised with a single codepoint ## Simplify OLD: This guarantees that any new codepoints defined by future protocol extensions will explicitly indicate the applicability of Multi-Part TLV procedures to the new codepoints. NEW: Future allocations will explicitly indicate the applicability of Multi-Part TLV procedures to the new codepoints. # Section 7 ## Please elaborate more the "extremely disruptive" mention in the following: CURRENT: Introduction of the use of MP-TLV for codepoints where the existing specifications have not explicitly defined MP-TLV support can be extremely disruptive to network operations in cases where not all ## I don’t parse the following: CURRENT: It is presumed that if such support is provided that it applies to all relevant codepoints. ## Consider adding examples of deployment scenarios OLD: a given implementation might limit MP- TLV support to particular codepoints based on the needs of the deployment scenarios in which it is used. NEW: a given implementation might limit MP- TLV support to particular codepoints based on the needs of the deployment scenarios in which it is used (e.g., set by default or controlled by a configuration parameter). ## I suggest to delete the following. This message is already stated in the document: CURRENT: Note that with the introduction of explicit specification of MP-TLV applicability for codepoints (Section 9), implicit MP-TLV support will never occur in the future. ## What is the goal of this MUST if the implem is already conformant?! (*) CURRENT: Where MP-TLV support is explicitly defined, conformant implementations MUST support MP-TLV. # Section 8: Not sure the normative language makes sense in the following text: CURRENT: Sending of MP-TLVs in the presence of nodes which do not correctly process such advertisements can result in interoperability issues, including incorrect forwarding of packets. This section discusses best practices which SHOULD be used when a deployment requires the use of MP-TLVs for codepoints for which existing specifications do not explicitly indicate MP-TLV support. # Section 8.1 ## Configuration and defaults (*) CURRENT: It is RECOMMENDED that implementations which support the sending of MP-TLVs provide configuration controls to enable/disable generation of MP-TLVs. (1) Should we also be able to expose the actual (configurable) capabilities? (2) Given the implications of partial support, can we suggest the default be to disable? ## Does the report in the following covers logging? Can we be explicit here? (*) CURRENT: Implementations which support disablement of MP-TLVs MUST report alarms under the following conditions: # Section 9.2: (nit) s/ This document requests that IANA extend/This document requests that IANA extends # Section 10 (*) CURRENT: This document creates no new security issues for IS-IS. Isn’t generalizing applicability of MP-TLV may be misused (e.g., abuse the number of occurrences to consume computing resources of a receiver)? Cheers, Med
Thank you to David Mandelberg for their secdir reviews. Also for the detailed shepherd review by Yingzhen Qu. General: I think the definition and explanation of how the term 'key' as used in this context is good. I also agree w/ Ketan's comment on lines 247-251 for how to clarify the wording about where 'key' is defined for a given TLV. Section 10: The ability to add multiple TLVs to an IS-IS session (possibly not the right word) may increase the ability to cause a denial of service via resource exhaustion. If that is a risk, please address this security concern. Otherwise, please clarify why it isn't a concern.
Thank you for writing this document, I have only one comment: “A TLV may contain information in its fixed part that is not part of the key.” - Could this be an RFC 2119 “MAY”?
Thank you to the authors for this document, and a special thank you to the document shepherd for a very thorough review with pointers to much of the relevant WG discussion around specific points of contention. Most of my comments were nits that have been addressed by other reviewers ballots so I will not repeat them here. This leaves me with just a single comment on the abstract: Abstract# The sentence "Extensions exist that require significant IS-IS changes that could help address the problem, but a less drastic solution would be beneficial" implies that this document provides a pragmatic solution rather than a more intrusive update to the IS-IS protocol. This leaves me wondering what these extensions are, and I see no discussion around this further into the document (unless the text around [RFC7356] is what the authors were alluding too), or whether deployment of the solution in this document would allow for future extensions to be backwards compatible should the need arise to further define these "Extensions" in the future. Practically speaking I see no reasons why this should be a problem given that "significant IS-IS changes" could have implications far beyond MP-TLV so I am wondering if this sentence should just be removed as it does not really provide any value.
I had previously reviewed this document, as well as another objecting to it, in the course of understanding the appeal that was raised. While it would be nice to have a crisper definition of the "key" for each TLV, I understand and agree with the WG consensus that the key for each relevant TLV is sufficiently clear to implementers in practice. This document acknowledges and formalizes an existing workaround actively being used, and existing successful interoperation is the best evidence that this is clear to implementers.
Thank you to Peter Yee for the GENART review.
** Section 9.2.1. Editorial.
| 17 | IS-IS Area Node IDs TLV | N |
+-----------+----------------------------------------+----+
| 18 | IS-IS Flooding Path TLV | N |
+-----------+----------------------------------------+----+
| 19 | IS-IS Flooding Request TLV | N |
| 126 | IPv4 Algorithm Prefix Reachability TLV | N |
+-----------+----------------------------------------+----+
| 127 | IPv6 Algorithm Prefix Reachability TLV | N |
These code point names include “TLV” as a suffix in this document, but that suffix is NOT present in the IANA registry.
# Éric Vyncke, INT AD, comments for draft-ietf-lsr-multi-tlv-13 CC @evyncke Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks (and congratulations) to Yingzhen Qu for the shepherd's detailed write-up including the WG consensus (and the history) *and* the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric ## COMMENTS (non-blocking) ### Abstract s/New technologies are adding new information/New specifications and IS-IS extensions are adding new information/ ### Section 1 Unsure whether IS-IS is used over the public Internet in `The continued growth of the Internet` :-) In the first paragraph, it is unclear whether the 255 applies per TLV or for the whole set of TLV (even if the reader can have a guess, let's be clear). s/Any future *document* *which* proposes/Any future *IETF specification* *that* proposes/ ? Should there be an exhaustive list rather than `Some examples of this are` ? Please introduce "LSP" before first use. Strongly suggest to indicate that the MP-TLV capability is negotiated (as I had big ??? in mind until section 7). ### Section 4 Bear with my lack of IS-IS expertise, but can a IIH message be fragmented in several layer-2 packets ? If so, how can a node differentiate between recent and old TLV in "MP-TLV" bundle (i.e., are these TLV parts of a unique bundle or separates ones) ? `Breaking of a single sub-TLV or other data unit across TLVs MUST NOT be done` what is the expected behavior when receiving such a TLV ? ### Section 5 Does the basis IS-IS specification cover the case when several TLV having the same Type have conflicting values ? Should there be text about this corner case ? ### Section 6 Be more assertive and use "MUST" in `Therefore any new codepoints defined by future protocol extensions will explicitly indicate the applicability of MP-TLV procedures to the new codepoints` ### Section 7 I find this section under-specified , e.g., isn't the following wishful thinking `It is presumed that if such support is provided that it applies to all relevant codepoints`? Why not a "MUST" in `SHOULD include this sub-TLV in a Router Capability TLV` ? ### Section 8 s/presence of routers *which* do not correctly/presence of routers *that* do not correctly/ Please explain the consequences (or when it can be bypassed) of the 2 "SHOULD". ### Section 9.1 Suggest adding informative references to the IANA registries URIs. ### Section 9.2 Should there be guidance for the designated experts ? ## NITS (non-blocking / cosmetic) ### Section 1 `PDU` acronym is never used, so do not introduce it ;)