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

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

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

There is also no any "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 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 can't accomplish such task, it can only lead more chaos in the operator's network.

states that multiple occrences of a TLV has already defined, and give one example of Router Capability TLV(Type 242) . But 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)" . 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 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 document 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.