Aijun – The draft is explicit on this point. To repeat the quote:
https://www.ietf.org/archive/id/draft-ietf-lsr-multi-tlv-08.html#name-multi-part-tlvs says: “The encoding of TLVs is not altered by the introduction of MP-TLV support. In particular, the "key" which is used to identify the set of TLVs which form an MP-TLV is the same key used in the absence of MP-TLV support.” If I have multiple TLVs associated with Link1 – I use the same set of identifiers for all TLVs associated with that link. Same for Link2, Link3, etc. There is no relationship between the TLVs used to advertise the attributes for Link1 and the TLVs used to advertise attributes for Link2. Les From: Aijun Wang <wangai...@tsinghua.org.cn> Sent: Thursday, February 13, 2025 1:47 AM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com>; lsr@ietf.org Cc: ops-...@ietf.org; draft-ietf-lsr-multi-tlv....@ietf.org; last-c...@ietf.org; 'The IESG' <i...@ietf.org> Subject: 答复: [Lsr] Re: 【Network Progtocol Standard/RFC Should Consider more its Deploment Challenges】: [Last-Call] draft-ietf-lsr-multi-tlv and key information Hi, Les: Your example doesn’t get the key points of my arguments. What I want to say is, if one router has two interfaces, both have one IPv4 address and one IPv6 address. Then, in non MP-TLV scenario, each of these links can send the TLV 22 to two other neighbors, either contain only IPv4 address, or contain only IPv6 address, the receiver can identify them as two different links correctly. But for MP-TLV scenario, if the information associated one link is exceed 255 bytes, you must slice the TLV 22 of this link, right? If the one segment of sliced TLV 22 for this link contain only IPv4 address, another segment of sliced TLV contain only IPv6 address(both segments will be legitimate), will the receiver treat the information associated with them as from different link? (actually, they are properties of the same link). If so, the TE calculation will be broken. Am I clear for my statements? Best Regards Aijun Wang China Telecom 发件人: forwardingalgori...@ietf.org<mailto:forwardingalgori...@ietf.org> [mailto:forwardingalgori...@ietf.org] 代表 Les Ginsberg (ginsberg) 发送时间: 2025年2月13日 15:41 收件人: Aijun Wang <wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>>; lsr@ietf.org<mailto:lsr@ietf.org> 抄送: ops-...@ietf.org<mailto:ops-...@ietf.org>; draft-ietf-lsr-multi-tlv....@ietf.org<mailto:draft-ietf-lsr-multi-tlv....@ietf.org>; last-c...@ietf.org<mailto:last-c...@ietf.org>; 'The IESG' <i...@ietf.org<mailto:i...@ietf.org>> 主题: [Lsr] Re: 【Network Progtocol Standard/RFC Should Consider more its Deploment Challenges】: [Last-Call] draft-ietf-lsr-multi-tlv and key information Aijun – There are three relevant RFCs for this case: RFC 5305: which specifies when to send IPv4 endpoint addresses in IS Neighbor TLVs. RFC 5307: which specifies when to send Link IDs in IS Neighbor TLVs RFC 6119: which specifies when to send IPv6 endpoint addresses in IS Neighbor TLVs https://www.ietf.org/archive/id/draft-ietf-lsr-multi-tlv-08.html#name-multi-part-tlvs says: “The encoding of TLVs is not altered by the introduction of MP-TLV support. In particular, the "key" which is used to identify the set of TLVs which form an MP-TLV is the same key used in the absence of MP-TLV support.” So, the answer to the question: “which link identifiers should be included” can be found in the above RFCs. The statement you make below: “For Non MP-TLV scenario, there will be no problem----Normally, different link can use different link identifier set, the sender/receiver can associate the related link parameter sub-TLV to the link that identified by the identifier.” is FALSE. Here is a simple example to illustrate: A and B are neighbors connected by a single link A has IPv4 address 192.168.1.1 and local Link ID 1. B has IPv4 address 192.168.1.2 and Local Link ID 20. A sends: (Neighbor B, Local IPv4 address 192.168.1.1 Remote IPv4 Address 192.168.2.2) B sends: (Neighbor A, Local Link ID 20, Remote Link ID 1) Two -way connectivity check fails because there are no matching identifiers in the advertisements from A and B. NOTE: B is not following existing RFCs. Nothing allows only Link IDs to be sent for a numbered link. Implementations that follow the existing RFCs will interoperate correctly. If an implementation does not, then interoperability issues can occur. This has nothing to do with MP-TLV. Les From: Aijun Wang <wangai...@tsinghua.org.cn<mailto:wangai...@tsinghua.org.cn>> Sent: Wednesday, February 12, 2025 8:16 PM To: Les Ginsberg (ginsberg) <ginsb...@cisco.com<mailto:ginsb...@cisco.com>>; lsr@ietf.org<mailto:lsr@ietf.org> Cc: ops-...@ietf.org<mailto:ops-...@ietf.org>; draft-ietf-lsr-multi-tlv....@ietf.org<mailto:draft-ietf-lsr-multi-tlv....@ietf.org>; last-c...@ietf.org<mailto:last-c...@ietf.org>; 'The IESG' <i...@ietf.org<mailto:i...@ietf.org>> Subject: 答复: 【Network Progtocol Standard/RFC Should Consider more its Deploment Challenges】: [Last-Call] draft-ietf-lsr-multi-tlv and key information Hi, Les: I missed this mail and notice it in just several minutes ago. To distinguish this discussion with other threads, I update the title to make it more outstanding and relevant. I copy it also to IESG mail list for further discussions. Let me give you the information you want for the discussions, it is also one example in your document, but you try to shun it when we compare the discussed version 06 and your latest Last-Call version of 07 and 08: a) Specific codepoint “Extended IS Reachability”(type 22) b) Specific information that is underspecified “The key information”. Currently, in your document, you described just as “The key consists of 7 octets of system ID and pseudocode number plus the set of link identifiers which are present” But there is no any description for the “key” in its original RFC document for this IS-IS TLV(type 22). And, in your document at the same section, you described(I don’t know is there any RFC document it, if you can point out, I appreciate your information): “Optionally one or more of the following link identifiers: * IPv4 interface address and IPv4 neighbor address as specified in [RFC5305<https://www.rfc-editor.org/info/rfc5305>]¶<https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-06#section-4.1-2.3.2.1.1> * IPv6 interface address and IPv6 neighbor address as specified in [RFC6119<https://www.rfc-editor.org/info/rfc6119>]¶<https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-06#section-4.1-2.3.2.2.1> * Link Local/Remote Identifiers as specified in [RFC5307<https://www.rfc-editor.org/info/rfc5307>]¶<https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-06#section-4.1-2.3.2.3.1> Then, come the question, as that I raised to Ops area experts Giuseppe at https://mailarchive.ietf.org/arch/msg/lsr/Fv7U9msEm9-sUrzOOm0iO7RoIVY/: For the sender, which link identifiers should be included? If different part of the MP-TLV uses the different link identifiers, they will all be valid “Extended IS Reachability” TLV, should the receiver threat them as MP-TLV to concatenate them together, or treat them as multi occurrence of the same TLV, replace the previous one with the newest occurrence? c) An explanation as to why this issue has not been seen in the field in the last 25 years For Non MP-TLV scenario, there will be no problem----Normally, different link can use different link identifier set, the sender/receiver can associate the related link parameter sub-TLV to the link that identified by the identifier. But, for MP-TLV scenario, it is different story, the sender/receiver MUST agree on the “key” of the link identifier, which is emphasized in your version 6 document (https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-06#name-example-extended-is-reachab), but delete it in the newer version. Or else, the attributes information for one link can’t be associated together. I expect we, or the IESG experts, or other interested experts to join in the technical discussions, to solve the ambiguity and potential challenges for its possible deployment in operator network. I know, from the POV of the vendor, such protocol can be implemented, but we should consider its possible deployment challenges, or else, it will be just shelved in the IETF repository. Network Protocol Standard/RFC Should Consider more its Deployment Challenges. Best Regards Aijun Wang China Telecom 发件人: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 发送时间: 2025年2月13日 6:39 收件人: lsr@ietf.org<mailto:lsr@ietf.org> 抄送: ops-...@ietf.org<mailto:ops-...@ietf.org>; draft-ietf-lsr-multi-tlv....@ietf.org<mailto:draft-ietf-lsr-multi-tlv....@ietf.org>; last-c...@ietf.org<mailto:last-c...@ietf.org>; Giuseppe Fioccola <giuseppe.fiocc...@huawei.com<mailto:giuseppe.fiocc...@huawei.com>> 主题: [Last-Call] draft-ietf-lsr-multi-tlv and key information Folks – Speaking as a WG member – not as an author of this draft… The discussion of “key information” and what is required in this draft has a long history. For those of you who have not followed this discussion and/or need a way to catch up, I highly recommend the excellent document shepherd’s report written by Yingzhen. https://datatracker.ietf.org/doc/draft-ietf-lsr-multi-tlv/shepherdwriteup/ This writeup includes extensive references to relevant emails from the WG list. Regarding continued claims that the draft is underspecified, a few key points: 1)The protocol has 25 years of history of successful deployments from multiple vendors of features which are dependent on accurate processing of TLVs which support advertisement of multiple objects. Specifically, but not exclusively, correct identification of IS Neighbor advertisements to not only a specific neighbor but also a specific link is essential to the operation of features like RSVP-TE, SR-TE, Flex-Algo, and BGP-LS – as well as correct operation of the base SPF calculation. Other examples (prefixes, capability advertisements) exist. Anyone who claims that the protocol (not just this document) is underspecified in this regard is ignoring (or unaware of) successful use of the protocol for the past 25 years. 2)This draft makes no changes to the encoding of any TLV. It only changes what actions a node takes when receiving multiple TLVS associated with the same object. This is explicitly stated in https://www.ietf.org/archive/id/draft-ietf-lsr-multi-tlv-08.html#name-multi-part-tlvs . It therefore does not need to update existing TLV definitions. Claims that further specification of key information is required do not stand up to scrutiny based on the above. Anyone claiming there is underspecification MUST provide detail as to: a)Specific codepoint b)Specific information that is underspecified c)An explanation as to why this issue has not been seen in the field in the last 25 years If there is a claim which passes the above scrutiny, it should be addressed in some fashion by the WG – though the most appropriate means is likely to be to update the existing RFC which defined the codepoint as such an issue affects deployments independent of the use of MP-TLV. However, thus far, in all the discussion of this document, no claim has passed such scrutiny. Les
_______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
