Network Working Group A. Wang
Internet-Draft China Telecom
Intended status: Informational 25 February 2025
Expires: 29 August 2025

Unsolved Challenges of IS-IS MP-TLV Proposal
draft-wang-lsr-unsolved-challenge-of-mp-tlv-00

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 29 August 2025.

Wang Expires 29 August 2025 [Page 1]

Internet-Draft Unsolved Challenges of MP-TLV Proposal February 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
4. Undefined Behavior for unkeyed TLV . . . . . . . . . . . . . 5
5. Unsolved Length Boundary for MP-TLV Proposal . . . . . . . . 6
6. Ambiguous "MP-TLV" Capabilities Definition . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7

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" 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.

Wang Expires 29 August 2025 [Page 2]

Internet-Draft Unsolved Challenges of MP-TLV Proposal February 2025

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

[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

Figure 1: Extended IS Reachability(TLV 22)

Wang Expires 29 August 2025 [Page 3]

Internet-Draft Unsolved Challenges of MP-TLV Proposal February 2025

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

Figure 2: Extended IP Reachability(TLV 135)

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.

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:

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

Wang Expires 29 August 2025 [Page 4]

Internet-Draft Unsolved Challenges of MP-TLV Proposal February 2025

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

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.

4. Undefined Behavior for unkeyed TLV

[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.".

Wang Expires 29 August 2025 [Page 5]

Internet-Draft Unsolved Challenges of MP-TLV Proposal February 2025

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.

5. 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.

6. 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.

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.

7. Security Considerations

The mechanism described in this document does not raise any new
security issues for the IS-IS protocols.

8. Acknowledgement

Thanks Les, Acee, David, Adrian, Robert, Tony Li etc. for the detail
discussion to foster this analysis document.

Wang Expires 29 August 2025 [Page 6]

Internet-Draft Unsolved Challenges of MP-TLV Proposal February 2025

9. IANA Considerations

None.

10. References

10.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-10, 21 February
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
lsr-multi-tlv-10>.

[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>.

[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>.

10.2. Informative References

Author's Address

Aijun Wang
China Telecom
Beiqijia Town, Changping District
Beijing
102209
China

Wang Expires 29 August 2025 [Page 7]

Internet-Draft Unsolved Challenges of MP-TLV Proposal February 2025

Email: wangaj3@chinatelecom.cn

Wang Expires 29 August 2025 [Page 8]