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? 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? 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. >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]] 代表 Les Ginsberg (ginsberg) 发送时间: 2024年7月4日 2:53 收件人: Ketan Talaulikar <[email protected]>; Yingzhen Qu <[email protected]> 抄送: lsr <[email protected]>; lsr-chairs <[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]
