Multi-part TLVs in IS-IS
Juniper Networks
Elnath-Exora Business Park Survey
Bangalore
Karnataka
560103
India
pkaneria@juniper.net
Juniper Networks
1133 Innovation Way
Sunnyvale
California
94089
USA
tony.li@tony.li
Juniper Networks
1133 Innovation Way
Sunnyvale
California
94089
USA
prz@juniper.net
Juniper Networks
Elnath-Exora Business Park Survey
Bangalore
Karnataka
560103
India
shraddha@juniper.net
Juniper Networks
1133 Innovation Way
Sunnyvale
California
94089
USA
cbower@juniper.net
Cisco Systems
821 Alder Drive
Milpitas
95035
CA
USA
ginsberg@cisco.com
Routing Area
LSR Working Group
ISIS
Draft
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.
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
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)
GMPLS-SRLG (Type 138)
IPv6 SRLG (Type 139)
Application-Specific SRLG (Type 238)
Application-Specific Link Attributes (sub-TLV Type 16)
Today, for example, the Extended IS Reachability TLV (22)
and MT Intermediate Systems TLV (222)
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.
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.
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
when, and only when, they appear in all capitals, as shown here.
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).
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.
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
IPv6 interface address and IPv6 neighbor address
as specified in
Link Local/Remote Identifiers
as specified in
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.
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.
As another example, consider the Extended IP Reachability TLV
(type 135) . 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.
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.
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.
This document makes no requests of IANA.
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 , , and .
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)
IANA