Hi authors, Please see below some possible comments on the draft.
1. §3 says “TLVs sometimes contain information, called a key, that indicates the applicability of the remaining contents of the TLV. If a router advertises multiple TLV tuples with the same Type code in an IS-IS IIH packet or in the set of LSPs for a level with the same key value, they are considered a multi-part TLV (MP-TLV).” I’m reading this as: TLV not having a key can’t be a MP-TLV. If this is not the intention please clarify. (e.g. same key value if that TLV has a key) If this is the intention, this seems to contradict with other text such as §4 “If a Multi-part TLV contains information that specifies the applicability of its contents (i.e., a key), the key information MUST be replicated” §6 “However, Multi-Part TLV procedures are potentially applicable to any codepoint that allows sub-TLVs to be included as part of the information advertised.” 2) §4.1 (TLV 22) “The key consists of the 7 octets of system ID and pseudonode number plus the link identifiers.” OK. May be for extra clarify :s/the link identifiers/all links identifiers which are present “The following key information MUST be replicated in each of the additional Extended IS Reachability TLVs: 7 octets of system ID and pseudonode number At least one of the following identifiers” It’s not clear to me whether you mean “all link identifiers” advertised in the first part (which would seem to match your above definition of the key) or “any (number) of links identifiers”. That’s the typical example where the lack of a formal definition of the key for a (all) TLVs may brings interop issue. One implementer could believe that all link identifiers are needed in all parts, while another could believe that a subset is enough in some cases. 3) §5 Procedure for Receiving Multi-part TLVs “If the internals of the TLV contain key information, then replication of the key information should be taken to indicate that subsequent data MUST be processed as if the subsequent data were concatenated after a single copy of the key information.” May be :s/should/MUST 4) §5 Procedure for Receiving Multi-part TLVs “A TLV may contain information in its fixed part that is not part of the key. […] Having inconsistent information in different parts of a MP-TLV is an error and is out of scope for this document.” I know that we have divergence on this aspect, but to me error handling is part of the specification. At least so that all receivers make a consistent choice. A typical simple behavior could be to discard the whole MP-TLV (all parts). Alternatively the error handling defined in https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-12#sec_isis_gen_metric “advertisement in the lowest numbered fragment MUST be used and the subsequent instances MUST be ignored.” Also I would welcome a more normative text. e.g. :s/is an error/ MUST be treated as an error. 5) §7.1 Recommended Controls and Alarms Ideally I would like the addition of the below case: “* An MP-TLV Capability Advertisement is not received from a node when use of MP-TLVs is enabled.” Because you can’t expect existing node to comply with “If an MP-TLV is received when use of MP-TLVs is disabled” hence this is not enough to detect the partial deployment issue. 6) §7.2 MP-TLV Capability Advertisement “Nodes which support MP-TLV for codepoints for which existing specifications do not explicitly define such support, but for which MP-TLV is applicable, SHOULD include this sub-TLV in a Router Capability TLV.” Looks good, thank you. Yet “existing specifications” may be unclear in 5 years from now. May be you could refer to the section 8.2 which specifically list those codepoints. (since you did the effort of writing §8.2, you could reference it) 7) 8.2.3. MP-TLV for IS-IS Sub-TLVs for TLVs Advertising Neighbor Information Checking one random value. 17 Generic Metric Y Does this match the sub-TLV defined in https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flex-algo-bw-con-12#sec_isis_gen_metric? If so, * This seems to contradict the spec “For a particular metric type, the Generic Metric sub-TLV MUST be advertised only once for a link when advertised in TLV 22, 222, 23, 223 and 141.”, “If there are multiple Generic Metric sub-TLVs advertised for a link for the same metric type (and same application in case of ASLA) in one or more received LSPDUs, advertisement in the lowest numbered fragment MUST be used and the subsequent instances MUST be ignored.” * Also it’s length is hardcoded to 4 octets. Why would one need to use MP-TLV? IINM, although I agree that sampling 1 TLV out of many is poor sampling, it’s a bit disturbing to find an error out of one TLV. At minimum it seems to indicate a lack of review from the WG. Picking another value 1 32-bit Administrative Tag Sub-TLV N Why a “No”? This sub TLV includes a set of tags and if the number of tags is large enough, it seems like a good candidate for MP-TLV, no? On a side note, thank you for the addition of §6 which definitely simplifies and helps interop. Thanks, Regards, --Bruno From: Yingzhen Qu <[email protected]> Sent: Tuesday, July 2, 2024 8:08 AM To: lsr <[email protected]>; lsr-chairs <[email protected]> Subject: [Lsr] WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024) CAUTION : This email originated outside the company. Do not click on any links or open attachments unless you are expecting them from the sender. ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur. Hi, This email begins a 2 week WG Last Call for the following draft: draft-ietf-lsr-multi-tlv-01 - Multi-part TLVs in IS-IS<https://datatracker.ietf.org/doc/draft-ietf-lsr-multi-tlv/> Please review the document and indicate your support or objections by July 15th, 2024. Authors, Please indicate to the list, your knowledge of any IPR related to this work. Thanks, Yingzhen ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
