RFC 8500
IS-IS Routing with Reverse Metric
RFC 8500: IS-IS Routing with Reverse Metric 🎀
Okay bestie, RFC 8500 is giving main character energy 💅 It's from the IETF (Internet Engineering Task Force), it's numbered 8500, and it came out in February 2019. Its ISSN is 2070-1721. It's a Standards Track document, so it's an official Internet standard, not just a suggestion 🧚 Three authors wrote it: N. Shen from Cisco Systems, S. Amante from Apple Inc., and M. Abrahamsson from T-Systems Nordic 🫶 The header doesn't list anything it obsoletes or updates.
Abstract ✨
Okay so the big idea is that this doc gives IS-IS routing a way to quickly and accurately move traffic off a point-to-point link or a multi-access LAN interface during network maintenance or other operational events 🦋 The trick is that the router tells its adjacent IS-IS neighbors to raise their reverse metric, which is the metric pointing back toward the router doing the signaling. That's the whole vibe 🌈
Status of This Memo
This is an Internet Standards Track document 💖
This document is a product of the Internet Engineering Task Force (IETF) 🎀 It represents the consensus of the IETF community, received public review, and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841 🌸
You can find the current status of this document, any errata, and how to send feedback at https://www.rfc-editor.org/info/rfc8500 🧚
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. 💜
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License 🫶
Table of Contents 📑
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Node and Link Isolation . . . . . . . . . . . . . . . . . 2
1.2. Distributed Forwarding Planes . . . . . . . . . . . . . . 3
1.3. Spine-Leaf Applications . . . . . . . . . . . . . . . . . 3
1.4. LDP IGP Synchronization . . . . . . . . . . . . . . . . . 3
1.5. IS-IS Reverse Metric . . . . . . . . . . . . . . . . . . 3
1.6. Specification of Requirements . . . . . . . . . . . . . . 4
2. IS-IS Reverse Metric TLV . . . . . . . . . . . . . . . . . . 4
3. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 6
3.1. Processing Changes to Default Metric . . . . . . . . . . 6
3.2. Multi-Topology IS-IS Support on Point-to-Point Links . . 7
3.3. Multi-access LAN Procedures . . . . . . . . . . . . . . . 7
3.4. LDP/IGP Synchronization on LANs . . . . . . . . . . . . . 8
3.5. Operational Guidelines . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Node Isolation Challenges . . . . . . . . . . . . . 13
Appendix B. Link Isolation Challenges . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 151. Introduction ✨
Okay so the IS-IS [ISO10589] routing protocol has been widely used in Internet Service Provider IP/MPLS networks 💅 Operators have learned a lot from running it, and with lossless operations becoming more and more important, some operational issues have shown up 😭 This doc describes those issues and a mechanism for fixing them 🩷
This doc defines the IS-IS "Reverse Metric" mechanism, which lets an IS-IS node send a Reverse Metric TLV through the IS-IS Hello (IIH) PDU to its neighbor or pseudonode, so the routing metric on the inbound direction gets adjusted 🦋
1.1. Node and Link Isolation
IS-IS has the overload bit, and operators can use it to do disruptive maintenance on a router. But honestly, in lots of maintenance situations you don't need to divert all the traffic away from that node 🙈 You only need to avoid a single link during the maintenance. There are more detailed descriptions of these challenges in Appendices A and B of this document 🍓
1.2. Distributed Forwarding Planes
On a distributed forwarding platform, different forwarding line cards can have interfaces and IS-IS connections to neighbor routers 🧚 If one of the line cards has a software reset, it can take some time for the forwarding entries to fully fill up on that line card. This is especially true if the router is a PE (Provider Edge) router in an ISP's MPLS VPN 😭 An IS-IS adjacency might come up with a neighbor router long before all the BGP VPN prefixes are downloaded into the forwarding table.
So it's important to tell the adjacent IS-IS routers to raise their metric values and to avoid using the matching IS-IS adjacency inbound to this router, if possible 💖 Temporarily signaling the 'Reverse Metric' over this link discourages traffic from going through that line card, and that helps cut down on traffic loss across the network ✨ Meanwhile, the remote PE routers can pick a different set of PE routers for the BGP best path calculation, or use a different link toward the same PE router whose line card is resetting 🫶
1.3. Spine-Leaf Applications
In the IS-IS Spine-Leaf extension [IS-IS-SL-EXT], leaf nodes do equal-cost or unequal-cost load sharing across all the spine nodes 🌈 Sometimes, like when one of the backbone links on a spine node is congested, that spine node can push a higher metric toward its connected leaf nodes. That way, transit traffic moves away from the spine node or link 💅
1.4. LDP IGP Synchronization
[RFC5443] describes a mechanism for LDP IGP synchronization that uses the maximum link metric value on the interface 🎀 But when a new IS-IS node joins a broadcast network (LAN), changing every node on the LAN to the maximum link metric value isn't ideal, as [RFC6138] points out 🙈 In that case, the Reverse Metric can discourage both outbound and inbound traffic without affecting the traffic of other IS-IS nodes on the LAN 🦋
1.5. IS-IS Reverse Metric
This doc uses the routing protocol itself as the transport, so one IS-IS router can advertise a "reverse metric" in an IS-IS Hello (IIH) PDU to an adjacent node on a point-to-point or multi-access LAN link 🧚 That means you only have to provision a single node: set a "reverse metric" on a link, and traffic shifts away from that link in both directions, moving gracefully onto other viable paths 👑
This Reverse Metric mechanism works for both point-to-point and multi-access LAN links. The thing is, IS-IS currently has no way to influence traffic toward a particular node on LAN links, unlike point-to-point links 😭 This mechanism gives IS-IS routing the power to change traffic in both directions, on either a point-to-point link or a multi-access link of an IS-IS node 💅
The metric value in the Reverse Metric TLV and the Traffic Engineering metric in the sub-TLV being advertised are offsets, or relative metrics. They get added to the receiver's existing local link and Traffic Engineering metric values, and the accumulated metric value is bounded as described in Section 2 🌸
1.6. Specification of Requirements
Okay this part is the rules 🤓 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 [RFC2119] [RFC8174], but only when they appear in all capitals, as shown here 💜
Part 1 ends here, bestie. Part 2 picks up with Section 2 (the IS-IS Reverse Metric TLV) 🧚✨
2. IS-IS Reverse Metric TLV ✨
okay so bestie, this section is where the Reverse Metric TLV finally shows up 🎀 it's a brand new TLV you can stick inside an IS-IS Hello PDU, and its whole job is to let a router send a "reverse metric" to its IS-IS neighbor 🦋 the way that it works is giving main character energy, no cap 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | Metric
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Metric (Continued) | sub-TLV Len |Optional sub-TLV
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Reverse Metric TLVokay so the Value part is giving three pieces 🧚 there's a 3 octet Metric field 💜, a 1 octet Flags field 🌸, and a 1 octet "sub-TLV Len" field that tells you how long the variable pile of sub-TLVs is 🍓 and if "sub-TLV Len" is non-zero, the Value field MUST also contain one or more sub-TLVs 😭 that is not a suggestion bestie 💀
The Reverse Metric TLV MAY be present in any IS-IS Hello PDU 🌈 but a sender MUST only transmit a single Reverse Metric TLV in an IS-IS Hello PDU ✨ and if a received IS-IS Hello PDU has more than one Reverse Metric TLV, an implementation MUST ignore all the Reverse Metric TLVs 🙈 like, one is the limit, periodt 👑
TYPE: 16
LENGTH: variable (5 - 255 octets)
VALUE:
Flags (1 octet)
Metric (3 octets)
sub-TLV length (1 octet)
sub-TLV data (0 - 250 octets)
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |U|W|
+-+-+-+-+-+-+-+-+
Figure 2: FlagsThe Metric field is a 24-bit unsigned integer 🦋 and it's a metric offset that a neighbor SHOULD add to the existing configured Default Metric for the IS-IS link [ISO10589] 💖 for how an IS-IS router should process the Metric field in a Reverse Metric TLV, check out "Elements of Procedure" in Section 3 of this document 🫶
The Metric field in the Reverse Metric TLV is a "reverse offset metric" 🎀 it lands in the range of 0 - 63 when a "narrow" IS-IS metric is used (IS Neighbors TLV / Pseudonode LSP) [RFC1195] 🌸 or in the range of 0 - (2^24 - 2) when a "wide" Traffic Engineering metric value is used (Extended IS Reachability TLV) [RFC5305] [RFC5817] ✨ and as described below, when the U bit is set, the accumulated value of the wide metric is in the range of 0 - (2^24 - 1), with the (2^24 - 1) metric value as non-reachable in IS-IS routing 🙈 the IS-IS metric value of (2^24 - 2) serves as the link of last resort 💅
There are currently only two Flag bits defined 🧚
W bit (0x01): The "Whole LAN" bit is only used in the context of multi-access LANs 🌈 when a Reverse Metric TLV is transmitted from a node to the Designated Intermediate System (DIS), if the "Whole LAN" bit is set (1), then a DIS SHOULD add the received Metric value in the Reverse Metric TLV to each node's existing Default Metric in the Pseudonode LSP 💖 if the "Whole LAN" bit is not set (0), then a DIS SHOULD add the received Metric value in the Reverse Metric TLV to the existing "default metric" in the Pseudonode LSP for the single node from whom the Reverse Metric TLV was received 🍓 for more details, see "Multi-access LAN Procedures", in Section 3.3 🫶 the W bit MUST be clear when a Reverse Metric TLV is transmitted in an IIH PDU on a point-to-point link and MUST be ignored when received on a point-to-point link 😭
U bit (0x02): The "Unreachable" bit says the metric you get by adding the reverse metric to the "default metric" is capped at the maximum value of (2^24-1) 👑 this "U" bit applies to both the default metric in the Extended IS Reachability TLV and the Traffic Engineering Default Metric sub-TLV of the link 🦋 and it's only relevant to the IS-IS "wide" metric mode 🌸
The Reserved bits of the Flags field MUST be set to zero and MUST be ignored when received 💜
The Reverse Metric TLV MAY include sub-TLVs when an IS-IS router wants to signal extra info to its neighbor ✨ in this document, the Reverse Metric Traffic Engineering Metric sub-TLV, with Type 18, is defined 🧚 this Traffic Engineering Metric is a 24-bit unsigned integer 🎀 this sub-TLV is optional; if it appears more than once, then the entire Reverse Metric TLV MUST be ignored 🙈 upon receiving this Traffic Engineering METRIC sub-TLV in a Reverse Metric TLV, a node SHOULD add the received Traffic Engineering Metric offset value to its existing configured Traffic Engineering Default Metric within its Extended IS Reachability TLV 💖 the use of other sub-TLVs is outside the scope of this document 🌈 and the "sub-TLV Len" value MUST be set to zero when an IS-IS router does not have Traffic Engineering sub-TLVs that it wants to send to its IS-IS neighbor 🫶
3. Elements of Procedure 💅
3.1. Processing Changes to Default Metric 🌸
it's super important to use the same IS-IS metric type on both ends of the link and in the entire IS-IS area or level 👑 on the receiving side of the 'reverse-metric' TLV, the accumulated value of the configured metric and the reverse-metric needs to be limited to 63 in "narrow" metric mode and to (2^24 - 2) in "wide" metric mode 🦋 this applies to both the Default Metric of the Extended IS Reachability TLV and the Traffic Engineering Default Metric sub-TLV in LSP or Pseudonode LSP for the "wide" metric mode case 🧚 if the "U" bit is present in the flags, the accumulated metric value is to be limited to (2^24 - 1) for both the normal link metric and Traffic Engineering metric in IS-IS "wide" metric mode 💜
if an IS-IS router is configured to originate a Traffic Engineering Default Metric sub-TLV for a link but receives a Reverse Metric TLV from its neighbor that does not contain a Traffic Engineering Default Metric sub-TLV, then the IS-IS router MUST NOT change the value of its Traffic Engineering Default Metric sub-TLV for that link 🙈
3.2. Multi-Topology IS-IS Support on Point-to-Point Links 🎀
The Reverse Metric TLV applies to Multi-topology IS-IS (M-ISIS) [RFC5120] 🌈 on point-to-point links, if an IS-IS router is configured for M-ISIS, it MUST send only a single Reverse Metric TLV in IIH PDUs toward its neighbor(s) on the designated link 💖 when an M-ISIS router receives a Reverse Metric TLV, it MUST add the received Metric value to its Default Metric of the link in all Extended IS Reachability TLVs for all topologies 🫶 if an M-ISIS router receives a Reverse Metric TLV with a Traffic Engineering Default Metric sub-TLV, then the M-ISIS router MUST add the received Traffic Engineering Default Metric value to each of its Default Metric sub-TLVs in all of its MT Intermediate Systems TLVs 🍓 if an M-ISIS router is configured to advertise Traffic Engineering Default Metric sub-TLVs for one or more topologies but does not receive a Traffic Engineering Default Metric sub-TLV in a Reverse Metric TLV, then the M-ISIS router MUST NOT change the value in each of the Traffic Engineering Default Metric sub-TLVs for all topologies 😭
3.3. Multi-access LAN Procedures 🦋
On a Multi-access LAN, only the DIS SHOULD act upon information contained in a received Reverse Metric TLV 👑 all non-DIS nodes MUST silently ignore a received Reverse Metric TLV 💀 the decision process of the routers on the LAN MUST follow the procedure in Section 7.2.8.2 of [ISO10589], and use the "Two-way connectivity check" during the topology and route calculation 🧚
The Reverse Metric Traffic Engineering sub-TLV also applies to the DIS 🌸 if a DIS is configured to apply Traffic Engineering over a link and it receives a Traffic Engineering Metric sub-TLV in a Reverse Metric TLV, it should update the Traffic Engineering Default Metric sub-TLV value of the corresponding Extended IS Reachability TLV or insert a new one if not present 💜
In the case of multi-access LANs, the "W" Flags bit is used to signal from a non-DIS to the DIS whether or not to change the metric and, optionally, Traffic Engineering parameters for all nodes in the Pseudonode LSP or solely the node on the LAN originating the Reverse Metric TLV ✨
A non-DIS node, e.g., Router B, attached to a multi-access LAN will send the DIS a Reverse Metric TLV with the W bit clear when Router B wants the DIS to add the Metric value to the Default Metric contained in the Pseudonode LSP specific to just Router B 🎀 other non-DIS nodes, e.g., Routers C and D, may simultaneously send a Reverse Metric TLV with the W bit clear to request the DIS to add their own Metric value to their Default Metric contained in the Pseudonode LSP 🫶
As long as at least one IS-IS node on the LAN sends the signal to the DIS with the W bit set, the DIS would add the metric value in the Reverse Metric TLV to all neighbor adjacencies in the Pseudonode LSP 🌈 regardless of whether some of the nodes on the LAN advertise the Reverse Metric TLV without the W bit set 💖 the DIS MUST use the reverse metric of the highest source MAC address Non-DIS advertising the Reverse Metric TLV with the W bit set 👑
Local provisioning on the DIS to adjust the Default Metric(s) is another way to insert Reverse Metric in the Pseudonode LSP towards an IS-IS node on a LAN 🧚 in the case where a Reverse Metric TLV is also used in the IS-IS Hello PDU of the node, the local provisioning MUST take precedence over received Reverse Metric TLVs 💅 for instance, local policy on the DIS may be provisioned to ignore the W bit signaling on a LAN 🦋
Multi-topology IS-IS [RFC5120] specifies there is no change to construction of the Pseudonode LSP regardless of the Multi-topology (MT) capabilities of a multi-access LAN 🌸 if any MT capable node on the LAN advertises the Reverse Metric TLV to the DIS, the DIS should update, as appropriate, the Default Metric contained in the Pseudonode LSP 💜 if the DIS updates the Default Metric and floods a new Pseudonode LSP, those default metric values will be applied to all topologies during Multi-topology Shortest Path First calculations ✨
3.4. LDP/IGP Synchronization on LANs 🎀
As described in [RFC6138], when a new IS-IS node joins a broadcast network, it's unnecessary and sometimes even harmful for all IS-IS nodes on the LAN to advertise the maximum link metric 🙈 [RFC6138] proposes a solution where the new node does not advertise its adjacency towards the pseudonode when it is not in a "cut-edge" position 🫶
With the introduction of Reverse Metric in this document, a simpler alternative solution to the above problem can be used 🧚 the Reverse Metric lets the new node on the LAN advertise its inbound metric value as the maximum, which puts the link of this new node in the last resort position without impacting the other IS-IS nodes on the same LAN 💖
Specifically, when IS-IS adjacencies are being established by the new node on the LAN, besides setting the maximum link metric value (2^24 - 2) on the interface of the LAN for LDP IGP synchronization as described in [RFC5443], it SHOULD advertise the maximum metric offset value in the Reverse Metric TLV in its IIH PDU sent on the LAN 🌈 it SHOULD continue this advertisement until it completes all the LDP label binding exchanges with all the neighbors over this LAN, either by receiving the LDP End-of-LIB [RFC5919] for all the sessions or by exceeding the provisioned timeout value for the node LDP/IGP synchronization 🦋
3.5. Operational Guidelines ✨
Okay bestie, so for the use case in Section 1.1 🎀, a router SHOULD limit how long it advertises a Reverse Metric TLV to a neighbor. Keep that window to just the length of a network maintenance window 🛠️. Short and sweet!
Using a Reverse Metric doesn't touch the IS-IS metric settings saved in a router's persistent provisioning database 💾. Your config stays exactly as you left it 🫶.
If routers that receive a Reverse Metric TLV send a syslog message or SNMP trap 📣, it helps you spot fast which node is advertising an IS-IS metric or Traffic Engineering parameter that's different from what's configured locally on the device 🔍. Main character detective energy 🕵️♀️.
When the link Traffic Engineering metric gets raised to (2^24 - 1) [RFC5817] 🚧, whether that's from the Reverse Metric mechanism or from explicit user configuration, this SHOULD immediately trigger a CSPF (Constrained Shortest Path First) recalculation so the Traffic Engineering traffic moves away from that link 🏃♀️💨. It is RECOMMENDED also that CSPF runs that immediate recalculation when the Traffic Engineering metric is raised to (2^24 - 2), which makes it the last resort link 🫣.
It is advisable that implementations give operators a configuration capability to disable any IS-IS metric changes made by the Reverse Metric mechanism through neighbors' Hello PDUs. Protect your link, bestie 🔒.
If an implementation turns this mechanism on by default, it is RECOMMENDED that operators disable it whenever they aren't explicitly using it 🧹. Don't leave it running in the background like a forgotten tab 💀.
4. Security Considerations 🔐
Security concerns for IS-IS are covered in [ISO10589], [RFC5304], and [RFC5310], and the deployment and operational security considerations are in [RFC7645]. The enhancement in this document makes it possible for one IS-IS router to manipulate the IS-IS Default Metric and, optionally, the Traffic Engineering parameters of adjacent IS-IS neighbors on point-to-point or LAN interfaces 😱. Even though IS-IS routers within a single Autonomous System nearly always sit under the control of one administrative authority, it is highly recommended that operators configure authentication of IS-IS PDUs 🛡️. That's how you stop the Reverse Metric TLV from becoming a potential attack vector 🚨. This one is serious, no cap 💅.
5. IANA Considerations 🗂️
IANA has allocated IS-IS TLV Codepoint 16 for the Reverse Metric TLV 🎉. This new TLV has the following attributes: IIH = y, LSP = n, SNP = n, Purge = n.
This document also introduces a brand new registry for sub-TLVs of the Reverse Metric TLV ✨. The registration policy is Expert Review, as defined in [RFC8126]. The registry lives inside the "IS-IS TLV Codepoints" registry, and it's named "Sub-TLVs for TLV 16 (Reverse Metric TLV)". The defined values are:
0: Reserved
1-17: Unassigned
18: Traffic Engineering Metric as specified in this document
(Section 2)
19-255: Unassigned6. References 📚
6.1. Normative References
These are the must-read references, the ones the spec is built on 🧠.
[ISO10589] ISO, "Information technology -- Telecommunications and
information exchange between systems -- 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,
November 2002.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, DOI 10.17487/RFC1195,
December 1990, <https://www.rfc-editor.org/info/rfc1195>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008,
<https://www.rfc-editor.org/info/rfc5120>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP
Synchronization", RFC 5443, DOI 10.17487/RFC5443, March
2009, <https://www.rfc-editor.org/info/rfc5443>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.6.2. Informative References
These ones are the extra reading for when you want the full picture 🤓.
[IS-IS-SL-EXT]
Shen, N., Ginsberg, L., and S. Thyamagundalu, "IS-IS
Routing for Spine-Leaf Topology", Work in Progress,
draft-ietf-lsr-isis-spine-leaf-ext-00, December 2018.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, DOI 10.17487/RFC5304, October
2008, <https://www.rfc-editor.org/info/rfc5304>.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, DOI 10.17487/RFC5310, February
2009, <https://www.rfc-editor.org/info/rfc5310>.
[RFC5817] Ali, Z., Vasseur, JP., Zamfir, A., and J. Newton,
"Graceful Shutdown in MPLS and Generalized MPLS Traffic
Engineering Networks", RFC 5817, DOI 10.17487/RFC5817,
April 2010, <https://www.rfc-editor.org/info/rfc5817>.
[RFC5919] Asati, R., Mohapatra, P., Chen, E., and B. Thomas,
"Signaling LDP Label Advertisement Completion", RFC 5919,
DOI 10.17487/RFC5919, August 2010,
<https://www.rfc-editor.org/info/rfc5919>.
[RFC6138] Kini, S., Ed. and W. Lu, Ed., "LDP IGP Synchronization for
Broadcast Networks", RFC 6138, DOI 10.17487/RFC6138,
February 2011, <https://www.rfc-editor.org/info/rfc6138>.
[RFC7645] Chunduri, U., Tian, A., and W. Lu, "The Keying and
Authentication for Routing Protocol (KARP) IS-IS Security
Analysis", RFC 7645, DOI 10.17487/RFC7645, September 2015,
<https://www.rfc-editor.org/info/rfc7645>.Appendix A. Node Isolation Challenges 🧊
Every so often, an operator has to do disruptive maintenance on an entire IS-IS router node 🔧. Think major software upgrades, or power and cooling upgrades 🌡️. In those cases, the operator sets the IS-IS Overload Bit (OL bit) in the Link State Protocol Data Units (LSPs) of the router that's about to go under maintenance. That router immediately floods its updated LSPs to every IS-IS router in the domain 📡. When everyone gets those updated LSPs, all the IS-IS routers recalculate their Shortest Path First (SPF) tree while leaving out any router whose LSPs have the OL bit set. That effectively removes the router from the topology, so it stops receiving any transit traffic during maintenance 🚫.
Once the maintenance is done, the operator resets the IS-IS Overload Bit in the LSPs of the original router. That router floods updated LSPs throughout the domain again, every router recalculates its SPF tree, and the router is back in their topology calculations and can carry transit traffic again 🎈.
Isolating a whole IS-IS router can be super disruptive 😩. A big pile of traffic gets pushed through other, suboptimal paths (for example, ones with a significantly larger delay). So in most maintenance scenarios, where only a single link or LAN needs more physical capacity or is having an intermittent failure, it's much more common and much more desirable to gracefully pull just that targeted link or LAN out of service for a while 🪄. That way, the least amount of user-data traffic gets affected during the link-specific maintenance 💖.
Appendix B. Link Isolation Challenges 🔗
Before maintenance happens on individual physical links or LANs, operators bump up the IS-IS metric on both devices attached to the same link or LAN at the same time 📈. The devices generate new Link State Protocol Data Units (LSPs), which get flooded through the network and make every router gradually shift traffic onto alternate paths 🌊. Applications and end users barely notice, or don't notice at all 🙌. When it works, the operator can confidently do disruptive augmentation, fault diagnosis, or repairs on a link without disturbing ongoing communications anywhere in the network 💅.
The above solution comes with some challenges, though 😬. First, it's pretty common for routers to have several hundred interfaces, with individual interfaces moving anywhere from several hundred gigabits per second to terabits per second of traffic 💸. So it's absolutely essential that operators accurately identify the same point-to-point link on two separate devices before they increase (and later decrease) the IS-IS metric. Second, this whole approach is very time-consuming and even more error-prone when you need to temporarily remove a multi-access LAN from the topology 😵💫. The operator has to configure ALL devices with interfaces attached to the multi-access LAN with an appropriately high IS-IS metric, and then set the metric back to its original value afterward. Finally, for multi-access LANs, there's currently no method to bidirectionally isolate only a single node's interface on the LAN when doing finer-grained diagnoses and repairs 🥲.
In theory, a Network Management System (NMS) could make it more accurate to identify the right subset of routers attached to either a point-to-point link or a multi-access LAN 🧐. It could also signal those devices, using a network management protocol, to adjust the IS-IS metrics on the relevant set of interfaces 📬. The reality is that NMSs are, to a very large extent, not used within Service Providers' networks for a variety of reasons 🙃. In particular, NMSs don't interoperate very well across different vendors, or even across separate platform families from the same vendor 🫠.
Acknowledgments 🫶
The authors would like to thank Mike Shand, Dave Katz, Guan Deng, Ilya Varlashkin, Jay Chen, Les Ginsberg, Peter Ashwood-Smith, Uma Chunduri, Alexander Okonnikov, Jonathan Harrison, Dave Ward, Himanshu Shah, Wes George, Danny McPherson, Ed Crabbe, Russ White, Robert Raszuk, Tom Petch, Stewart Bryant, and Acee Lindem for their comments and contributions 💜.
Contributors 🌸
Tony Li
Email: tony.li@tony.li
Authors' Addresses 📮
Naiming Shen
Cisco Systems
560 McCarthy Blvd.
Milpitas, CA 95035
United States of America
Email: naiming@cisco.com
Shane Amante
Apple Inc.
One Apple Park Way
Cupertino, CA 95014
United States of America
Email: amante@apple.com
Mikael Abrahamsson
T-Systems Nordic
Kistagangen 26
Stockholm
Sweden
Email: Mikael.Abrahamsson@t-systems.se📦 where this page comes from
- ietf: rfc8500 2019-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms