Hi, Chris: Aijun Wang China Telecom
> On Aug 8, 2024, at 20:53, Christian Hopps <[email protected]> wrote: > > [As WG member] > > I'm neutral on whether the RFC should try and identify what the specific key > is for all the existing TLVs; however, I think the current draft does define > what a key is. It's exactly the data which would identify multiple TLVs as > being all part of a single logical TLV. The draft does say this so it's not > undefined. [WAJ] This is the general conception of “key”, which is exists in every place in the computer/communication industry. Can the vendors use such concepts only to interact with each other no ambiguously? Certainly Can’t. > > The only issue I see is if for some existing TLV there were some chance of > ambiguity in identifying what data this would be -- and worst case is that we > are no better off than before -- frankly I doubt this ambiguity exists. [WAJ] Ambiguity exists in almost for every multi-TLV capable code points. > > Thanks, > Chris. > [As WG member.] > > "Aijun Wang" <[email protected]> writes: > >> Hi, Les: >> >> >> >> I think you should understand that “key” is the key component of any >> Multi-TLV solution, because the sender/receiver should segment the >> long contents into different parts with the same “key”, and >> reconstruct them together via the same “key”. >> >> This is also the general way to deal with the large packet within the >> network. >> >> >> >> Then, without definition of such “key” information within the >> proposed document, we can’t say we have solved the aimed problem. >> >> On the contrary, it introduces more chaos within the network. >> >> >> >> Best Regards >> >> >> >> Aijun Wang >> >> China Telecom >> >> >> >> 发件人: [email protected] >> [mailto:[email protected]] 代表 Les Ginsberg (ginsberg) >> 发送时间: 2024年8月8日 1:00 >> 收件人: [email protected]; 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) >> >> >> >> 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]> >> 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] <[email protected]> >> Sent: Tuesday, August 6, 2024 3:36 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) >> >> >> >> Thanks Les for your reply. >> >> Please see 1 comment inline [Bruno] >> >> >> >> From: Les Ginsberg (ginsberg) <[email protected]> >> Sent: Wednesday, July 3, 2024 8:53 PM >> To: Ketan Talaulikar <[email protected]>; Yingzhen Qu < >> [email protected]> >> Cc: lsr <[email protected]>; lsr-chairs <[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]> >> Sent: Wednesday, July 3, 2024 9:56 AM >> To: Yingzhen Qu <[email protected]> >> Cc: lsr <[email protected]>; lsr-chairs <[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]> >> 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 >> >> >> >> 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] >> To unsubscribe send an email to [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. > > <signature.asc> _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
