Skip to main content

Multi-part TLVs in IS-IS
draft-pkaneria-lsr-multi-tlv-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Parag Kaneriya , Tony Li , Tony Przygienda , Shraddha Hegde , Chris Bowers , Les Ginsberg
Last updated 2022-07-04
Replaced by draft-ietf-lsr-multi-tlv
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-pkaneria-lsr-multi-tlv-01
LSR Working Group                                            P. Kaneriya
Internet-Draft                                                  Tony. Li
Intended status: Standards Track                      Antoni. Przygienda
Expires: 5 January 2023                                         S. Hegde
                                                               C. Bowers
                                                        Juniper Networks
                                                             L. Ginsberg
                                                           Cisco Systems
                                                             4 July 2022

                        Multi-part TLVs in IS-IS
                    draft-pkaneria-lsr-multi-tlv-01

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.

Copyright Notice

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

Kaneriya, et al.         Expires 5 January 2023                 [Page 1]
Internet-Draft               Multi-part TLVs                   July 2022

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Multi-part TLVs . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  The Multi-part TLV Capability . . . . . . . . . . . . . . . .   3
   5.  Procedure for Advertising Multi-part TLVs . . . . . . . . . .   4
   6.  Procedure for Receiving Multi-part TLVs . . . . . . . . . . .   4
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  The Multiple TLV Instance Sub-TLV . . . . . . . . . . . .   5
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

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.

Kaneriya, et al.         Expires 5 January 2023                 [Page 2]
Internet-Draft               Multi-part TLVs                   July 2022

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

   *  Type: 1 octect, value XXX.

Kaneriya, et al.         Expires 5 January 2023                 [Page 3]
Internet-Draft               Multi-part TLVs                   July 2022

   *  Length: 1 octect, value 0.

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:

   *  7 octets of system ID and pseudonode number

   *  3 octets of default metric

   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.

Kaneriya, et al.         Expires 5 January 2023                 [Page 4]
Internet-Draft               Multi-part TLVs                   July 2022

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

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

Kaneriya, et al.         Expires 5 January 2023                 [Page 5]
Internet-Draft               Multi-part TLVs                   July 2022

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

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

9.2.  Informative References

   [capreg]   IANA, "IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV
              Registry", August 1987, <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, February 2008,
              <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, October
              2008, <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, September 2014,
              <https://www.rfc-editor.org/info/rfc7356>.

Authors' Addresses

   Parag Kaneriya
   Juniper Networks
   Elnath-Exora Business Park Survey
   Bangalore 560103
   Karnataka
   India
   Email: pkaneria@juniper.net

Kaneriya, et al.         Expires 5 January 2023                 [Page 6]
Internet-Draft               Multi-part TLVs                   July 2022

   Tony Li
   Juniper Networks
   1133 Innovation Way
   Sunnyvale, California 94089
   United States of America
   Email: tony.li@tony.li

   Antoni Przygienda
   Juniper Networks
   1133 Innovation Way
   Sunnyvale, California 94089
   United States of America
   Email: prz@juniper.net

   Shraddha Hegde
   Juniper Networks
   Elnath-Exora Business Park Survey
   Bangalore 560103
   Karnataka
   India
   Email: shraddha@juniper.net

   Chris Bowers
   Juniper Networks
   1133 Innovation Way
   Sunnyvale, California 94089
   United States of America
   Email: cbower@juniper.net

   Les Ginsberg
   Cisco Systems
   821 Alder Drive
   Milpitas, CA 95035
   United States of America
   Email: ginsberg@cisco.com

Kaneriya, et al.         Expires 5 January 2023                 [Page 7]