Unsolved Challenges of IS-IS MP-TLV Proposal

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

Take the "Extended IS Reachability" (TLV 22) as the example. This TLV is defined in . The original text regards to this TLV, is the followings:

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 . The original text regards to this TLV, is the followings:

No "key" definition information for this TLV in the specific RFC. Such "key" definition information defined only in the , 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 , as illustrated below that extract directly from this document:

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

+ 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:

+ 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, 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? 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 can't accomplish such task, it can only lead more chaos in the operator's network.

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:

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

As the draft 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 . 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 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 . 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 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 , Ketan etc. for the detail discussion to foster this analysis document.

None.