RFC 5120

RFC 5120: M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs) 🦋

okay bestie, this one is from the Network Working Group and it's dated February 2008 🎀 It's on the Standards Track, so it's an actual Internet standard. The authors are T. Przygienda (Z2 Sagl), N. Shen (Cisco Systems), and N. Sheth (Juniper Networks) 👑 The title block doesn't list anything it obsoletes or updates, so it's standing on its own 💅

Status of This Memo ✨

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Abstract 🌸

okay so this doc describes an optional mechanism inside Intermediate System to Intermediate Systems (IS-ISs) that a lot of ISPs already use for IGP routing inside their clouds ☁️ It explains how to run a set of independent IP topologies, which we call Multi-Topologies (MTs), within one single IS-IS domain 🧚

The MT extension is seriously useful for a bunch of stuff. You can build an in-band management network "on top" of the original IGP topology 🔧 You can keep separate IGP routing domains for isolated multicast or IPv6 islands inside the backbone 🌈 Or you can force a subset of an address space to follow a different topology 💜 It's giving flexibility, periodt 💅

1. Introduction ✨

Maintaining multiple MTs for IS-IS [ISO10589] [RFC1195] in a backwards-compatible way takes several extensions to the packet encoding, plus some extra Shortest Path First (SPF) procedures 🧠 The problem splits into two parts: forming adjacencies, and advertising prefixes and reachable intermediate systems within each topology. Once all the extra info is in place, MT-capable SPF computation has to actually use it. The next sections cover each problem separately 🫶

To keep things simple, the "standard" IS-IS topology is defined as MT ID #0 (zero) 💖

1.1. Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 📖

1.2. Definitions of Terms Used in This Document

Here's the acronym cheat sheet 🌸

CSNP Complete Sequence Number Packet.  Used to describe all the
     contents of a link state database of IS-IS.

DIS  Designated Intermediate System.  The intermediate system elected
     to advertise the pseudo-node for a broadcast network.

IIH  IS-IS Hello.  Packets that are used to discover adjacent
     intermediate systems.

LSP  Link State Packet.  Packet generated by an intermediate system
     and lists adjacent systems, prefixes, and other information.

PSNP Partial Sequence Number Packet.  Used to request information
     from an adjacent intermediate system's link state database.

SPF  Shortest Path First.  An algorithm that takes a database of
     nodes within a domain and builds a tree of connectivity along
     the shortest paths through the entire network.

2. Maintaining MT Adjacencies 💅

Every adjacency that gets formed MUST be classified as belonging to a set of MTs on the interface 🎀 This happens by adding a new TLV into IIH packets, and that TLV advertises which topologies the interface belongs to 🦋 If MT #0 is the only MT on the interface, it is optional to advertise it in the new TLV. So not including the TLV in the IIH just means MT ID #0 capability only 🍓 Through this exchange of MT capabilities, a router can advertise the IS TLVs in LSPs with the common MT set over those adjacencies ✨

If an adjacency has multiple MTs on an interface, and the topologies have overlapping IP address space, then additional mechanisms MUST be used to figure out the topology identity of the incoming IP packets on the interface 😭 See further discussion in Section 8.2.2 of this document 🧚

2.1. Forming Adjacencies on Point-to-Point Interfaces

Adjacencies on point-to-point interfaces get formed as usual with IS-IS routers that don't implement MT extensions 🌈 If a local router doesn't participate in certain MTs, it won't advertise those MT IDs in its IIHs, so it won't include that neighbor within its LSPs 🙈 On the flip side, if an MT ID isn't detected in the remote side's IIHs, the local router MUST NOT include that neighbor within its LSPs ⚠️ The local router SHOULD NOT form an adjacency if they don't have at least one common MT over the interface 💀

2.2. Forming Adjacencies on Broadcast Interfaces

On a LAN, all the routers that implement the MT extension MAY advertise their MT capability TLV in their IIHs 💜 If there's at least one adjacency on the LAN interface that belongs to this MT, the MT capable router MUST include the corresponding MT IS Reachable TLV in its LSP. Otherwise it MAY include this MT IS Reachable TLV in its LSP, as long as the LAN interface participates in this MT set 🌸

Two routers on a LAN SHALL always establish adjacency, even if they don't have a common MT 🫶 This is so all the routers on the LAN can correctly elect the same DIS 👑 The IS SHOULD NOT include the MT IS TLV in its LSP if none of the adjacencies on the LAN contain this MT 🙅

