RFC 6822
IS-IS Multi-Instance
RFC 6822: IS-IS Multi-Instance 🎀
okay bestie, RFC 6822 is giving routing protocol glow-up energy 🦋 It was published by the IETF in December 2012 as a Standards Track document, which means it's an official Internet Standard, not just a vibe. The editor is S. Previdi (Ed.), and the other authors are L. Ginsberg, M. Shand, A. Roy, and D. Ward. Everyone on the author list is from Cisco Systems 💼 The ISSN is 2070-1721. The title block has no Obsoletes or Updates line, so this RFC doesn't list anything it replaces or amends 🌸
Abstract
okay so the abstract is the TL;DR 💅 It says this doc describes a way for one router to share one or more circuits among multiple IS-IS routing protocol instances. Each instance gets its own resources, so they're isolated from each other ✨ Routers form instance-specific adjacencies (basically, instance-specific neighbour relationships), and each instance can support multiple topologies. Every topology has its own unique Link State Database (LSDB) 🧚 Every Protocol Data Unit (PDU) carries a brand-new Type-Length-Value (TLV) that says which instance and which topology (or topologies) it belongs to. iconic, honestly 👑
Status of This Memo
this section is the official paperwork 📜 It's an Internet Standards Track document. It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 🎀 For more on Internet Standards, check Section 2 of RFC 5741.
info about the current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc6822 🔗
Copyright Notice
more legal-ish stuff, but it matters 🫶 The copyright belongs to the IETF Trust and the document authors, Copyright (c) 2012, with all rights reserved.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date of publication. Please read those carefully, bestie, because they spell out your rights and restrictions. Any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 💜
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get an adequate license from whoever controls that copyright, this document may not be modified outside the IETF Standards Process, and derivative works may not be created outside it. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌈
Table of Contents
here's the full map so you can find your way around 🗺️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Elements Of Procedure . . . . . . . . . . . . . . . . . . . . 4
2.1. Instance Identifier TLV . . . . . . . . . . . . . . . . . 5
2.2. Instance Membership . . . . . . . . . . . . . . . . . . . 6
2.3. Use of Authentication . . . . . . . . . . . . . . . . . . 6
2.4. Adjacency Establishment . . . . . . . . . . . . . . . . . 6
2.4.1. Point-to-Point Adjacencies . . . . . . . . . . . . . . 7
2.4.2. Multi-Access Adjacencies . . . . . . . . . . . . . . . 7
2.5. Update Process Operation . . . . . . . . . . . . . . . . . 7
2.5.1. Update Process Operation on Point-to-Point Circuits . 7
2.5.2. Update Process Operation on Broadcast Circuits . . . . 7
2.6. Interoperability Considerations . . . . . . . . . . . . . 8
2.6.1. Interoperability Issues on Broadcast Circuits . . . . 8
2.6.2. Interoperability Using Point-to-Point Circuits . . . . 9
3. Usage Guidelines . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. One-to-One Mapping between Topologies and Instances . . . 10
3.2. Many-to-One Mapping between Topologies and Instances . . . 10
3.3. Considerations for the Number of Instances . . . . . . . . 11
4. Relationship to M-ISIS . . . . . . . . . . . . . . . . . . . . 11
5. Graceful Restart Interactions . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 141. Introduction 🌸
so here's the problem: the protocol in [ISO10589] has an existing limitation where only one instance of the protocol can run on a given circuit 😭 This doc defines an extension to IS-IS that removes that restriction. The extension is called "Multi-Instance IS-IS" (MI-IS-IS) 💖
Routers that support this extension are called "Multi-Instance-capable routers" (MI-RTR) ✨
using multiple instances gives you better isolation of the resources tied to each instance, both inside a router and across the network 🧚 Instance-specific prioritization for handling PDUs and doing routing calculations inside a router may be specified. Instance-specific flooding parameters may also be defined, so different instances can use network-wide resources at different rates 🍓
Another limitation is that a given instance runs a single Update Process on a single LSDB. This doc extends IS-IS so that non-zero instances can run multiple Update Processes. Each Update Process is tied to a topology and its own unique topology-specific LSDB. Non-zero instances are only supported by MI-RTRs. Legacy routers only support the standard, or zero, instance. And the standard instance is not changed in any way by the extensions in this document, so old routers stay happy 🫶
MI-IS-IS might be used for topology-specific routing. When it's used that way, it's an alternative to Multi-Topology IS-IS [RFC5120] 💅
MI-IS-IS might also be used to advertise information on behalf of applications [RFC6823]. That means info that isn't directly about how IS-IS works can be advertised in a way that keeps its impact on routing small 🎀
Those are just examples of how MI-IS-IS might be used. Specifying the uses of MI-IS-IS is outside the scope of this document 🙈
1.1. Requirements Language
the BCP 14 key words are the capital-letter rules that tell you how strict something is, so here they are, spelled out exactly as the doc has them: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL". In this document they're interpreted as described in RFC 2119 [RFC2119] 🔥
2. Elements Of Procedure 🦋
okay this is the core of it. An Instance Identifier (IID) is introduced to uniquely identify an IS-IS instance 🌈 The protocol extension includes a new TLV, the IID-TLV, in each IS-IS PDU originated by an MI-RTR, except as noted in this document. The IID-TLV identifies the unique instance and the topology/topologies the PDU applies to. Each IS-IS PDU is associated with only one IS-IS instance 💜
MI-RTRs form instance-specific adjacencies. The IID-TLV in IS-IS Hellos (IIH) includes the IID and the set of Instance-Specific Topology Identifiers (ITIDs) that the sending IS supports. When multiple instances share the same circuit, each instance has its own separate set of adjacencies 🌸
MI-RTRs support exchanging topology-specific Link State PDUs for the IID/ITID pairs that each neighbour supports. A unique IS-IS Update Process (see [ISO10589] operates for each IID/ITID pair. This MAY also imply IID/ITID-specific routing calculations and IID/ITID-specific routing and forwarding tables. However, this aspect is outside the scope of this specification 🧚
The mechanisms used to separate IS-IS instances and topology-specific Update Processes inside a router are also outside the scope of this specification 🙈
2.1. Instance Identifier TLV
a new TLV is defined to convey the IID and the ITIDs supported ✨ The IID-TLV links a PDU to an IS-IS instance using a unique 16-bit number. The IID-TLV is carried in all IS-IS PDUs associated with a non-zero instance, which includes IIHs, Sequence Number PDUs (SNPs), and Link State PDUs (LSPs) 🍓
Multiple instances of IS-IS can coexist on the same circuit and on the same physical router. IIDs MUST be unique within the same routing domain 💖
IID #0 is reserved for the standard instance supported by legacy systems. IS-IS PDUs associated with the standard instance MUST NOT include an IID-TLV, except where noted in this document 👑
The IID-TLV MAY include one or more ITIDs. An ITID is a 16-bit identifier where all values (0 - 65535) are valid 🎀
here's the format for the IID-TLV, bestie 💅
Type: 7
Length: 2 - 254
Value:
No. of octets
+-------------------------+
| IID (0 - 65535) | 2
+-------------------------+
| Supported ITID | 2
+-------------------------+
: :
+-------------------------+
| Supported ITID | 2
+-------------------------+When the IID = 0, the list of supported ITIDs MUST NOT be present 😭
An IID-TLV with IID = 0 MUST NOT appear in an SNP or LSP. When the TLV appears (with a non-zero IID) in an SNP or LSP, exactly one ITID MUST be present, indicating the topology the PDU is associated with. If no ITIDs or multiple ITIDs are present, or the IID is zero, then the PDU MUST be ignored 💀
When the IID is non-zero and the TLV appears in an IIH, the set of ITIDs supported on the circuit the IIH is sent over is included. There MUST be at least one ITID present 🌈
Multiple IID-TLVs MAY appear in IIHs. If multiple IID-TLVs are present and the IID value isn't the same across all of them, then the PDU MUST be ignored 🙈
A single IID-TLV can advertise up to 126 ITIDs. If multiple IID-TLVs are present in an IIH PDU, the supported set of ITIDs is the union of all the ITIDs in all the IID-TLVs 🧚
When an LSP purge is initiated, the IID-TLV MUST be retained, but the rest of the LSP body SHOULD be removed. The purge procedure is described in [RFC6233] and [RFC6232] 🫶
A PDU without an IID-TLV belongs to the standard instance 🍓
2.2. Instance Membership
each MI-RTR is configured to participate in one or more IS-IS instances. For each non-zero instance it participates in, an MI-RTR marks the IS-IS PDUs it generates for that instance (IIHs, LSPs, or SNPs) by including the IID-TLV with the appropriate instance identifier ✨
that's part 1 done, bestie 🎀 more of RFC 6822 is coming in part 2 💖
2.3. Use of Authentication 🔐
okay so when authentication is in use, the IID (if one is present) gets used first to pick out which authentication configuration applies 🎀. then the authentication check just runs as normal. when multiple ITIDs are supported, ITID-specific authentication MAY be used in SNPs and LSPs ✨
2.4. Adjacency Establishment 🤝
so to set up adjacencies, IS-IS routers swap IIH PDUs 💌. there are two kinds in IS-IS: point-to-point and broadcast. the subsections below list the extra rules an MI-RTR MUST follow when it's establishing adjacencies 💅
2.4.1. Point-to-Point Adjacencies
MI-RTRs put the IID-TLV in the point-to-point Hello PDUs they originate 📨. when an MI-RTR gets an IIH, it checks the IID-TLV it received. if that IID matches any IID the router supports on that circuit, the normal adjacency establishment procedures kick in and set up an instance-specific adjacency 🦋. also, no IID TLV at all means IID #0 🙈. for instances other than IID #0, an adjacency SHOULD NOT be established unless there is at least one ITID in common 🫣
this extension lets an MI-RTR set up multiple adjacencies with the same physical neighbor over one point-to-point circuit 👯. but because the instances are logically independent, the usual expectation of at most one neighbor on a given point-to-point circuit still holds 💜
2.4.2. Multi-Access Adjacencies
Multi-Access (broadcast) circuits work differently from point-to-point. PDUs sent by one router are visible to all routers, and all routers have to agree on the election of a Designated Intermediate System (DIS), no matter which ITIDs each one supports 🗳️
MI-RTRs set up adjacencies and elect a DIS per IS-IS instance 🌸. each MI-RTR only forms adjacencies with routers that advertise support for the instances the local router has been configured to support on that circuit. an MI-RTR isn't required to support every possible instance on a LAN, so it's possible to elect a different DIS for different instances 🧚
2.5. Update Process Operation 🔄
for non-zero instances, a unique Update Process exists for each supported ITID 🌈
2.5.1. Update Process Operation on Point-to-Point Circuits
On Point-to-Point circuits (including Point-to-Point Operation over LAN [RFC5309]), the ITID-specific Update Process only operates on that circuit, and only for those ITIDs that both ISs on the circuit support 🫶
2.5.2. Update Process Operation on Broadcast Circuits
On broadcast circuits, a single DIS is elected for each supported IID, no matter which ITIDs are advertised in LAN IIHs 👑. this requires the DIS to generate pseudo-node LSPs for all supported ITIDs, and the Update Process for all supported ITIDs has to operate on the broadcast circuit. among MI-RTRs on a broadcast circuit, if the set of supported ITIDs for a given non-zero IID is inconsistent, connectivity for the topology (or topologies) tied to the ITIDs that some MI-RTRs don't support can be compromised 😭
2.6. Interoperability Considerations 🧸
[ISO10589] requires that any TLV that isn't understood is silently ignored, without compromising the processing of the whole IS-IS PDU (IIH, LSP, SNP) 💅
to a router that doesn't implement this extension, every IS-IS PDU it receives will look like it belongs to the standard instance, regardless of whether an IID TLV is present 🙃. this can cause interoperability issues unless the mechanisms and procedures discussed below are followed 😬
2.6.1. Interoperability Issues on Broadcast Circuits
So routers can interoperate correctly with routers that don't implement this extension, and so nothing gets disrupted, a specific and dedicated Media Access Control (MAC) address is used for multicasting IS-IS PDUs with any non-zero IID 🛡️. each level will use its own specific layer 2 multicast address. that address lets MI-RTRs swap IS-IS PDUs with non-zero IIDs without legacy routers processing them, so no disruption is caused ✨
An MI-RTR will use the AllL1IS or AllL2IS ISIS MAC-layer address (as defined in [ISO10589]) as the destination address when sending an IS-IS PDU for the standard instance. An MI-RTR will use one of two new dedicated layer 2 multicast addresses (AllL1MI-ISs or AllL2MI-ISs) as the destination address when sending an IS-IS PDU for any non-zero IID. These addresses are specified in Section 6. If operating in point-to-point mode on a broadcast circuit [RFC5309], an MI-RTR MUST use one of the two new multicast addresses as the destination address when sending point-to-point IIHs associated with a non-zero instance. (Either address will do.)
MI-RTRs MUST discard IS-IS PDUs received if either of the following is true:
- The destination multicast address is
AllL1ISorAllL2ISand the PDU contains an IID-TLV. - The destination multicast address is one of the two new addresses, and the PDU contains an IID-TLV with a zero value for the IID or has no IID-TLV.
NOTE: If the multicast addressesAllL1ISand/orAllL2ISare improperly used to send IS-IS PDUs for non-zero IIDs, legacy systems will interpret these PDUs as being associated with IID #0. This will cause inconsistencies in the LSDB in those routers, may incorrectly maintain adjacencies, and may lead to inconsistent DIS election. 🙀
2.6.2. Interoperability Using Point-to-Point Circuits
For an MI-RTR to interoperate over a point-to-point circuit with a router that does not support this extension, the MI-RTR MUST NOT send IS-IS PDUs for instances other than IID #0 over the point-to-point circuit, since these PDUs may affect the state of IID #0 in the neighbor 🚫.
The presence or absence of the IID-TLV in an IIH indicates whether the neighbor does or doesn't support this extension 🔍. so all IIHs sent on a point-to-point circuit by an MI-RTR MUST include an IID-TLV. this includes IIHs associated with IID #0 💖. once it's determined that the neighbor doesn't support this extension, an MI-RTR MUST NOT send PDUs (including IIHs) for instances other than IID #0 🙅♀️
until an IIH is received from a neighbor, an MI-RTR MAY send IIHs for a non-zero instance 🤞. however, once an IIH with no IID TLV has been received (meaning the neighbor is not an MI-RTR), the MI-RTR MUST NOT send IIHs for a non-zero instance 🛑. that temporary relaxation of the restriction on sending IIHs for non-zero instances lets a non-zero instance adjacency be established on an interface where the MI-RTR does not support the standard instance 🎀.
Point-to-point adjacency setup MUST be done through the three-way handshaking procedure defined in [RFC5303], to stop a non-MI capable neighbor from bringing up an adjacency prematurely just because it received an IIH with an IID-TLV for a non-zero instance 🫢
3. Usage Guidelines ✨
As discussed above, MI-IS-IS extends IS-IS to support multiple instances on a given circuit 💫. each instance is uniquely identified by its IID and forms instance-specific adjacencies. each instance supports one or more topologies, represented by ITIDs. all topologies associated with a given instance share the instance-specific adjacencies. the set of topologies supported by a given IID MAY differ from circuit to circuit 🌍. each topology has its own set of LSPs and runs a topology-specific Update Process. flooding of topology-specific LSPs is only performed on circuits where both the local router and the neighbor(s) support a given topology (i.e., they advertise the same ITID in the set of supported ITIDs sent in the IID-TLV included in IIHs) 🧠
the following subsections give some guidelines for using instances and topologies within each instance 📚. while this represents examples based on the intent of the authors, implementors are not constrained by the examples 🤍
3.1. One-to-One Mapping between Topologies and Instances
When the set of information to be flooded in LSPs is intended to be flooded to all MI-RTRs supporting a given IID, a single topology MAY be used 🦋. the information contained in the single LSDB MAY still contain information associated with multiple applications, as the GENINFO TLV for each application has an application-specific ID that identifies the application to which the TLV applies [RFC6823] 💅
3.2. Many-to-One Mapping between Topologies and Instances
When the set of information to be flooded in LSPs includes subsets that are of interest to a subset of the MI-RTRs supporting a given IID, support of multiple ITIDs allows each subset to be flooded only to those MI-RTRs that are interested in that subset 🎯. in the simplest case, a one-to-one mapping between a given application and an ITID allows the information associated with that application to be flooded only to MI-RTRs that support that application. but a many-to-one mapping between applications and a given ITID is also possible 💜. when the set of application-specific information is large, the use of multiple ITIDs provides significantly greater efficiencies, as MI-RTRs only need to maintain the LSDB for applications of interest, and that information only needs to be flooded over a topology defined by the MI-RTRs who support a given ITID 🚀
the use of multiple ITIDs also allows the dedication of a full LSP set (256 LSPs at each level) for the use of a given (set of) applications, thereby minimizing the possibility of exceeding the carrying capacity of an LSP set 📦. such a possibility might arise if information for all applications were to be included in a single LSP set 😵
Note that 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. 🔗
3.3. Considerations for the Number of Instances
The support of multiple topologies within the context of a single instance provides better scalability in support of multiple applications, both in terms of the number of adjacencies that are required and in the flooding of topology-specific LSDB 📈. in many cases, a single non-zero instance would be sufficient and optimal ✨. however, in cases where the set of topologies desired in support of a set of applications is largely disjoint from the set of topologies desired in support of a second set of applications, it could make sense to use multiple instances 🌈
4. Relationship to M-ISIS ✨
okay so [RFC5120] is the one that brings multi-topology routing to the party 💅 In that document, 12-bit Multi-Topology Identifiers (MTIDs) identify the topologies that an IS-IS instance (a "standard instance" as defined by this document) supports. no cap, the Multi-topology IDs from [RFC5120] and the ITIDs from this document have zero relationship 🙈
If an MI-RTR uses the extensions for the BFD-Enabled TLV [RFC6213], the ITID SHOULD be used in place of the MTID. Then all 16 bits of the identifier field are usable 🔥
An MI-RTR MAY use the extensions defined in this document to support multiple topologies in the context of an instance with a non-zero IID. Each MI topology gets its own unique LSDB, identified by an ITID 🦋 An ITID-specific IS-IS Update Process runs on each topology. This is very different from [RFC5120], where one LSDB and one IS-IS Update Process handle all the topologies 👑
An MI-RTR MUST NOT support [RFC5120] multi-topology within a non-zero instance. The following TLVs MUST NOT be sent in an LSP associated with a non-zero instance, and MUST be ignored when received 💀
TLV 222 - MT IS Neighbors
TLV 235 - MT IP Reachability
TLV 237 - MT IPv6 Reachability5. Graceful Restart Interactions 🔄
okay bestie, [RFC5306] defines the protocol extensions for graceful restart of a routing instance ✨ Those extensions apply to MI-RTRs too, with one big addition. Since there are topology-specific LSP databases, all of them have to be synchronized after a restart before database synchronization is complete 😭 That means using some extra T2 timers. See [RFC5306] for further details 🫶
6. IANA Considerations 🌸
Per this document, IANA has registered a new IS-IS TLV, which shows up in the "IS-IS TLV Codepoints" registry 🎀
Type Description IIH LSP SNP Purge
---- --------------------- --- --- --- -----
7 Instance Identifier y y y yAlso per this document, IANA has registered two EUI-48 multicast addresses from the IANA-managed EUI address space, as specified in [RFC5342]. They're these two:
01-00-5E-90-00-02 AllL1MI-ISs
01-00-5E-90-00-03 AllL2MI-ISs7. Security Considerations 💀🔐
okay, this part is SERIOUS, so pay attention 🥺 Security concerns for IS-IS are addressed in [ISO10589], [RFC5304], and [RFC5310]. Please go read all three, because your network's safety depends on it 😭🔥
8. Acknowledgements 🫶
The authors would like to thank Dino Farinacci and Tony Li for their contributions. Iconic behavior, honestly 👑
9. References 📚
9.1. Normative References
[ISO10589] International Organization for Standardization,
"Intermediate system to Intermediate system intra-domain
routeing information exchange protocol for use in
conjunction with the protocol for providing the
connectionless-mode Network Service (ISO 8473)", ISO/
IEC 10589:2002, Second Edition, Nov. 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
[RFC5303] Katz, D., Saluja, R., and D. Eastlake, "Three-Way
Handshake for IS-IS Point-to-Point Adjacencies",
RFC 5303, October 2008.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, October 2008.
[RFC5306] Shand, M. and L. Ginsberg, "Restart Signaling for IS-IS",
RFC 5306, October 2008.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, February 2009.
[RFC6213] Hopps, C. and L. Ginsberg, "IS-IS BFD-Enabled TLV",
RFC 6213, April 2011.
[RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge
Originator Identification TLV for IS-IS", RFC 6232,
May 2011.
[RFC6233] Li, T. and L. Ginsberg, "IS-IS Registry Extension for
Purges", RFC 6233, May 2011.
[RFC6823] Ginsberg, L., Previdi, S., and M. Shand, "Advertising
Generic Information in IS-IS", RFC 6823, December 2012.9.2. Informative References
[RFC5309] Shen, N. and A. Zinin, "Point-to-Point Operation over LAN
in Link State Routing Protocols", RFC 5309, October 2008.
[RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol
Usage for IEEE 802 Parameters", BCP 141, RFC 5342,
September 2008.Authors' Addresses 🎀
Stefano Previdi (editor)
Cisco Systems
Via Del Serafico 200
Rome 0144
Italy
EMail: sprevidi@cisco.com
Les Ginsberg
Cisco Systems
510 McCarthy Blvd.
Milpitas, CA 95035
USA
EMail: ginsberg@cisco.com
Mike Shand
EMail: imc.shand@gmail.com
Abhay Roy
Cisco Systems
170 W. Tasman Dr.
San Jose, CA 95134
USA
EMail: akr@cisco.com
Dave Ward
Cisco Systems
3700 Cisco Way
San Jose, CA 95134
USA
EMail: wardd@cisco.com📦 where this page comes from
- ietf: rfc6822 2012-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms