Multi-part TLVs in IS-IS

Abstract

New technologies are adding new information into IS-IS while deployment scales are simultaneously increasing, causing the contents of many critical TLVs to exceed the currently supported limit of 255 octets. Extensions exist that require significant IS-IS changes that could help address the problem, but a less drastic solution would be beneficial. This document codifies the common mechanism of extending the TLV content space through multiple TLVs.¶

1. Introduction

The continued growth of the Internet has resulted in a commensurate growth in the scale of service provider networks and the amount of information carried in IS-IS [ISO10589] Type-Length-Value (TLV) tuples. Simultaneously, new traffic engineering technologies are defining new attributes, further adding to the scaling pressures. The original TLV definition allows for 255 octets of payload, which is becoming increasingly stressful.¶

Some TLV definitions have addressed this by explicitly stating that a TLV may appear multiple times inside of an LSP. However, this has not been done for many legacy TLVs, leaving the situation somewhat ambiguous. The intent of this document is to clarify and codify the situation by explicitly making multiple occurences of a TLV the mechanism for scaling TLV contents, except where otherwise explicitly stated.¶

This document does not pertain to any TLV where multiple occurrences of a TLV are already defined. As of this writing, the authors are aware of the following TLVs that fall into this category:¶

• Router Capability TLV (Type 242) [RFC7981]¶
• GMPLS-SRLG (Type 138) [RFC5307]¶
• IPv6 SRLG (Type 139) [RFC6119]¶
• Application-Specific SRLG (Type 238) [RFC8919]¶
• Application-Specific Link Attributes (sub-TLV Type 16) [RFC8919]¶

Today, for example, the Extended IS Reachability TLV (22) [RFC5305] and MT Intermediate Systems TLV (222) [RFC5120] are TLVs where existing standards do not specify sending multiple TLVs for the same object and no other mechanism for expanding the information carrying capacity of the TLV has been specified.¶

[RFC7356] has proposed a 16 bit length field for TLVs in flooding scoped Protocol Data Units (PDUs), but this does not address how to expand the information advertised when using the existing 8-bit length TLVs.¶

The mechanism described in this document has not been documented for all TLVs previously, so it is likely that some implementations would not interoperate correctly if these mechanisms were used without caution.¶

The mechanism described in this document has been used explicitly by some implementations, so this document is not creating an unprecedented mechanism. It is specifying a means for extending TLVs where no extension mechanism has been previously specified, and defining a default extension mechanism for future TLVs, if they choose not to specify another extension mechanism. The mechanism described in this document is applicable to top level TLVs as well as any level of sub-TLVs which may appear within a top level TLV.¶

3. Multi-part TLVs

A TLV is a tuple of (Type, Length, Value) and can be advertised in IS-IS packets. TLVs sometimes contain information, called a key, that indicates the applicability of the remaining contents of the TLV. If a router advertises multiple TLV tuples with the same Type code in an IS-IS IIH packet or in the set of LSPs for a level with the same key value, they are considered a multi-part TLV (MP-TLV).¶

4. Procedure for Advertising Multi-part TLVs

Network operators should not enable Multi-part TLVs until ensuring that all implementations that will receive the Multi-part TLVs are capable of interpreting them correctly.¶

If a Multi-part TLV contains information that specifies the applicability of its contents (i.e., a key), the key information MUST be replicated in additional TLV instances so that all contents specific to that key can be identified.¶

5. Procedure for Receiving Multi-part TLVs

A node that receives a multi-part TLV MUST accept all of the information in all of the parts. The order of arrival and placement of the TLV parts in LSP fragments is irrelevant. The placement of the TLV parts in an IIH is irrelevant.¶

The contents of a multi-part TLV MUST be processed as if they were concatenated. If the internals of the TLV contain key information, then replication of the key information should be taken to indicate that subsequent data MUST be processed as if the subsequent data were concatenated after a single copy of the key information.¶

For example, suppose that a node receives an LSP with a multi-part Extended IS Reachability TLV. The first part contains key information K with sub-TLVs A, B, and C. The second part contains key information K with sub-TLVs D, E, and F. The receiving node must then process this as having key information K and sub-TLVs A, B, C, D, E, F, or, because ordering is irrelevant, sub-TLVs D, E, F, A, B, C, or any other permutation.¶

A TLV may contain information in its fixed part that is not part of the key. For example, the metric in both the Extended IS Reachability TLV and the Extended IP Reachability TLV does not specify which object the TLV refers to, and thus is not part of the key. Having inconsistent information in different parts of a MP-TLV is an error and is out of scope for this document.¶

6. Deployment Considerations

Sending of MP-TLVs in the presence of nodes which do not correctly process such advertisements can result in interoperablity issues, including incorrect forwarding of packets. It is RECOMMENDED that implementations which support the sending of MP-TLVs provide configuration controls to enable/disable generation of MP-TLVs. Implementations also SHOULD report alarms under the following conditions:¶

• If an MP-TLV is received when use of MP-TLVs is disabled.¶
• If local configuration requires the use of MP-TLVs when generation of MP-TLVs is disabled.¶

Note that MP-TLV support may vary on a per TLV basis. For example, an implementation might support MP-TLVs for IS Extended Reachabolity but not for IP Reachability.¶

9. Normative References

[ISO10589]

ISO, "Intermediate system to Intermediate system routing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)", August 1987, <ISO/IEC 10589:2002>.

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

[RFC5120]

Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, <https://www.rfc-editor.org/info/rfc5120>.

[RFC5304]

Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, <https://www.rfc-editor.org/info/rfc5304>.

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

[RFC5307]

Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, <https://www.rfc-editor.org/info/rfc5307>.

[RFC5310]

Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, <https://www.rfc-editor.org/info/rfc5310>.

[RFC6119]

Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, February 2011, <https://www.rfc-editor.org/info/rfc6119>.

[RFC7356]

Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, September 2014, <https://www.rfc-editor.org/info/rfc7356>.

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

[RFC8919]

Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and J. Drake, "IS-IS Application-Specific Link Attributes", RFC 8919, DOI 10.17487/RFC8919, October 2020, <https://www.rfc-editor.org/info/rfc8919>.