| Internet-Draft | Unsolved Challenges of MP-TLV Proposal | February 2025 |
| Wang | Expires 29 August 2025 | [Page] |
The IS-IS routing protocol uses TLV (Type-Length-Value) encoding in a variety of protocol messages. The original IS-IS TLV definition allows only for 255 octets of value in maximum. MP-TLV [I-D.ietf-lsr-multi-tlv] gives one proposal trying to solve this issue, but has some unsolved challenges for its implementations and deployment. This document analyzes in detail these challenges and proposes the community to find other better solution.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 29 August 2025.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[I-D.ietf-lsr-multi-tlv] describes one proposal that tries to solve the big TLV issue(we call big-TLV, which the length of the contents within the TLV is exceed 255 bytes). It declares that "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. Also note the definition of the "key" exists in the specification(s) which define the TLV. "¶
Actually, there is no any such "key" definition in the related RFCs.¶
It also propose to introduce the advertisement of "MP-TLV Capabilities Advertisement", but the proposed encoding is not codepoint dependent, which is not only useless for the implementation, but also give ambiguous information for the operator.¶
Finally, there is no length boundary for all the possible IS-IS MP-TLV codepoints that listed in the section-9.2 of [I-D.ietf-lsr-multi-tlv], which can lead the potential memory crush of the MP-TLV receivers when the sender has abnormal behavior.¶
These unsolved issues challenge the implements and deployment of this document and after the analysis below, we recommend the community to consider other direction to solve the mentioned big-TLV problem of the IS-IS standard.¶
It is well known that when one sender wants to send one large packet that exceeds the Maximum Transmit Unit(MTU) of the path, it must segment the large packet, and encapsulate each segment with one unique identifier to identify each segment of the large packet.¶
The header of IPv4 datagram header is one example to show such knob: the "identification" field is defined as "Unique Packet Id for identifying the group of fragments of a single IP datagram".¶
It is impossible to concatenate the segments of one large packet together without the explicit unique identifier.¶
Such principle can apply also the segmentation of MP-TLV at the sender side and its concatenation at the receiver side, that is to say, there must exist the "key" information for the MP-TLV and every piece of the MP-TLV must carry the same "key" field.¶
[I-D.ietf-lsr-multi-tlv] states that: "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. Also note the definition of the "key" exists in the specification(s) which define the TLV.".¶
But, actually, there is no any "key" definition exists in the specification(s) which define the TLV.¶
Take the "Extended IS Reachability" (TLV 22) as the example. This TLV is defined in [RFC5305]. The original text regards to this TLV, is the followings:¶
The proposed extended IS reachability TLV contains a new data structure, consisting of: 7 octets of system ID and pseudonode number 3 octets of default metric 1 octet of length of sub-TLVs 0-244 octets of sub-TLVs
There are some sub-TLVs that can be included in this TLV, but they are only "MUST exist" in some scenario. That is to say, no "key" definition for this TLV in the specific RFC¶
Take the "Extended IP Reachability" (TLV 135) as another example. This TLV is defined also in [RFC5305]. The original text regards to this TLV, is the followings:¶
The proposed extended IP reachability TLV contains a new data structure, consisting of:
4 octets of metric information
1 octet of control information, consisting of
1 bit of up/down information
1 bit indicating the presence of sub-TLVs
6 bits of prefix length
0-4 octets of IPv4 prefix
0-250 optional octets of sub-TLVs, if present consisting of
1 octet of length of sub-TLVs
0-249 octets of sub-TLVs, where each sub-TLV consists of a sequence of
1 octet of sub-type
1 octet of length of the Value field of the sub-TLV
0-247 octets of value
There is also no any "key" definition information for this TLV in the specific RFC.¶
Such "key" definition information defined only in the [I-D.ietf-lsr-multi-tlv], which illustrates that this document change or add more restraints to the specification that defines these IS-IS TLVs.¶
Even we accept the newly definition of "key" definition for TLV 22 in [I-D.ietf-lsr-multi-tlv], as illustrated below that extract directly from this document:¶
As an example, consider the Extended IS Reachability TLV (type 22). A neighbor in this TLV is specified by: * 7 octets of system ID and pseudonode number * 3 octets of default metric * Optionally one or more of the following link identifiers: - IPv4 interface address and IPv4 neighbor address as specified in [RFC5305] - IPv6 interface address and IPv6 neighbor address as specified in [RFC6119] - Link Local/Remote Identifiers as specified in [RFC5307] The key consists of the 7 octets of system ID and pseudonode number plus the set of link identifiers which are present.
Here, we should notice that "the set of link identifiers", which is the newly defined "key" in this document, is "Optionally". That is to say, any vendor can select any one of them as the "key" information to segment the MP-TLV. This will certainly lead the confusion on the receiver when it receives the segments of MP-TLV from different vendors and try to concatenate them respectively. Take the example below:¶
If vendor A send pieces of TLV 22 instance A¶
<22, Neighbor System ID, other possible sub-TLVs, IPv4 Local/Remote Address> + object info !!V4 addresses only <22, Neighbor System ID, IPv4 Local/Remote Address> + object info !!V4 addresses only
vendor B send pieces of TLV 22 instance B:¶
<22, Neighbor System ID, other possible sub-TLVs, IPv6 Local/Remote Address> + additional object info !!V6 addresses only <22, Neighbor System ID, IPv6 Local/Remote Address> + additional object info !!V6 addresses only
How vendor A determine the “key” parts for concatenating the different pieces of TLV 22 instance B¶
How vendor B determine the “key” parts for concatenating the different pieces of TLV 22 instance A?¶
Imaging there is another vendor C, receive both of these pieces for another two instances, how does vendor C determine such information solely from the ambiguous segmented pieces?¶
From the above scenario, we can see there will be many chaos for the interoperability issues within the operator network, which should be avoided by the publish of the network protocol standard. But [I-D.ietf-lsr-multi-tlv] can't accomplish such task, it can only lead more chaos in the operator's network.¶
[I-D.ietf-lsr-multi-tlv] states that multiple occrences of a TLV has already defined, and give one example of Router Capability TLV(Type 242) [RFC7981]. But [RFC7981] states that "Where a receiving system has two copies of an IS-IS Router CAPABILITY TLV from the same system that have conflicting information for a given sub-TLV, the procedure used to choose which copy shall be used is undefined.".¶
Another example is "Application-Specific SRLG (Type 238)" [RFC9479]. Even the document mentioned the possibilities of multiple occurrences, as "Multiple TLVs for the same link MAY be advertised.", but there is lack of the description of what's the procedure of the receiver.¶
As the draft [I-D.ietf-lsr-multi-tlv] emphasize that "The encoding of TLVs is not altered by the introduction of MP-TLV support.", then, there is no any place to encode the actual length of the big-TLV. In theory, the sender can send unlimited occurrences of any MP-TLV codepoints listed in section-9.2 of [I-D.ietf-lsr-multi-tlv]. This will make huge burden for the memory allocation of the receiver on these possible MP-TLV codepoint, and also the potential attacks from one abnormal sender.¶
In order to assure the interoperability and deployment of MP-TLV feature in operator's network, the document [I-D.ietf-lsr-multi-tlv] introduces the "MP-TLV Capability Advertisement" sub-TLV within the IS-IS Router CAPABILITY TLV, but it is IS-IS TLV/sub-TLV codepoint independent. It is also impossible that let the sender don't send such announcements until only after it supports the concatenation of MP-TLV codepoints illustrated in section-9.2 of [I-D.ietf-lsr-multi-tlv]. Then the sending of such capabilities announcements gives no any clues for the receiver, and also the operator. It can only mislead the operator the support of MP-TLV for some expected MP-TLV is achieved, but in actually it does not.¶
The document [I-D.ietf-lsr-multi-tlv] states that "diligence is still required on the part of the operator to ensure that configurations which require the sending of MP-TLV for a given codepoint are not introduced on any node in the network until all nodes in the network support MP-TLV for the relevant codepoints. ", which is impossible and exists only in the imagination of the authors.¶
The mechanism described in this document does not raise any new security issues for the IS-IS protocols.¶
Thanks Les, Acee, David, Adrian, Robert, Tony Li etc. for the detail discussion to foster this analysis document.¶
None.¶