Bruno – Thanx for the detailed comments.
Note that we have not yet fully determined what text changes should be made to the draft – but hopefully this discussion will help us move forward. I appreciate that this discussion is time consuming – but hopefully worth it for all of us. BTW, I will be away for a few days the first part of next week (returning on Thursday August 15) – so responses may be delayed. Please see inline. From: [email protected] <[email protected]> Sent: Wednesday, August 7, 2024 6:03 AM To: Yingzhen Qu <[email protected]>; lsr <[email protected]>; lsr-chairs <[email protected]> Subject: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024) 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.” [LES:] In order for MP-TLV to be applicable to a codepoint, there has to be the potential for more than 255 bytes of information to be advertised. (obvious 😊) And if multiple TLVs are sent, there has to be a way to identify them as being associated with the same object (which is what the “key” does). This is consistent with the statement “TLV not having a key can’t be a MP-TLV.”. But there are some subtleties. To use your example of the admin tag sub-TLVs, I agree that it is conceivable (though unlikely) that one could need to advertise more than 255 bytes of tags, yet the tag sub-TLVs themselves do not have a “key”. Functionally however, as they are associated with a single prefix, they inherit the key from the parent codepoint. (More comments on admin tag below). In summary, I think we can do a better job of wording in this section – we will work on that. But the existing text is correct in spirit. 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 [LES:] We will make this change. “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. [LES:] We mean exactly what we say - "at least one". It is not necessary to advertise all of the link identifiers in each TLV in order to correctly identify the two TLVs as having the same key. There is a good deal that could be said here - but it is not the province of this document to do so. The issue you raise is applicable to a single TLV as well. For example, A-B have an adjacency and advertise an IS-Neighbor TLV, the following works for the purposes of doing TWCC: A advertises: (B system-id, IPv4 endpoint addresses, Local/Remote Link IDs) B advertises: ( A system-id, Local/Remote IDs) If it takes two TLVs for A to advertise all of the link attribute information associated with the adjacency to B, A could advertise: TLV #1: (B system-id, IPv4 endpoint addresses, Local/Remote Link IDs) TLV #2: (B system-id, Local/Remote Link IDs) Receivers can still correctly identify the two TLVs as being associated with the same adjacency to B. You may wish this was written down in some document - but multi-tlv draft is not the right place to do this. If needed, some update to RFC 5305 (et al) could be done. That is a decision for the WG to make. 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 [LES:] We will make this change. 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. [LES:] In such scenarios there is no way to know which value is "correct". Historically there have been two approaches: 1)Implementations make a local decision as to which of the values they use and/or whether to ignore both. 2)Define a deterministic behavior e.g., use the first occurrence in the lowest numbered LSP. In cases where behavior is specified, some RFCs have chosen #1 and some have chosen #2. But multi-tlv does not introduce this problem and therefore it is out of scope for this document to define the behavior. Not least because we would have to be concerned with contradicting existing specifications no matter which choice was made. If you feel this is important enough to address, then the codepoint specific documents need to be updated. It is possible that we could say something like: “If the relevant RFC which defines a codepoint is not explicit as to how to handle such situations, Option #2 SHOULD be followed.” This would establish a recommended default behavior while allowing specific codepoints to override this behavior. If you think this is helpful we can add such text. ?? 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. [LES:] I am having trouble parsing this. If the receiver receives only one TLV for a given object, there is no way for the receiver to know whether the sender had additional information to send but suppressed it or if the sender simply didn't have any additional information. What we are recommending here is that implementations inform the operator that MP-TLVs are being sent by some nodes even though the operator has disabled it on the local node. If the operator has disabled the use of MP-TLVs on a node, it is presumed that the operator had a reason to do so i.e., the operator knows that at least some nodes in the network do not support reception of MP-TLVs and so they should not be sent by any node. The only way the operator can avoid partial deployment issues is to ensure that the configuration of any node does not require the sending of MP-TLVs. Disabling the sending of MP-TLVs in the presence of configuration which requires more than 255 bytes to be sent for an object means that not all required info can be sent - and what will be excluded is unpredictable - so the network will be compromised. We could add some text to this effect in Section 7 if you think it would be helpful. 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) [LES:] The point of adding the MP-TLV applicability column to registries means that going forward, every new codepoint will be required to explicitly indicate whether MP-TLV applies. This will be enforced by the WG and IANA. So, it should not be possible for documents that become RFCs after this draft becomes an RFC to be "unclear". Existing RFCs may never get updated, but hopefully we have covered those cases in Section 8.2. So I do not share your concern. 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? [LES:] I agree – this is misidentified. We will correct that. 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. [LES:] Disturbs me too. We tried hard to be accurate and complete, but…obviously we still need good review (like yours). 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? [LES:] :] Conceptually I agree. RFC 5130 does not prohibit multiple sub-TLVs - though it also does not explicitly allow them. One could argue that 50+ 32 bit tags can be advertised in a single sub-TLV – which ought to be more than enough for any deployment. But strictly speaking RFC 5130 does not prohibit this – so it could be considered as possible. There are then two choices: 1)Mark this codepoint as MP-TLV applicable 2)Update RFC 5130 to prohibit multiple sub-TLVs/prefix #1 can be done in this draft #2 should be done as either an errata or bis to RFC 5130. Make sense to you? On a side note, thank you for the addition of §6 which definitely simplifies and helps interop. [LES:] Thanx. Les Thanks, Regards, --Bruno From: Yingzhen Qu <[email protected]<mailto:[email protected]>> Sent: Tuesday, July 2, 2024 8:08 AM To: lsr <[email protected]<mailto:[email protected]>>; lsr-chairs <[email protected]<mailto:[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]
