Bruno – Thanx for the response – and especially for your detailed comments on the draft (which you sent in a separate email). It will take some time for authors to reach consensus on what if any changes to the draft should be made – please be patient while the authors discuss that.
In the meantime, some responses to this email inline. From: [email protected] <[email protected]> Sent: Wednesday, August 7, 2024 6:02 AM To: Les Ginsberg (ginsberg) <[email protected]>; Ketan Talaulikar <[email protected]>; Yingzhen Qu <[email protected]> Cc: 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) Hi Les, Thanks for your detailed answer. Please see inline. From: Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>> Sent: Tuesday, August 6, 2024 5:40 PM Bruno – Thanx for the concerns. Let’s dig deeper into the concerns about “interoperability”. I will use IS Neighbors advertisements in this discussion – but conceptually the discussion applies to all codepoints – though obviously the specifics are different in each case. It is important to note that this draft has not introduced any modification to the encoding of any existing TLV. The format and the set of sub-TLVs associated with a given codepoint are defined in the respective RFCs for each codepoint and are not altered by this draft. It is important to note that this draft defines and requires the notion of a “key”, on a per TLV basis, which may not have been formally specified in some of the existing TLVs. [LES:] It is true that you won’t find the word “key” in any of the RFCs which define the existing codepoint formats – but that does not mean we have introduced anything new. Obviously, what uniquely identifies the object of a particular codepoint advertisement differs based on the advertisement type. We introduced the term “key” as a generic term for these codepoint unique values – but as I have been emphasizing this in no way alters the encoding of any TLV/sub-TLV nor does it alter the processing on reception. It just allows us to discuss the operational aspects using succinct and easily understandable language. I do not see that by doing so any confusion should result. In the case of IS-Neighbor, the correct identification of keys is already required for two reasons: 1)It determines the identity of the link/neighbor being advertised 2)It is necessary in order to correctly do two-way connectivity checking Independent of multi-TLV, implementations MUST correctly process the keys or operation of the network is compromised. The interoperability issues associated with multi-tlv do not arise because existing specifications are ambiguous as to what constitutes a key. Well that’s my question and presumably also the point raised by Ketan: have all existing (sub) TLVs specified their “key”? Because this is major requirement of this document. I’ve raised a point in a sub-sequent email which includes comments on the draft. I may obviously be wrong but I’m finding the current definition of the key a bit under specified for this TLV. (these TLVs) [LES:] If there is under specification, it is not within the scope of this draft to correct that. That would fall to an errata/update to the document which defines the codepoint. I also think it would be helpful if you (or anyone else) provided a specific example where you believe under specification exists. It would then be easier to discuss the best way to address it. But for multi-tlv, we are simply making use of the existing content. Indeed, one of the advantages of multi-tlv vs other solutions that have been discussed is that no additional content needs to be added to existing advertisements in order to support more than 255 bytes/object. Interoperability issues result from some implementations treating two TLVs with matching keys in different ways: Historically two TLVs with the same key have been treated as replacements for each other i.e., one TLV is treated as “stale” and one TLV is treated as the “current”. Possibly but I’m not excluding that some specification are treating this error condition as “underdefined”. (or “out of scope for this document” as written in this document) [LES:] The draft does not preclude this either. When all nodes in the network do not support (at least) reception of multi-tlvs for the same object, problems can and do occur. One of the ways this could manifest itself is that an implementation could ignore both of the TLVs. But it isn’t necessary to make an exhaustive list of all the ways things could break. It is sufficient to make the point that partial deployment is problematic (which we do). With multi-TLV, two TLVs with the same key are treated as complementary i.e., the information in both TLVs is treated as current. If all routers in the network don’t apply the same interpretation to multiple TLVs with the same key, then we have (obvious) interoperability issues. This is what is discussed in the draft and is the proper subject of the draft. That point is very clear in the spec. My point it only about the formal specification of the “key”. That “key” may not have been formally defined in existing specification. If the MP-TLV draft also does not specify what portion constitute the “key”, this opens interop issues. [LES:] At the risk of repeating myself, I disagree. If there are inconsistencies in the identification/use of a “key” for a codepoint, that is an interoperability issue even without the use of multi-tlv. Keys for each TLV are defined in the respective RFCs that define each codepoint. I’m not sure that the key for a TLV has been formally defined by those RFC, especially since this notion of “key” may have been introduced in this MP-TLV document. e.g. can you point to me the denition of the key in https://datatracker.ietf.org/doc/html/rfc5305#section-3 [LES:] I think I have covered this point already. Les Thanks, Regards, --Bruno Repeating that information in this draft is at best redundant – at worst unintentionally conflicting – and clearly does not scale (we have hundreds of codepoints to which multi-TLV can be applied). This is why we made the decision not to specify/discuss the “key” for every TLV – but focused on the conceptual use of the key in support of multi-TLV. Les From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Sent: Tuesday, August 6, 2024 3:36 AM 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: RE: [Lsr] Re: WG Last Call for draft-ietf-lsr-multi-tlv (7/1/2024 - 7/15/2024) Thanks Les for your reply. Please see 1 comment inline [Bruno] From: Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>> Sent: Wednesday, July 3, 2024 8:53 PM To: 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) 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. 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. [Bruno] I think that interoperability is important, especially for a link state IGP. If interop depends on the “generosity” of the receivers, why not specifying (I mean mandating with MUST) the level of generosity which is required for interop (well I mean “for things to work”) Thanks, --Bruno 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]> ____________________________________________________________________________________________________________ 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]