The DIS, CSNP, and PSNP functions are not changed by the MT extension 🎀

3. Advertising MT Reachable Intermediate Systems in LSPs 🦋

A router MUST include within its LSPs, in the Reachable Intermediate Systems TLV, only the adjacent nodes that are participating in the corresponding topology 💅 It should only advertise those TLVs if it participates in that topology itself 🌈 The Standard Reachable Intermediate Systems TLV is acting as MT ID #0 here, which makes it the equivalent of the newly introduced MT Reachable Intermediate Systems TLV ✨ A router MUST announce the MT IS TLV when there's at least one adjacency on the interface that belongs to this MT. Otherwise it MAY announce the MT IS TLV of an adjacency for a given MT, if this interface participates in the LAN 🧚

Here's the tricky bit 🙈 Since there's no way to stop a router that doesn't understand MT extensions from generating the pseudo-node, it isn't possible to add special TLVs to the pseudo-node LSPs or to run distinct DIS elections per MT 😭 So a pseudo-node LSP generated by the DIS MUST contain all the nodes on the LAN in its IS Reachable TLV, as usual, regardless of their MT capabilities 💖 In other words, the pseudo-node LSP construction doesn't change at all 🍓

4. MTs and Overload, Partition, and Attached Bits 🌈

For each of the MTs, a router could end up potentially partitioned, overloaded, and attached independently 🫠 To keep things from getting too complicated, MT extensions do not support MT based partition repair 🙅 The overload, partition, and attached bits in the LSP header only reflect the status of the default topology 🎀

The attached bit and overload bit are part of the MT TLV, which gets distributed within a node's LSP fragment zero 🦋 Since each adjacency can belong to different MTs, some MTs can be L2 attached while others aren't, all on the same router 👑 The overload bit in the MT TLV can be used to signal that a topology is overloaded. An MT-based system counts as overloaded if the overload bit in the MT is set 💜

Route leaking between the levels SHOULD only be performed within the same MT 🫶

5. Advertising MT Specific IP Prefixes 🧚

Each MT has its own address space, so a new TLV is needed for prefixes stored in MTs other than MT ID #0 🌸 To make the encoding less confusing when the same prefixes show up in multiple MTs, and to speed up SPF per MT, the spec doesn't add a sub-TLV in the Traffic Engineered (TE) extensions 🙌 Instead, it introduces a new TLV for that purpose, one that closely follows the TE encoding [RFC3784] ✨

6. MT SPF Computation 👑

Each MT MUST run its own instance of the decision process 🔥 The pseudo-node LSPs are used by all topologies during computation 🦋 Each non-default topology MAY have its attached bit and overload bit set in the MT TLV 💅 A reverse-connectivity check within SPF MUST follow the according MT, so bi-directional reachability is assured within the same MT 🫶

The results of each computation SHOULD be stored in a separate Routing Information Base (RIB) in normal cases 🎀 Otherwise, overlapping addresses in different topologies could lead to undesirable routing behavior, like forwarding loops 😭 The forwarding logic and configuration need to make sure the same MT is traversed from source to destination for packets 🧠 The nexthops derived from the MT SPF MUST belong to the adjacencies conforming to the same MT, for correct forwarding 💖 It is recommended for administrators to keep the configuration of all routers in the domain consistent, to prevent undesirable forwarding behavior 🌈

No attempt is made in this document to let one topology calculate routes using the routing information from another topology inside SPF. Even though it's possible to redistribute and leak routes from another IS-IS topology or from external sources, the exact mechanism is beyond the scope of this document 🙈

7. Packet Encoding 🍓

Four new TLVs are added to support MT extensions ✨ One of them is common to LSPs and IIHs 🦋 Encoding of the Intermediate System TLV and IPv4 Reachable Prefixes is tied to the traffic engineering extensions [RFC3784], to keep the implementation effort simple 🧚 The main reasons for using new TLVs instead of sub-TLVs inside the existing type-22 and type-135 TLVs are:

1. In many cases multi-topologies are non-congruent, so using the sub-TLV approach won't save LSP space 💀
2. Many sub-TLVs are already being used in type-22, and many more are being proposed, while the existing TLVs have a maximum limit on the TLV size 😭
3. If traffic engineering or some other application gets applied per topology level later, the new TLVs can automatically inherit the same attributes already defined for the "standard" topology. That means no going through the long standard process to redefine them per topology 👑

