Hi, Les：
1) In the abstract of this document, it states: “This document codifies the common mechanism of extending the TLV content space through multiple TLVs.”， then, Where is codifies? What is the common mechanism? 2) In section 3, “”Multi-part TLVs”, this document has the following statements: 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) Then, the key for each TLV is important to concatenate the MP-TLV, and where is key field definition of each MP-TLV? If there is no such key field definition, how do you assure the interoperability from different vendor?(the previous question you avoid to answer) For example, one vendor cut the longer TLV into several parts, use the key fields that defined by itself, but the receiver think they are lack of some information to concatenate due to lack of some information for key fields that it assumes, the receive can only discard these MP-TLVs, even they all disclaims that they support MP-TLV capabilities. 3) The PIC Yang files that you recommend is for the management purpose, not for the interoperability purpose. Will you define many RFCs for each key field definition of the MP-TLV later? In summarize, there is no obvious points that can support to forward this document that can lead to more chaos in network than not deploying it at all. Best Regards Aijun Wang China Telecom 发件人: Les Ginsberg (ginsberg) [mailto:[email protected]] 发送时间: 2024年7月4日 15:03 收件人: Aijun Wang <[email protected]>; 'Ketan Talaulikar' <[email protected]>; 'Yingzhen Qu' <[email protected]> 抄送: 'lsr' <[email protected]>; 'lsr-chairs' <[email protected]> 主题: RE: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024) Aijun – Please see inline. From: Aijun Wang <[email protected] <mailto:[email protected]> > Sent: Wednesday, July 3, 2024 7:55 PM To: Les Ginsberg (ginsberg) <[email protected] <mailto:[email protected]> >; 'Ketan Talaulikar' <[email protected] <mailto:[email protected]> >; 'Yingzhen Qu' <[email protected] <mailto:[email protected]> > Cc: '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, Les: 1) If the document doesn’t specify the key field part of each possible multi-part TLV and multi-part sub-TLV, how can you avoid the interoperability problem in the deployment? What’s the value then to let the vendors to comply with this specification? [LES:] The value of the document is that it standardizes MP-TLV as the mechanism to be used in cases where more than 255 bytes of information about a given object needs to be advertised. This applies to codepoints which are currently defined as well as any new codepoints defined in the future. There is no longer any reason to consider alternative mechanisms and the use of other mechanisms would be in violation of this RFC-to-be. 2) Even for the “MP-TLV Capability Advertisement” in your document, as described within it: The sub-TLV intentionally does not provide a syntax to specify MP-TLV support on a per-codepoint basis. It is presumed that if such support is provided that it applies to all relevant codepoints. It is understood that in reality, a given implementation might limit MP-TLV support to particular codepoints based on the needs of the deployment scenarios in which it is used.¶ <https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-01#section-7.2-7> Are the above statements are contradict themselves: It declares that it applies to all, but in reality it is not. What’s the usage of above false positive announcement then? [LES:] Section 7.2 needs to be read in its entirety to appreciate the goals and limitations. It is clearly stated that the new sub-TLV is only providing an informational indication to the operator. Complete definition of what is supported by an implementation is not a function of the routing protocol itself. Rather it is the role of conformance documents. Note that the means to provide a complete definition of what a given implementation supports has been started. See: https://datatracker.ietf.org/doc/draft-qgp-lsr-isis-pics-srmpls-yang/ https://datatracker.ietf.org/doc/draft-qgp-lsr-isis-pics-yang/ We welcome input on these drafts – which are still in early stages. 3) Even for your onerous descriptions in your IANA considerations, there is also error, for example, for the IPv6 SRLG(code point 139), which is specified not applied for the MP-TLV, but the associated RFC 6119, states clearly that “The IPv6 SRLG TLV MAY occur more than once within the IS-IS logical LSP“, even in the description of “introduction” part of your document. [LES:] There is an error – but it is not what you have pointed out. There are three SRLG related codepoints and three different RFCs that are relevant: RFC 5307 which defines the IPv4 SRLG TLV(138). This specification does not state whether multiple TLVs for the same link are allowed. RFC 6119 which defines the IPv6 SRLG TLV(139). This specification explicitly states in Section 4.4: “There MUST NOT be more than one IPv6 SRLG TLV for a given link.” RFC 9479 which defines the ASLA SRLG TLV(238). This specification explicitly states in Section 4.3: “Multiple TLVs for the same link MAY be advertised.” The error in this draft is not in the IANA section (as you suggested) but rather that we state in the Introduction that the IPv6 SRLG TLV (139) explicitly specifies the use of multiple TLVs when in fact RFC 6119 states the opposite. Thanx for calling our attention to this issue – we will correct the statement in the Introduction. As for resolving the inconsistency among the three RFCs mentioned above, that should be done – but it is outside the scope of this draft. Les >From the above all, we can see that this document is far from to solve the >mentioned question, will only lead to more chaos within the network. We should not forward this document at the current stage. More works should be done to solve the issue. Best Regards Aijun Wang China Telecom 发件人: [email protected] <mailto:[email protected]> [mailto:[email protected]] 代表 Les Ginsberg (ginsberg) 发送时间: 2024年7月4日 2:53 收件人: Ketan Talaulikar <[email protected] <mailto:[email protected]> >; Yingzhen Qu <[email protected] <mailto:[email protected]> > 抄送: lsr <[email protected] <mailto:[email protected]> >; lsr-chairs <[email protected] <mailto:[email protected]> > 主题: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024) Ketan – Thanx for the support. Responses inline. From: Ketan Talaulikar <[email protected] <mailto:[email protected]> > Sent: Wednesday, July 3, 2024 9:56 AM To: Yingzhen Qu <[email protected] <mailto:[email protected]> > Cc: 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 All, I thank the authors for the work on this draft and support its publication. This work was very much needed for the enablement of new feature sets in ISIS networks and the specification will aid interoperability. My only "grudge" is something that I have brought up previously on this draft [1] and perhaps there may still be some interest in the WG/authors to take care of them? 1) Mandate that the non-key part is identical in all the parts and if not recommend that the value in the first part is taken. Or, say something about handling this condition than saying "error and out of scope". [LES:] The authors discussed this aspect. What we decided was that the scope of this draft was to clearly define the generic aspects of multi-tlv – not to discuss the peculiarities of any specific codepoint. With that in mind, Section 4 – and specifically the examples provided – is meant only to illustrate what a “key” is. There is considerably more that could be said about each specific codepoint – but we believe that is out of scope for this document. 2) Since the early versions of the draft, a lot of effort has been put on cataloguing TLV/sub-TLVs and their applicability for MP. From there, it is only one more step to actually specify the "key" and "non-key" parts of TLVs (where this is not done already) in an appendix section. This is important for interoperability. The draft today covers two of the most prominent TLVs but does not cover the others. [LES:] Again, the intent of this document is to clearly describe the generic Multi-TLV mechanism – not to discuss the specifics of each codepoint. To do so would expand the scope of the document beyond any reasonable boundaries. For example, in the case of Neighbor TLVs (such as TLV 22), there are a wide variety of implementation strategies. Some implementations send only LinkIDs all the time. Some implementations send endpoint addresses (when available) and not Link IDs. Some implementations send endpoint addresses and Link IDs. All of these options are valid – but may impact interoperability depending on the “generosity” of the receivers. And some commonality is required – independent of Multi-TLV – in order for two-way connectivity check to work correctly. It is not in the scope of this document to include such a discussion – and the use of Multi-TLV does not introduce new issues in this regard. This is why we restricted ourselves to only discussing “what a key is” in the examples. The discussion – even for the two examples - is not exhaustive and is not meant to be. If there is a significant interoperability issue with a particular codepoint, some other document will have to be written/updated to address that. Les That said, I won't hold this document if I am in the rough on this. Thanks, Ketan [1] https://mailarchive.ietf.org/arch/msg/lsr/qQkeAHnw2qjrGoySbES4EVafgY4/ On Tue, Jul 2, 2024 at 11:39 AM Yingzhen Qu <[email protected] <mailto:[email protected]> > wrote: 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 _______________________________________________ Lsr mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]>
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
