IS-IS Multi-Instance
obsoleted by
- rfc-8202 — IS-IS Multi-Instance
Extracted elements (26)
Dedicated MAC multicast addresses are required for non-zero IID PDUs on broadcast circuits because ISO 10589 requires legacy routers to silently ignore unknown TLVs, causing them to misinterpret MI-IS-IS PDUs as belonging to IID #0, which would corrupt LSDBs and DIS elections.
Multiple IS-IS instances isolate resources (adjacencies, LSDBs, flooding) and enable instance-specific prioritization and flooding rate control. MI-IS-IS serves as an alternative to Multi-Topology IS-IS (RFC 5120) and enables advertisement of non-routing application information with minimal impact on routing.
Supporting multiple topologies (ITIDs) within a single non-zero instance is preferred over multiple instances in most cases, as it reduces the number of adjacencies required. Multiple instances are only warranted when the desired topology sets for different application groups are largely disjoint.
Graceful restart (RFC 5306) applies to MI-RTRs with the additional requirement that all topology-specific LSP databases must be synchronized following restart, requiring additional T2 timers per topology to ensure database synchronization is complete.
On broadcast circuits, MI-RTRs MUST use dedicated multicast MAC addresses — AllL1MI-ISs (01-00-5E-90-00-02) and AllL2MI-ISs (01-00-5E-90-00-03) — for all non-zero IID PDUs, so legacy routers do not process them and cause disruption.
There is no relationship between Multi-Topology Identifiers (MTIDs) from RFC 5120 and the ITIDs defined in this document. MI-IS-IS runs a separate Update Process and LSDB per ITID, unlike M-ISIS which uses a single LSDB for all topologies within a standard instance.
All IIHs sent on a point-to-point circuit by an MI-RTR MUST include an IID-TLV, including those for IID #0. Once a neighbor is determined to not support MI-IS-IS (IIH received with no IID-TLV), an MI-RTR MUST NOT send PDUs for instances other than IID #0.
An MI-RTR MUST NOT support RFC 5120 multi-topology within a non-zero instance. TLVs 222 (MT IS Neighbors), 235 (MT IP Reachability), and 237 (MT IPv6 Reachability) MUST NOT be sent in LSPs associated with a non-zero instance and MUST be ignored when received.
For non-zero instances on a point-to-point circuit, an adjacency SHOULD NOT be established unless there is at least one ITID in common between the two IS-IS neighbors.
IIDs MUST be unique within the same IS-IS routing domain.
IS-IS PDUs associated with the standard instance MUST NOT include an IID-TLV except where noted in the document. An IID-TLV with IID = 0 MUST NOT appear in an SNP or LSP.
MI-RTRs MUST discard IS-IS PDUs if: the destination is AllL1IS or AllL2IS and the PDU contains an IID-TLV; or the destination is one of the new MI-IS-IS multicast addresses but the PDU has a zero IID or no IID-TLV.
MI-RTRs MUST use AllL1MI-ISs or AllL2MI-ISs as the destination MAC address when sending IS-IS PDUs for any non-zero IID on broadcast circuits, including when operating in point-to-point mode over LAN (RFC 5309).
Point-to-point adjacency setup MUST use the three-way handshaking procedure defined in RFC 5303 to prevent a non-MI-capable neighbor from prematurely establishing an adjacency based on reception of an IIH with a non-zero IID-TLV.
The topology associated with each ITID MUST be fully connected in order for ITID-specific LSPs to be successfully flooded to all MI-RTRs that support that ITID.
When an IID-TLV with non-zero IID appears in an SNP or LSP, exactly one ITID MUST be present indicating the associated topology. If no ITIDs or multiple ITIDs are present, or the IID is zero, the PDU MUST be ignored.
When an LSP purge is initiated, the IID-TLV MUST be retained but the remainder of the LSP body SHOULD be removed, following the purge procedures in RFC 6232 and RFC 6233.
When authentication is in use, the IID (if present) is first used to select the applicable authentication configuration; the authentication check is then performed as normal. ITID-specific authentication MAY be used in SNPs and LSPs when multiple ITIDs are supported.
When IID is non-zero and the IID-TLV appears in an IIH, there MUST be at least one ITID present. If multiple IID-TLVs appear in an IIH and the IID values differ across TLVs, the PDU MUST be ignored.
An Instance Identifier (IID) is a 16-bit number uniquely identifying an IS-IS instance within a routing domain. IID #0 is reserved for the standard legacy instance. Non-zero IIDs are only used by Multi-Instance-capable routers (MI-RTRs).
For non-zero instances, a unique IS-IS Update Process exists for each supported ITID with a corresponding topology-specific LSDB. On broadcast circuits, the DIS generates pseudo-node LSPs for all supported ITIDs.
On broadcast (multi-access) circuits, MI-RTRs establish adjacencies and elect a DIS per IS-IS instance. Different IS-IS instances may elect different DIS routers on the same LAN, since each MI-RTR only forms adjacencies with routers that advertise support for the configured instances.
IANA registered IS-IS TLV Type 7 (Instance Identifier) in the IS-IS TLV Codepoints registry, valid for use in IIH, LSP, SNP, and Purge PDUs.
IANA registered two EUI-48 multicast addresses from the IANA-managed EUI address space: AllL1MI-ISs (01-00-5E-90-00-02) and AllL2MI-ISs (01-00-5E-90-00-03) for use with non-zero IS-IS instances on broadcast circuits.
Security concerns for IS-IS Multi-Instance are addressed by existing IS-IS security mechanisms defined in ISO 10589, RFC 5304 (IS-IS Cryptographic Authentication), and RFC 5310 (IS-IS Generic Cryptographic Authentication). The IID is used to select per-instance authentication configuration.
The IID-TLV (Type 7, Length 2–254) carries a 2-octet IID field (0–65535) followed by zero or more 2-octet Supported ITID fields. It is included in all IS-IS PDUs (IIH, LSP, SNP) associated with a non-zero instance.