7. Packet Encoding ✨

7.1. Multi-Topology TLV

okay so the MT TLV is type 229, and it's basically the list of topologies your router is hanging out in 🦋 Here's the format:

• CODE - 229
• LENGTH - total length of the value field, it SHOULD be 2 times the number of MT components.
• VALUE - one or more 2-byte MT components, structured as follows:

                                                          No. of Octets
                      +--------------------------------+
                      |O |A |R |R |        MT ID       |      2
                      +--------------------------------+

Bit O is the OVERLOAD bit for the MT. It's only valid in LSP fragment zero for MTs other than ID #0. Otherwise it SHOULD be set to 0 on transmission and ignored on receipt 💅

Bit A is the ATTACH bit for the MT. Same deal: it's only valid in LSP fragment zero for MTs other than ID #0. Otherwise it SHOULD be set to 0 on transmission and ignored on receipt 🌸

Bits R are reserved. They SHOULD be set to 0 on transmission and ignored on receipt.

MT ID is a 12-bit field holding the ID of the topology being announced 🎀

This MT TLV can advertise up to 127 MTs 👑 It gets announced in IIHs and LSP fragment 0, and it can show up multiple times. The resulting MT set SHOULD be the union of all the MT TLV occurrences in the packet. Any other IS-IS PDU occurrence of this TLV MUST be ignored. If there's no MT TLV in hellos and fragment zero LSPs, that MUST be read as the advertising interface or router participating in MT ID #0 only. And if a router does advertise MT TLV, it has to advertise every MT it participates in, specifically including topology ID #0 too. No skipping the standard one, bestie 🫶

7.2. MT Intermediate Systems TLV

The TLV number here is 222. It's basically the extended IS reachability TLV (type 22) with two extra bytes stuck in front at the beginning.

• CODE - 222
• LENGTH - total length of the value field
• VALUE - 2-byte MT membership plus the format of extended IS reachability TLV, structured as follows:

                                                     No. of Octets
                 +--------------------------------+
                 |R |R |R |R |        MT ID       |      2
                 +--------------------------------+
                 | extended IS TLV format         |    11 - 253
                 +--------------------------------+
                 .                                .
                 .                                .
                 +--------------------------------+
                 | extended IS TLV format         |    11 - 253
                 +--------------------------------+

Bits R are reserved. They SHOULD be set to 0 on transmission and ignored on receipt.

MT ID is a 12-bit field holding the non-zero MT ID of the topology being announced. If the ID is zero, the TLV MUST be ignored. This is how everyone keeps the same view of the standard unicast topology 🧚

After the 2-byte MT membership, the MT IS content uses the same format as extended IS TLV, type 22 [RFC3784]. It can hold up to 23 neighbors of the same MT if no sub-TLVs are used.

This TLV can occur multiple times 💜

7.3. Multi-Topology Reachable IPv4 Prefixes TLV

The TLV number is 235. It's aligned with extended IP reachability TLV type 135, just with an extra two bytes in front 🍓

• CODE - 235
• LENGTH - total length of the value field
• VALUE - 2-byte MT membership plus the format of extended IP reachability TLV, structured as follows:

                                                     No. of Octets
                 +--------------------------------+
                 |R |R |R |R |        MT ID       |      2
                 +--------------------------------+
                 | extended IP TLV format         |    5 - 253
                 +--------------------------------+
                 .                                .
                 .                                .
                 +--------------------------------+
                 | extended IP TLV format         |    5 - 253
                 +--------------------------------+

Bits R are reserved. They SHOULD be set to 0 on transmission and ignored on receipt.

MT ID is a 12-bit field holding the non-zero ID of the topology being announced. If the ID is zero, the TLV MUST be ignored. Again, this keeps the standard unicast topology consistent for everybody 🌈

After the 2-byte MT membership, the MT IPv4 content uses the same format as extended IP reachability TLV, type 135 [RFC3784].

This TLV can occur multiple times ✨

7.4. Multi-Topology Reachable IPv6 Prefixes TLV

The TLV number is 237. It lines up with IPv6 Reachability TLV type 236, plus two extra bytes at the front 🦋

