Multi-part TLVs in IS-IS

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 16 August 2024.¶

Copyright Notice

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶

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

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 alter the encoding of 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) [RFC9479]¶

• Instance Identifier (type 7) [RFC8202]¶

• Application-Specific Link Attributes (sub-TLV Type 16) [RFC9479]¶

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

2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

6. Specification of Applicability of Multi-part TLV

As mentioned in Section 1, existing specifications for some TLVs have explicitly stated that the use of Multi-Part TLV procedures are applicable to that codepoint. However, Multi-Part TLV procedures are potentially applicable to any codepoint that allows sub-TLVs to be included as part of the information advertised. The lack of explicit indication of applicability of Multi-Part TLV procedures to all codepoints to which such procedures could be applied contributes to potential interoperability problems if/when the need arises to advertise more than 255 bytes of information for such a codepoint.¶

This document makes explicit the applicability of Multi-Part TLV procedures for all existing codepoints defined for the IS-IS protocol by extending existing and relevant IANA protocol registries to include an explicit indication of applicability of Multi-Part TLV procedures for each codepoint. See Section 8. This guarantees that any new codepoints defined by future protocol extensions will explicitly indicate the applicability of Multi-Part TLV procedures to the new codepoints.¶

8. IANA Considerations

Type: 30 (suggested)
Description: MP-TLV Support for TLVs with implicit support
MP-TLV Applicability: N
Reference: This document Section 7.2

9. Security Considerations

This document creates no new security issues for IS-IS. Additional instances of existing TLVs expose no new information.¶

Security concerns for IS-IS are addressed in [ISO10589], [RFC5304], and [RFC5310].¶

Authors' Addresses