Internet-Draft Multi-part TLVs July 2022
Kaneriya, et al. Expires 5 January 2023 [Page]
Workgroup:
LSR Working Group
Internet-Draft:
draft-pkaneria-lsr-multi-tlv-01
Published:
Intended Status:
Standards Track
Expires:
Authors:
P. Kaneriya
Juniper Networks
Tony. Li
Juniper Networks
Antoni. Przygienda
Juniper Networks
S. Hegde
Juniper Networks
C. Bowers
Juniper Networks
L. Ginsberg
Cisco Systems

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 such as [RFC7356] 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.

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

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.

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 copies 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 does nothing to address legacy implementations that do not yet implement the full breadth and scope of that RFC.

The mechanism described in this document has not been documented for all TLVs previously, so it is likely that some implementations would not inter-operate correctly if these mechanisms were used without caution. To avoid this issue, this document introduces a new router capability [RFC7981] so that implementations can advertise their readiness to participate in this mechanism.

The mechanism described in this document has been used explicitly by some TLVs, 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.

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.

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. The Multi-part TLV Capability

The Multi-part TLV Capability is a sub-TLV of the Router Capability TLV [RFC7981]. Nodes that are prepared to receive multi-part TLVs SHOULD advertise this capability. The capability has the format:

           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          |      Type     |     Length    |
          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5. Procedure for Advertising Multi-part TLVs

If all routers in an area advertise the Multi-part TLV Capability a node MAY advertise multi-part TLVs to increase space for payload values, unless otherwise specified by the TLV.

If the TLV contains information that specifies the applicability of its contents (i.e., a key), the key information SHOULD be replicated in additional TLV instances so that all contents specific to that key can be advertised.

As an example, consider the Extended IS Reachability TLV (type 22). A neighbor in this TLV is specified by:

This acts as the key for this entry. The key is followed by up to 244 octets of sub-TLV information.

If this is insufficient sub-TLV space, then the node MAY advertise additional Extended IS Reachability TLVs. The key information MUST be replicated identically and the additional sub-TLV space may be populated with additional information.

6. Procedure for Receiving Multi-part TLVs

A node that supports the Multi-part TLV Capability and 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 concantenated 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.

7. IANA Considerations

This document requests a code point allocation for the following sub-TLV.

7.1. The Multiple TLV Instance Sub-TLV

IANA is requested to add a new sub-TLV to the IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV [capreg].

  • Value - XXX (TBD by IANA).
  • Description - Multi-part TLV Capability

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

9. References

9.1. 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)", , <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, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC5304]
Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, , <https://www.rfc-editor.org/info/rfc5304>.
[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, , <https://www.rfc-editor.org/info/rfc5310>.
[RFC7981]
Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, , <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, , <https://www.rfc-editor.org/info/rfc8174>.

9.2. Informative References

[capreg]
IANA, "IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV Registry", , <https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-242>.
[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, , <https://www.rfc-editor.org/info/rfc5120>.
[RFC5305]
Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, , <https://www.rfc-editor.org/info/rfc5305>.
[RFC7356]
Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, , <https://www.rfc-editor.org/info/rfc7356>.

Authors' Addresses

Parag Kaneriya
Juniper Networks
Elnath-Exora Business Park Survey
Bangalore 560103
Karnataka
India
Tony Li
Juniper Networks
1133 Innovation Way
Sunnyvale, California 94089
United States of America
Antoni Przygienda
Juniper Networks
1133 Innovation Way
Sunnyvale, California 94089
United States of America
Shraddha Hegde
Juniper Networks
Elnath-Exora Business Park Survey
Bangalore 560103
Karnataka
India
Chris Bowers
Juniper Networks
1133 Innovation Way
Sunnyvale, California 94089
United States of America
Les Ginsberg
Cisco Systems
821 Alder Drive
Milpitas, CA 95035
United States of America