Bruno – Seems like we are converging. Some additional responses inline – look for LES2:
From: [email protected] <[email protected]> Sent: Friday, August 9, 2024 7:40 AM To: Les Ginsberg (ginsberg) <[email protected]> Cc: Yingzhen Qu <[email protected]>; lsr <[email protected]>; lsr-chairs <[email protected]> Subject: RE: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024) Les, From: Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>> Sent: Friday, August 9, 2024 6:11 AM Bruno – Thanx for the detailed comments. Thanks for taking the time to respond in detail. 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. +1. 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. No problem, thanks Les. On my side, I’ll be away till August 26 [LES2:] Now I am jealous. 😊 Please see inline. From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Sent: Wednesday, August 7, 2024 6:03 AM To: Yingzhen Qu <[email protected]<mailto:[email protected]>>; lsr <[email protected]<mailto:[email protected]>>; lsr-chairs <[email protected]<mailto:[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). [Bruno] OK. The principle of the MP-TLV extension is clear. My concern is that the sender be more subtle than the receiver and hence the receiver gets surprised/lost. 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. [Bruno] OK, thanks. 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) [Bruno] Thanks for the example. Really useful. I’m fine so far, especially because A and B are different nodes so they may advertise/be configured with different things. 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) [Bruno] What about the following example advertised by A TLV #1: (B system-id, IPv6 Interface Address, Local/Remote Link IDs) TLV #2: (B system-id, IPv6 Interface Address) With B not supporting RFC 6119 (IPv6 Interface Address) [LES2:] For a given topology, it is required that in order for an adjacency to be formed, the set of supported address-families MUST match. I cannot have A supporting IPV4 and IPv6 in MTID #0 – but B supporting only IPv4 – because A will want to use the link to forward IPv4 and IPv6 traffic – which B does not support. So this case cannot arise – at least not legally. These topological restrictions come from RFC1195 and RFC 5120. Possibly this is obvious to everyone but me, but I’m a priori not confident that the sender may be as creative as it want, and expect the receiver to always figure out correctly. Receivers can still correctly identify the two TLVs as being associated with the same adjacency to B. I agree that there are multiple cases where the receiver could correctly identify the two TLVs. My concern is that some receivers may not, even if they could. E.g. the one implementing the receiver feels like this is an optional case and no bother implementing this case. [LES2:] This problem is not introduced by multi-tlv – so my statement directly below applies. 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. [Bruno] Thanks. 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. [Bruno] To me multi-tlv introduces the possibility to advertise two TLV with the same key. Because of a bug, those two TLV may sent with different information in its fixed part. So it would be up to this document to handle that case. Sorry if I’m missing something [LES2:] Even in a single TLV, the sender could send duplicate information (remember that IS-IS allows multiple prefix advertisements (for example) to be included in a single TLV). 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. ?? [Bruno] I think that this would be helpful. At least for me. Thanks for the suggestion. But the deterministic behavior would need to be specified (,no?) [LES2:] Yes – part of the new text would be to specify the behavior. 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. [Bruno] Let me rephrase. OLD: If local LSP generation requires the use of MP-TLVs when generation of MP-TLVs is disabled NEW: If local LSP generation requires the use of MP-TLVs when generation of MP-TLVs is disabled on this node or not supported on other nodes in the flooding domain (as advertised by the MP-TLV Capability Advertisement). [LES2:] OK – I understand your point now. We can add this text. Thanx for clarifying. I understand that this is extra work so I’m not insisting. But if you believe that this is not a significant extra work, I think it may help the operator during initial deployment. 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. [Bruno] Let’s suppose that new configuration is added requiring more than 255 bytes. I’m making a distinction between: 1. Node does _not_ send MP-TLV hence some configuration is not advertised in IS-IS (whether the CLI is shown as “active” or “inactive” doesn’t seem to change anything for IS-IS). Agreed the node and the network will not behave as expected, but all nodes have a consistent view of the LSDB 2. No sends MP-TLV while some other nodes do not support MP-TLV. --> different nodes have a different view of the LSDB. I feel that “b” is a bigger issue. [LES2:] I won’t quibble about which issue is “bigger”. They both are problematic. Will work on text to address this point. 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. [Bruno] ok, no problem. 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). [Bruno] I wish there would be more eyes / reviewers. It’s also why I believed that adding, in this doc, the key for each TLV would allow more eyes to check that we all agree on the key definition. But I got the pusback 😉. I’m not trying to insist, but explain my initial motivation. 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. [Bruno] Thank you. 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. [Bruno] +1. Especially when some implementations may only support one 😉. 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? [Bruno] Absolutely. #1 seems easier but totally up to you. Personally a 3rd option would also work for me “3) Maks this codepoint a non MP-TLV applicable”. Because I think that MP-TLV is introduced by this document and hence could make that choice. But I feel that your preference would be to make MP-TLV applicable to all TLVs by default whenever it’s possible. [LES2:] I believe the 3rd option (as you refer to it) is preferable, but it really amounts to updating RFC 5130 – which I am a bit loathe to do in this document. I will discuss with co-authors and see what we want to do. Les Thank you --Bruno 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. ____________________________________________________________________________________________________________ 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]
