rfc-5311

Simplified Extension of Link State PDU (LSP) Space for IS-IS

D. McPherson (Editor), L. Ginsberg, S. Previdi, M. Shand
date2009-02 streamIETF areartg wgisis statusPROPOSED STANDARD pages12 canonicalhttps://www.rfc-editor.org/rfc/rfc5311 doi10.17487/RFC5311
This document describes a simplified method for extending the Link State PDU (LSP) space beyond the 256 LSP limit. This method is intended as a preferred replacement for the method defined in RFC 3786. [STANDARDS-TRACK]

obsoletes

Extracted elements (23)

design-rationale §6.5

Leaf information should be restricted to normal LSP sets when possible, because advertising leaf info in Extended LSPs increases the frequency of forwarding plane update events across the network.

routing

design-rationale §4.5

New TLVs 23 and 223 are introduced because restrictions prevent TLV 22 and 222 from appearing in Extended LSPs (except for the Originating System neighbor). Without these new TLVs, TE sub-TLV information for the Originating System's neighbors could not be advertised in Extended LSPs.

routing

design-rationale §5

RFC 5311 replaces RFC 3786 by restricting Extended LSP content to information that does NOT impact Shortest Path Tree (SPT) computation. This allows legacy IS-IS systems to treat Extended LSPs as belonging to a virtual IS reachable only via the Originating System, making SPF results consistent between legacy and extension-capable systems without requiring two operating modes.

routing

design-rationale §5

Using additional system-ids for Extended LSPs (rather than RFC 3786's approach) eliminates the need for two operating modes and special Logical LSP handling during SPF, because legacy systems naturally treat Virtual ISs as leaf nodes reachable only via the Originating System.

routing

interoperability-note §6.1

Implementations being revised to support new protocol extensions that define TLVs/sub-TLVs advertisable in Extended LSPs SHOULD also be revised to support these extensions (RFC 5311) so they can process new information whether it appears in normal or Extended LSPs.

routing

interoperability-note §5

Legacy IS-IS implementations not supporting these extensions see Extended LSPs as belonging to a virtual system reachable only via the Originating System, so their SPF results remain consistent with extension-capable ISs. No special interoperability mode is needed, unlike RFC 3786.

routing

normative-requirement §4 MUST

Additional system-ids MUST be unique within the Level-1 area when used at Level-1, and MUST be unique within the domain when used at Level-2, subject to the same uniqueness restrictions as normal system-ids.

routing

normative-requirement §4 MUST NOT

If the Extended LSP with LSP number zero and remaining lifetime > 0 is not present for a particular additional system-id, then none of the Extended LSPs in that Extended LSP set shall be processed.

routing

normative-requirement §6.3 MUST

If the Originating System sets the OL bit in a normal LSP, Extension-capable ISs MUST also treat the Virtual ISs as unreachable, consistent with legacy behavior, to avoid potential routing loops when leaf information is in Extended LSPs.

routing

normative-requirement §4.2.3 MUST

IS Neighbor Reachability advertisements in Extended LSPs are restricted to the Originating System only. A neighbor to the Originating System MUST be advertised, MUST use a non-zero metric, and SHOULD use MaxLinkMetric-1. For multi-topology, an MT IS Neighbor advertisement MUST be included for every topology advertised.

routing

normative-requirement §4.2.4 MUST

LSP number zero of an Extended LSP set MUST include an Area Address TLV. The set of area addresses advertised MUST be a subset of those in the normal LSP number zero at the same level, and SHOULD be syntactically identical.

routing

normative-requirement §4.2.1 MUST NOT

The following TLVs MUST NOT appear in an Extended LSP: ES Neighbors (3), Part. DIS (4), and Prefix Neighbors (5). If received, an Extension-Capable IS MUST ignore those TLVs and SHOULD report an error; other TLVs in the set MUST be processed normally.

routing

normative-requirement §4.3 MUST

The Original LSP set MUST include a neighbor (with metric zero) to the Virtual IS associated with each Extended LSP set generated. This guarantees two-way connectivity check success and that cost to reach the Virtual IS equals cost to reach the Originating System.

routing

normative-requirement §4.2.5 MUST

The Overload (OL), Attached (ATT), and Partition Repair (P) bits MUST be set to 0 in all Extended LSPs. Setting ATT would incorrectly indicate the Virtual IS is attached to other areas, potentially causing legacy systems to use it as a default exit point.

routing

normative-requirement §4.5 MUST NOT

TLVs 23 and 223 MUST NOT be used to infer that a neighbor relationship exists in the absence of TLV 22 or TLV 222 in the Originating LSP set, to maintain compatibility with systems not supporting these extensions.

routing

normative-requirement §4.2.2 MUST

When leaf advertisements for multiple topologies are included in an Extended LSP set, the multi-topology TLV (229) MUST include all topologies for which a leaf advertisement is included.

routing

normative-requirement §6.4 MUST

When neighbor attribute information for the same context appears in both Original and Extended LSPs: non-conflicting info MUST be additive; conflicting info MUST prefer the Original LSP (or lowest system-id Extended LSP if absent); TLV 22/222 MUST override TLV 23/223 for the same neighbor.

routing

protocol-element §3

An 'Additional system-id' is a system-id other than the Normal system-id, assigned by the network administrator to allow generation of Extended LSPs. It must be unique within the Level-1 area or Level-2 domain, and Extended LSPs using it are treated by the Update Process identically to normal LSPs.

routing

protocol-element §4.5

IS Neighbor Attribute TLV (Type 23) is defined, identical in format to the extended IS reachability TLV (22), for advertising neighbor sub-TLV information (e.g., TE attributes) in Extended LSPs without violating restrictions on TLV 22 in Extended LSPs.

routing

protocol-element §4.5

MT IS Neighbor Attribute TLV (Type 223) is defined, identical in format to the MT-ISN TLV (222), for advertising MT neighbor attribute information in Extended LSPs. Both TLVs 23 and 223 MAY appear in Original or Extended LSPs.

routing

registry §8

This document registers three new IS-IS TLV codepoints in the ISIS TLV Codepoints Registry: Type 23 (IS Neighbor Attribute, LSP only), Type 24 (IS Alias ID, LSP only), and Type 223 (MT IS Neighbor Attribute, LSP only). None appear in IIH or SNP.

routing, registry

security-consideration §7

This document raises no new security issues for IS-IS. General security considerations for IS-IS are addressed in RFC 5304 (IS-IS Cryptographic Authentication).

security, routing

wire-format §4.4

IS Alias ID TLV (Type 24): value field contains a 6-octet Normal System-id of the Originating System, followed by a 1-octet Sub-TLV length, followed by optional Sub-TLVs (0 to 248 octets). Total value length is 7 to 255 octets.

routing