Internet DRAFT - draft-pkaneria-lsr-multi-tlv
draft-pkaneria-lsr-multi-tlv
LSR Working Group P. Kaneriya
Internet-Draft Tony. Li
Intended status: Standards Track Antoni. Przygienda
Expires: 3 June 2023 S. Hegde
C. Bowers
Juniper Networks
L. Ginsberg
Cisco Systems
30 November 2022
Multi-part TLVs in IS-IS
draft-pkaneria-lsr-multi-tlv-02
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.
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 3 June 2023.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
Kaneriya, et al. Expires 3 June 2023 [Page 1]
Internet-Draft Multi-part TLVs November 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 . . . . . . . . . . . . . . . . . . . . . . . 4
4. Procedure for Advertising Multi-part TLVs . . . . . . . . . . 4
4.1. Example: Extended IS Reachability . . . . . . . . . . . . 4
4.2. Example: Extended IP Reachability . . . . . . . . . . . . 5
5. Procedure for Receiving Multi-part TLVs . . . . . . . . . . . 5
6. Deployment Considerations . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
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]
Kaneriya, et al. Expires 3 June 2023 [Page 2]
Internet-Draft Multi-part TLVs November 2022
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.
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.
Kaneriya, et al. Expires 3 June 2023 [Page 3]
Internet-Draft Multi-part TLVs November 2022
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.
4.1. Example: Extended IS Reachability
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
* Optionally one or more of the following identifiers:
- IPv4 interface address and IPv4 neighbor address as specified
in [RFC5305]
- IPv6 interface address and IPv6 neighbor address as specified
in [RFC6119]
- Link Local/Remote Identifiers as specified in [RFC5307]
This acts as the key for this entry. Note that the link identifiers
are encoded as sub-TLVs and MAY appear in any order. It is
RECOMMENDED that the link identifiers be the first sub-TLVs. Note
that it is valid to advertise no link identifiers, but in the
presence of parallel adjacencies to the same neighbor it will not be
possible to associate the advertisement with a specific link.
Kaneriya, et al. Expires 3 June 2023 [Page 4]
Internet-Draft Multi-part TLVs November 2022
If the remaining space in the TLV is insufficient to advertise all
other sub-TLVs, then the node MAY advertise additional Extended IS
Reachability TLVs. The key information MUST be replicated
identically.
4.2. Example: Extended IP Reachability
As another example, consider the Extended IP Reachability TLV (type
135) [RFC5305]. A prefix in this TLV is specified by:
* 4 octets of metric information
* 1 octet of control information which includes 6 bits specifying
the prefix length
* 0-4 octets of IPv4 prefix
followed by up to 250 octets of sub-TLV information.
The key consists of the 6 bits of prefix length and the 0-4 octets of
IPv4 prefix.
If this is insufficient sub-TLV space, then the node MAY advertise
additional instances of the Extended IP Reachability TLV. The key
information MUST be replicated identically. The complete information
for a given key in such cases is the joined set of all the carried
information under the key in all the TLV instances.
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.
Kaneriya, et al. Expires 3 June 2023 [Page 5]
Internet-Draft Multi-part TLVs November 2022
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.
7. IANA Considerations
This document makes no requests of IANA.
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. 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>.
Kaneriya, et al. Expires 3 June 2023 [Page 6]
Internet-Draft Multi-part TLVs November 2022
[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>.
Kaneriya, et al. Expires 3 June 2023 [Page 7]
Internet-Draft Multi-part TLVs November 2022
[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>.
Authors' Addresses
Parag Kaneriya
Juniper Networks
Elnath-Exora Business Park Survey
Bangalore 560103
Karnataka
India
Email: pkaneria@juniper.net
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
Kaneriya, et al. Expires 3 June 2023 [Page 8]
Internet-Draft Multi-part TLVs November 2022
Les Ginsberg
Cisco Systems
821 Alder Drive
Milpitas, CA 95035
United States of America
Email: ginsberg@cisco.com
Kaneriya, et al. Expires 3 June 2023 [Page 9]
