Network Working Group A. Wang
Internet-Draft China Telecom
Intended status: Informational 28 April 2025
Expires: 30 October 2025
Unsolved Challenges of IS-IS MP-TLV Proposal
draft-wang-lsr-unsolved-challenge-of-mp-tlv-02
Abstract
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.
Requirements Language
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.
Status of This Memo
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 30 October 2025.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wang Expires 30 October 2025 [Page 1]
Internet-Draft Unsolved Challenges of MP-TLV Proposal April 2025
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. General Process of Segmentation and Concatenation . . . . . . 3
3. Unsolved "Key" Information for MP-TLV Proposal . . . . . . . 3
3.1. Ambigious "key" definition for TLV 22 . . . . . . . . . . 4
3.2. Concatenation Challenge of the Nested sub-sub-TLV . . . . 6
4. Unsolved Length Boundary for MP-TLV Proposal . . . . . . . . 6
5. Ambiguous "MP-TLV" Capabilities Definition . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
[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" that is used to identify the set
of TLVs that form an MP-TLV is the same key used in the absence of
MP-TLV support. Also note the definition of the "key" is part of the
specification(s) that define(s) the TLV and is therefore outside the
scope of this document.
NOTE: This document intentionally does not include a definition of
the key for each codepoint. To do so would be redundant and risk
unintentionally deviating from the definition that already exists in
the relevant specifications. Also, the term "key" is a generic term
that is not used in the relevant specifications. "
Actually, there is no any such "key" or some other "generic term"
definition of the same purpose in the related RFCs.
Wang Expires 30 October 2025 [Page 2]
Internet-Draft Unsolved Challenges of MP-TLV Proposal April 2025
And, under the proposed mechanism, it will be very difficult and
inefficient to concatenate the several sub-sub-TLV pieces into the
original top-TLV and associated parent sub-TLV with the undefined
"key".
It proposes 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 mislead
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.
2. General Process of Segmentation and Concatenation
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.
3. Unsolved "Key" Information for MP-TLV Proposal
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:
Wang Expires 30 October 2025 [Page 3]
Internet-Draft Unsolved Challenges of MP-TLV Proposal April 2025
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
Figure 1: Extended IS Reachability(TLV 22)
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
Figure 2: Extended IP Reachability(TLV 135)
No "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.
3.1. Ambigious "key" definition for TLV 22
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:
Wang Expires 30 October 2025 [Page 4]
Internet-Draft Unsolved Challenges of MP-TLV Proposal April 2025
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.
Figure 3: Ambigious "Key" definition for TLV 22
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
Figure 4: Instance A of TLV 22 from vendor A
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
Figure 5: Instance B of TLV 22 from vendor B
How vendor A determine the “key†parts for concatenating the
different pieces of TLV 22 instance B, considering there may be
several IPv6 address for one link.
How vendor B determine the “key†parts for concatenating the
different pieces of TLV 22 instance A,considering there may be
several IPv4 address for one link?
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?
Wang Expires 30 October 2025 [Page 5]
Internet-Draft Unsolved Challenges of MP-TLV Proposal April 2025
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.
3.2. Concatenation Challenge of the Nested sub-sub-TLV
[I-D.ietf-lsr-multi-tlv] states that "the mechanism described in this
document is applicable to top level TLVs as well as any level of sub-
TLVs that may appear within a top level TLV.", but it will be very
very challenging and inefficient. Let's take one example to
illustrate it:
Suppose we have one sub-sub-TLV that has exceed the 255 bytes, and
needs to be sent in three pieces(let’s call them P1, P2,P3).
Under the current MP-TLV proposal, these pieces must be sent in the
following format in one or more LSPs:
TOP_TLV?undefined ?key1?, sub-TLV?undefined ?key2?, sub-sub-TLV(undefined ?key3?, P1)??
TOP_TLV?undefined ?key1?, sub-TLV?undefined ?key2?, sub-sub-TLV(undefined ?key3?, P2)??
TOP_TLV?undefined ?key1?, sub-TLV?undefined ?key2?, sub-sub-TLV(undefined ?key3?, P3)??
Figure 6: Concatenation Challenge of the Nested sub-sub-TLV
Besides the ambiguity of the undefined ‘key1’, ‘key2’, ‘key3’ in the
above nest encapsulations, which can lead to enormous challenges for
the interoperability, such encapsulation proposal, is very
inefficient.
The IETF community should try to find other general and efficient
solution..
4. Unsolved Length Boundary for MP-TLV Proposal
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.
Wang Expires 30 October 2025 [Page 6]
Internet-Draft Unsolved Challenges of MP-TLV Proposal April 2025
5. Ambiguous "MP-TLV" Capabilities Definition
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.
6. Security Considerations
The mechanism described in this document does not raise any new
security issues for the IS-IS protocols.
7. Acknowledgement
Thanks Les, Acee, David, Adrian, Robert, Tony Li , Ketan etc. for the
detail discussion to foster this analysis document.
8. IANA Considerations
None.
9. References
9.1. Normative References
[I-D.ietf-lsr-multi-tlv]
Kaneriya, P., Li, T., Przygienda, T., Hegde, S., and L.
Ginsberg, "Multi-Part TLVs in IS-IS", Work in Progress,
Internet-Draft, draft-ietf-lsr-multi-tlv-18, 25 April
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
lsr-multi-tlv-18>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Wang Expires 30 October 2025 [Page 7]
Internet-Draft Unsolved Challenges of MP-TLV Proposal April 2025
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions
for Advertising Router Information", RFC 7981,
DOI 10.17487/RFC7981, October 2016,
<https://www.rfc-editor.org/info/rfc7981>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9479] Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and
J. Drake, "IS-IS Application-Specific Link Attributes",
RFC 9479, DOI 10.17487/RFC9479, October 2023,
<https://www.rfc-editor.org/info/rfc9479>.
9.2. Informative References
Author's Address
Aijun Wang
China Telecom
Beiqijia Town, Changping District
Beijing
102209
China
Email: wangaj3@chinatelecom.cn
Wang Expires 30 October 2025 [Page 8]