• CODE - 237
• LENGTH - total length of the value field
• VALUE - 2-byte MT membership plus the format of IPv6 Reachability TLV, structured as follows:

                                                     No. of Octets
                 +--------------------------------+
                 |R |R |R |R |        MT ID       |      2
                 +--------------------------------+
                 | IPv6 Reachability format       |    6 - 253
                 +--------------------------------+
                 .                                .
                 +--------------------------------+
                 | IPv6 Reachability format       |    6 - 253
                 +--------------------------------+

Bits R are reserved. They SHOULD be set to 0 on transmission and ignored on receipt.

MT ID is a 12-bit field holding the ID of the topology being announced. If the ID is zero, the TLV MUST be ignored.

After the 2-byte MT membership, the MT IPv6 context uses the same format as IPv6 Reachability TLV, type 236 [H01].

This TLV can occur multiple times 🫶

7.5. Reserved MT ID Values

Some MT topologies already have jobs assigned to them 👑

-  MT ID #0:          Equivalent to the "standard" topology.
-  MT ID #1:          Reserved for IPv4 in-band management
                      purposes.
-  MT ID #2:          Reserved for IPv6 routing topology.
-  MT ID #3:          Reserved for IPv4 multicast routing topology.
-  MT ID #4:          Reserved for IPv6 multicast routing topology.
-  MT ID #5:          Reserved for IPv6 in-band management
                      purposes.
-  MT ID #6-#3995:    Reserved for IETF consensus.
-  MT ID #3996-#4095: Reserved for development, experimental and
                      proprietary features [RFC3692].

8. MT IP Forwarding Considerations

okay so running MT extension for IS-IS routing can give you multiple RIBs on the same system 🌸 Here's a rundown of the known things to think about for IP forwarding in different MT setups. Some of these deployment scenarios come with different trade-offs, in terms of how hard they are to deploy and what you get out of them 💅

8.1. Each MT Belongs to a Distinct Address Family

In this case, every MT-related route goes into its own separate RIB. Multiple topologies can share the same IS-IS interface by looking at the address family of the incoming packet 🦋 For example, IPv4 and IPv6 can share one interface with no extra considerations under MT ISIS. Easy mode 😭

8.2. Some MTs Belong to the Same Address Family

8.2.1. Each Interface Belongs to One and Only One MT

In this case, MTs can forward packets from the same address family, even when the addresses overlap. Each MT has its own dedicated interfaces, and those interfaces can be tied to specific MT RIBs and FIBs 🎀

8.2.2. Multiple MTs Share an Interface with Overlapping Addresses

Here you need an extra mechanism to pick the right RIBs for incoming IP packets, so the correct RIB makes the forwarding decision 🔥 For example, if the topologies are Quality of Service (QoS) partitioned, the Differentiated Services Code Point (DSCP) bits in the IP packet header can be used to decide. Some IP headers, or even packet data information, MAY be checked to pick the forwarding table. For instance, the source IP address in the header can determine the forwarding behavior you want.

This topic isn't unique to IS-IS or even to Multi-topology. It's a local policy and configuration decision to make sure inbound traffic uses the correct forwarding tables 💜 For example, preferred customer packets might go through a Layer 2 Tunneling Protocol (L2TP) towards the high-bandwidth upstream provider, while other packets go through a different L2TP to a normal-bandwidth provider. Those mechanisms aren't part of the L2TP protocol specifications.

The generic approach of mapping packets to multiple MT RIBs over the same inbound interface is outside the scope of this document 🙈

8.2.3. Multiple MTs Share an Interface with Non-Overlapping Addresses

When there's no overlap in the address space among all the MTs, the destination address space is what tells you which topology a packet belongs to, strictly speaking ✨ Routes from different MTs can be installed into a shared RIB. As an example of this kind of deployment, a special IS-IS topology can be set up for certain External Border Gateway Protocol (eBGP) nexthop addresses 🌈

8.3. Some MTs Are Not Used for Forwarding Purposes

MT in IS-IS MAY be used even if the resulting RIB isn't used for forwarding. For example, a multicast Reverse Path Forwarding (RPF) check can run against a different RIB than the standard unicast RIB, even though a totally different RIB handles the multicast forwarding 🧚 Still, an incoming packet MUST still be clearly identified as belonging to a unique topology. Non-negotiable, bestie 💀

9. MT Network Management Considerations

when multiple IS-IS topologies exist in a domain, some routers can be configured to take part in only a subset of the MTs in the network 🍓 This section talks about the options you have for letting operations or network management stations reach those routers 💖

