Mohamed Boucadair has entered the following ballot position for draft-ietf-lsr-multi-tlv-11: Yes
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-multi-tlv/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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 _______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
