Hi, Adrian:
Image you have one network that comprised by 100 nodes(small network), and there are 5 TLVs(small portion of the number that list in section 8.2 of this document) that needs to be MP-TLV implemented and deployed. You need to do the “Local Configuration” on these 100 nodes, to enable the MP-TLV compatibilities for every of these 5 TLVs. And, every time one new MP-TLV is introduced, such tedious “enable” work need to be done again…… I think there will be no operator to accept such solution. And, for your question about “there were two instance of TLV abc, how would you distinguish them?”, I think we should only focus the example(TLV 22) that given in the section 4.1 of this document(https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-06#section-4.1): If there are two instance of TLV 22, we can distinguish them only from the fields of this TLV(System ID, Optional sub-TLVs, for example, IPv4 interface address, IPv6 interface address or Link Identifiers etc.). But, RFC5305 that defines TLV 22 doesn’t require any optional sub-TLV be present( “Thus, if no sub-TLVs are used, the new encoding requires 11 octets and can contain up to 23 neighbors.), then from the context for this TLV, you can’t derive the “key” information for specific link to the same neighbor. The “key” information for specific link is only described in the MP-TLV document itself. That’s the reason that Mach and Robert suggest also to build some wiki page to list the “key” information for each MP-TLV code point. But, I think build such “wiki page” is challengeable. We should think other method to solve such problem. Best Regards Aijun Wang China Telecom 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Adrian Farrel 发送时间: 2024年11月13日 20:58 收件人: 'Aijun Wang' <wangai...@tsinghua.org.cn> 抄送: lsr@ietf.org; draft-ietf-lsr-multi-...@ietf.org 主题: [Lsr] Re: Debate on draft-ietf-lsr-multi-tlv Our understanding of the current text differs. > 1) If the operator want to assure their network behave correctly, all the > NODEs > within the network MUST all support the MP-TLV capabilities, that is, every > node can concatenate the segments MP-TLV pieces together, via some undefined > “key”. > That is to say, Support MP-TLV is NOT optional. > > 2) Support for MP-TLV is NOT configured for per-TLV. You can confirm it via > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-06#section-8.1 Taking these two points together. It is clearly important to an operator to know that the deployed implementations will interoperate. ISIS works today without using MP-TLV, so to some extent “everything is good.” 7.1 suggests that implementations should allow you to turn off MP-TLV, so you can always return to the no MP-TLV base situation. 7.1 further says that the configuration should be per-TLV, so that you can reach a common set of support MP-TLV across your deployed implementations. 8.1 requests a code point to announce whether an implementation supports MP-TLV. The use of this code point is described in 7.2. 7.2 clearly explains that the advertisement of support for MP-TLV is informational only and must not be used to control behaviour (the control for behaviour is the local configuration). Personally, if I found my peer did not support MP-TLV and I was configured to support it, I would log a bit message. Also conversely. > 3) If the document doesn’t aim to solve all the possible MP-TLV code point, > then > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-06#section-8.2 > should be > removed. And also the statement in its Abstract part: “ This document > codifies the common mechanism > of extending the TLV content space through multiple TLVs”. I think you are questioning whether the mechanism defined in this document is applicable to every ISIS TLV that has been defined. I believe it is. The question (judging from your previous emails) is about the value of the key, because it is a requirement that the key value be present in all instances of the MP-TLV. Let’s pick a random TLV with type code abc. - If that has no key, then there is nothing special to do. You just have multiple MP-TLVs with type code abc. - If that TLV does have a key then you are asking “What is it? How do I find it out?” because you need to place it in each MP-TLV instance. In this second case, my view is that the definition of “key” needs a little work, but that it is meant to mean “the information fields within TLV abc that give specific context to the TLV.” In other words, if, under normal circumstances, there were two instance of TLV abc, how would you distinguish them? I believe that information is *always* included in the documentation of any TLV. You can work it out as follows: - If multiple instances of the TLV are not allowed, there is no key. - If multiple instances of the TLV are allowed, there is a description of how you derive the context for the TLV (and that is the definition of the key). > As I said before, it solves partly two IS-IS TLV code points (TLV 22 and TLV > 135, as mentioned as examples). > > Anyway, if you follow the discussions more throughly, you may find more > problems > existing within the document, as also mentioned in your detail review > comments. Thanks, I think my following of the discussions may be throughly enough. Cheers, Adrian On Nov 13, 2024, at 16:59, Adrian Farrel <adr...@olddog.co.uk <mailto:adr...@olddog.co.uk> > wrote: Hi Aijun, I realised after I sent the email that the word “field” was open to misinterpretation. But, too late! The email was already sent. I meant, “in particular, clarifying what has already been implemented and deployed, and ensuring that others can interoperate safely.” If you read my review carefully you will see that I have raised some concerns about the way the text describes how MP-TLVs can be built (where are the boundaries to partition). I also have an issue about the use of the word “key” without a more formal definition. But I do not have concerns about the definition of a key for each TLV. The key is, I believe, those fields within a TLV that are necessary to determine the scope of applicability of the TLV. For many TLVs there are no such fields because the YLV applies to the advertising node, and that is all. For other TLVs, the fields that define the scope of applicability are “obvious” from the document that defines the TLV. Could that be made clearer by a wiki that lists the fields that comprise the key in each case? Yes. Is that necessary for this document to work? I don’t think so. My reasoning is that: 1. Support for MP-TLV is optional 2. Support for MP-TLV is configured per-TLV 3. It is likely that most TLVs will not reach the 255 byte limit For what it is worth, it has been a very long time since I touched ISIS code, but I believe I could figure out how to make an interoperable implementation after the resolution of my review questions. Cheers, Adrian From: Aijun Wang <wangai...@tsinghua.org.cn <mailto:wangai...@tsinghua.org.cn> > Sent: 13 November 2024 02:07 To: adr...@olddog.co.uk <mailto:adr...@olddog.co.uk> ; lsr@ietf.org <mailto:lsr@ietf.org> Cc: draft-ietf-lsr-multi-...@ietf.org <mailto:draft-ietf-lsr-multi-...@ietf.org> Subject: 答复: [Lsr] Debate on draft-ietf-lsr-multi-tlv Hi, Adrian: I admire your efforts to try to improve the readiness of this document. But, SURPRINGLY, you get the wrong conclusion-----“in particular clarifying what is in the field and ensuring that others can interoperate safely.” We are discussing where is the “field(what constitute a key)” to “ensuing that others can interoperate safely”. Would you like to follow/chime in the discussions on another thread (https://mailarchive.ietf.org/arch/msg/lsr/eDZWKm-bcG1t7WKYYmwqMvlNAoY/), and to review again and make a new judgment/conclusion of this document? Best Regards Aijun Wang China Telecom 发件人: forwardingalgori...@ietf.org <mailto:forwardingalgori...@ietf.org> [mailto:forwardingalgori...@ietf.org] 代表 Adrian Farrel 发送时间: 2024年11月13日 5:22 收件人: lsr@ietf.org <mailto:lsr@ietf.org> 抄送: draft-ietf-lsr-multi-...@ietf.org <mailto:draft-ietf-lsr-multi-...@ietf.org> 主题: [Lsr] Debate on draft-ietf-lsr-multi-tlv Hi, Well, this whole discussion sent me off to read the draft. I have some suggestions to clarify the text that might help with the current discussion, and also some nits that were thrown up by reading the draft. I don't know where this fits into the last call sequence, but I hope my comments are useful to improve the document – feel free to tell me I have misunderstood. I should add, I support the publication of this document for many of the reasons stated: in particular clarifying what is in the field and ensuring that others can interoperate safely. Cheers, Adrian = Clarification points = Section 3 has: A TLV is a tuple of (Type, Length, Value) and can be advertised in IS-IS packets. 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). This seems to be the crunch paragraph that could set the scene for the rest of the document, and could help new readers understand the scope. This is clear except for: 1. "key" is a term which I understand, and which I would also have used, but I wondered whether anything is actually called a key in the current IS-IS literature. So I did a search and didn’t find anything – it’s possible my search wasn’t broad enough. But, if you have a citation for the assertion, then please include it and some of the angst will go away. OTOH, if this is a term being defined here, we might strengthen the definition and scope. 2. "sometimes contains" means that sometimes a key is not included in which case, presumably, the mechanisms in this document can still be applied. So maybe… A TLV is a tuple of (Type, Length, Value) and can be advertised in IS-IS packets. The applicability of the TLV is indicated by the Type field, and for the case of some specific Type codes, may be further qualified by specific information in the Value that, in this document, are collectively called the key. If a router advertises multiple TLV tuples in an IS-IS IIH packet or in the set of LSPs for a level, and they have the same Type code, they are considered a multi-part TLV (MP-TLV) if any key defined for the specific TLV Type also matches in the TLVs --- In Section 4 Network operators should not enable Multi-part TLVs until ensuring that all implementations that will receive the Multi-part TLVs are capable of interpreting them correctly. 3. Why is that not “SHOULD NOT”? 4. But also, why is that not “MUST NOT”? --- The example in 4.1 is ambiguous. You have previously stated (section 4) that the key information MUST be replicated in additional TLV instances This example defines: The key consists of the 7 octets of system ID and pseudonode number plus the set of link identifiers which are present. But then: The following key information MUST be replicated in each of the additional Extended IS Reachability TLVs: * 7 octets of system ID and pseudonode number * The set of link identifiers SHOULD be identical in all TLVs which are part of the MP-TLV set. How is that “SHOULD” consistent with the two cases of “MUST”? I should have thought this should read… The following key information MUST be replicated in each of the additional Extended IS Reachability TLVs: * 7 octets of system ID and pseudonode number * The set of link identifiers Except, this is an example, not normative text so the whole should read… The following key information is replicated in each of the additional Extended IS Reachability TLVs: * 7 octets of system ID and pseudonode number * The set of link identifiers . --- Similarly in 4.2, the use of BCP14 language is not appropriate. So… OLD The key information MUST be replicated identically. NEW The key information is replicated identically. END --- Somethings we learn in section 5 about how a sender constructs MP-TLVs are: 5. The series of TLVs with the same T and K values may be sent in any order 6. The contents of a Value that is being split across MP-TLVs cannot be arbitrarily split. Any split must be at a sub-TLV boundary (and no lower, i.e., not at a sub-sub-TLV boundary, and certainly not just “some bytes in one MP-TLV and some bytes in another). This is because the receiver “concatenates” the contents of the received Values in any order and it wouldn’t be clear to which sub-TLV the sub-sub-TLV belonged (and, of course, you could just garble the order of bytes). These points really need to be brought out in section 4 because they instruct the sender. --- Section 5 contains: If the internals of the TLV do NOT include key information, the relevant key can be found in the parent TLV. I am struggling to parse this. I think it is probably simply not adding anything (except confusion). Suppose I have: TLV{key, info, sub-TLV1, sub-TLV2} Here, TLV is the parent and sub-TLV1 and sub-TLV2 are the children But it is too long. So I send: MP-TLV1{key, info, sub-TLV1} MP-TLV2{key, sub-TLV2} Key all sorted. So, I’m trying to find a case where MP-TLV would not include the key and I would have to go to the parent (especially since the text in section 4 says I must put the key in). Probably, all that this says is, if you need to know the key and the key is not in the sub-TLV, look in the parent. That is, of course, true. But it is nothing to do with MP-TLV: just a bit of ISIS know-how. --- I think there is some confusion in Section 6 with: Multi-part procedures may also be applicable to codepoints which do not support sub-TLVs, but which define an unbounded number of attributes which may be advertised in a single codepoint. An example of the latter is GMPLS-SRLG as defined in [RFC5307]. There is some confusion over the wording here because 5307 *does* use sub-TLVs, even if the SRLG sub-TLV has an unbounded number of attributes (controlled by the length field). How about… Multi-part procedures may also be applicable both to TLV codepoints which do not support sub-TLVs and to those which define an unbounded number of attributes which may be advertised within a single sub-TLV. An example of the latter is GMPLS-SRLG as defined in [RFC5307]. However, my concern (expressed in a comment on section 5) is that you can’t make MP-TLVs arbitrarily because of the rule that says you can re-assemble in any order. = Nits = Section 1 has: Today, for example, the Extended IS Reachability TLV (22) [RFC5305] and MT Intermediate Systems TLV (222) [RFC5120] are TLVs where existing standards do not specify sending multiple TLVs for the same object and no other mechanism for expanding the information carrying capacity of the TLV has been specified. Consider that you hope to publish this as an RFC that will persist. You need text that will survive the test of time, and also will not contradict the document itself. How about... For example, [RFC5305] defines the Extended IS Reachability TLV (22) and [RFC5120] defines the MT Intermediate Systems TLV (222). Those documents do not specify sending multiple TLVs for the same object. --- Section 1 has: [RFC7356] has proposed a 16 bit length field for TLVs in flooding scoped Protocol Data Units (PDUs), but this does not address how to expand the information advertised when using the existing 8-bit length TLVs. RFC 7356 is a standards track document, so it didn't "propose", it "defined". How about... [RFC7356] defined a 16 bit length field for TLVs in flooding scoped Protocol Data Units (PDUs), but does not address how to advertise more information when using the existing 8-bit length TLVs. --- Section 1 has: The mechanism described in this document has not been documented for all TLVs previously, so it is likely that some implementations would not interoperate correctly if these mechanisms were used without caution. This is foundational motivation for the document, so maybe it could be made a little clearer? How about... The mechanism described in this document has been implemented, but without formal documentation, there is a risk that these and new implementations would not interoperate correctly. This document provides the necessary protocol definition. --- Finally in Section 1: The mechanism described in this document has been used explicitly by some implementations, so this document is not creating an unprecedented mechanism. It is specifying a means for extending TLVs where no extension mechanism has been previously specified, and defining a default extension mechanism for future TLVs, if they choose not to specify another extension mechanism. The mechanism described in this document is applicable to top level TLVs as well as any level of sub-TLVs which may appear within a top level TLV. This feels like an over-sell to me. Having already had the previous paragraph, you could safely slim this down to: This document specifies a means for extending TLVs where no extension mechanism has been previously specified, and defines a default extension mechanism for future TLVs. The mechanism described in this document is applicable to top level TLVs as well as any level of sub-TLVs that may appear within a top level TLV. --- Section 5 has a couple of instances of “NOT”. It is general good practice to only use upper case in the BCP14 phrases. _______________________________________________ Lsr mailing list -- lsr@ietf.org <mailto:lsr@ietf.org> To unsubscribe send an email to lsr-le...@ietf.org <mailto:lsr-le...@ietf.org>
_______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