9.1. Create Dedicated Management Topology to Include All the Nodes

This approach sets up a dedicated management topology, also called an 'in-band' management topology 🎀 This 'mgmt' topology includes all the routers that need to be managed. The routes computed in this topology get installed into the 'mgmt' RIB. If the 'mgmt' topology uses a set of non-overlapping address space with the default topology, those 'mgmt' routes can also be optionally installed into the default RIB 🦋 Having duplicate 'mgmt' routes in both RIBs has some perks: the network management utilities on the system don't have to be changed to use a RIB other than the default one, and the 'mgmt' topology can share the same link with the default topology if it's designed that way 🌸

9.2. Extend the Default Topology to All the Nodes

Even if the default topology isn't used on some nodes in the IP forwarding, we MAY want to extend the default topology to those nodes for network management purposes 🫶 Operators SHOULD set high costs on the links that belong to the extended portion of the default topology. That way, IP data traffic won't get forwarded through those nodes during network topology changes 👑

10. Acknowledgments 🙏✨

Okay bestie, the authors wanted to give a huge shoutout to everyone who helped make this doc happen. Andrew Partan, Dino Farinacci, Derek Yeung, Alex Zinin, Stefano Previdi, Heidi Ou, Steve Luong, Pekka Savola, Mike Shand, Shankar Vemulapalli, and Les Ginsberg all brought the discussion, reviews, comments, and contributions. Iconic 🫶💖

11. Security Considerations 🔐💀

Okay, this section is serious business, so let's get into it. IS-IS security applies to the work presented here. No specific security issues with the proposed solutions are known 🙌 The authentication procedure for IS-IS PDUs is the same no matter what MT information is inside the IS-IS PDUs. Lowkey satisfying, right? 💅

Note that an authentication mechanism, such as the one defined in [RFC3567], SHOULD be applied if there is high risk resulting from modification of multi-topology information. 🚨 Big deal, so don't skip this one!

As described in Section 8.2.2, multiple topologies share an interface in the same address space, so some mechanism beyond IS-IS needs to be used to select the right forwarding table for an inbound packet. 😬 If the system is misconfigured, or a packet shows up with a spoofed source address, it can lead to packet loss or unauthorized use of premium network resources. That's a lot of drama for one packet, no cap 💀

12. IANA Considerations 📋🎀

This document defines the following new IS-IS TLV types, which have already been reflected in the IANA IS-IS TLV code-point registry ✨

          Name                    Value

          MT-ISN                  222
          M-Topologies            229
          MT IP. Reach            235
          MT IPv6 IP. Reach       237

IANA has created a new registry, "IS-IS Multi-Topology Parameters", with the assignments listed in Section 7.5 of this document, plus registration policies [RFC2434] for future assignments. 🗂️ The MT ID values in the range 6-3995 are allocated through Expert Review. Values in the range of 3996-4095 are reserved for Private Use. In all cases, assigned values are to be registered with IANA. Super organized, periodt 💜

13. References 📚🦋

13.1. Normative References

• [ISO10589] ISO. Intermediate System to Intermediate System Routing Exchange Protocol for Use in Conjunction with the Protocol for Providing the Connectionless-Mode Network Service. ISO 10589, 1992.
• [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
• [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

13.2. Informative References

• [RFC3567] Li, T. and R. Atkinson, "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, July 2003.
• [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
• [H01] C. Hopps, "Routing IPv6 with IS-IS", Work in Progress.

Authors' Addresses 🏡💌

Tony Przygienda
Z2 Sagl
Via Rovello 32
CH-6942 Savosa
EMail: prz@net4u.ch

Naiming Shen
Cisco Systems
225 West Tasman Drive
San Jose, CA, 95134 USA
EMail: naiming@cisco.com

Nischal Sheth
Juniper Networks
1194 North Mathilda Avenue
Sunnyvale, CA 94089 USA
EMail: nsheth@juniper.net

Full Copyright Statement ⚖️🌸

Copyright (C) The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 💜🧚

The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on whether any license under those rights might or might not be available. It also doesn't claim to have made any independent effort to identify such rights. Info on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79 📖

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users of this specification to use those proprietary rights can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. 🔗

The IETF invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology required to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. Thanks for being a good citizen of the internet, bestie 🫶🌈