doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc8500.txt b/doc/rfc/rfc8500.txt
new file mode 100644
index 0000000..91fa231
--- /dev/null
+++ b/doc/rfc/rfc8500.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           N. Shen
+Request for Comments: 8500                                 Cisco Systems
+Category: Standards Track                                      S. Amante
+ISSN: 2070-1721                                               Apple Inc.
+                                                          M. Abrahamsson
+                                                        T-Systems Nordic
+                                                           February 2019
+
+
+                   IS-IS Routing with Reverse Metric
+
+Abstract
+
+   This document describes a mechanism to allow IS-IS routing to quickly
+   and accurately shift traffic away from either a point-to-point or
+   multi-access LAN interface during network maintenance or other
+   operational events.  This is accomplished by signaling adjacent IS-IS
+   neighbors with a higher reverse metric, i.e., the metric towards the
+   signaling IS-IS router.
+
+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.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained 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, as 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 are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+Shen, et al.                 Standards Track                    [Page 1]
+
+RFC 8500                  IS-IS Reverse Metric             February 2019
+
+
+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  . . . . . . . . . . . . . . . . . . . . . . .  15
+
+1.  Introduction
+
+   The IS-IS [ISO10589] routing protocol has been widely used in
+   Internet Service Provider IP/MPLS networks.  Operational experience
+   with the protocol combined with ever increasing requirements for
+   lossless operations have demonstrated some operational issues.  This
+   document describes the issues and a mechanism for mitigating them.
+
+   This document defines the IS-IS "Reverse Metric" mechanism that
+   allows an IS-IS node to send a Reverse Metric TLV through the IS-IS
+   Hello (IIH) PDU to the neighbor or pseudonode to adjust the routing
+   metric on the inbound direction.
+
+1.1.  Node and Link Isolation
+
+   The IS-IS routing mechanism has the overload bit, which can be used
+   by operators to perform disruptive maintenance on the router.  But in
+   many operational maintenance cases, it is not necessary to divert all
+   the traffic away from this node.  It is necessary to avoid only a
+   single link during the maintenance.  More detailed descriptions of
+   the challenges can be found in Appendices A and B of this document.
+
+
+
+Shen, et al.                 Standards Track                    [Page 2]
+
+RFC 8500                  IS-IS Reverse Metric             February 2019
+
+
+1.2.  Distributed Forwarding Planes
+
+   In a distributed forwarding platform, different forwarding line cards
+   may have interfaces and IS-IS connections to neighbor routers.  If
+   one of the line card's software resets, it may take some time for the
+   forwarding entries to be fully populated on the line card, in
+   particular if the router is a PE (Provider Edge) router in an ISP's
+   MPLS VPN.  An IS-IS adjacency may be established with a neighbor
+   router long before the entire BGP VPN prefixes are downloaded to the
+   forwarding table.  It is important to signal to the adjacent IS-IS
+   routers to raise metric values and not to use the corresponding IS-IS
+   adjacency inbound to this router if possible.  Temporarily signaling
+   the 'Reverse Metric' over this link to discourage the traffic via the
+   corresponding line card will help to reduce the traffic loss in the
+   network.  In the meantime, the remote PE routers will select a
+   different set of PE routers for the BGP best path calculation or use
+   a different link towards the same PE router on which a line card is
+   resetting.
+
+1.3.  Spine-Leaf Applications
+
+   In the IS-IS Spine-Leaf extension [IS-IS-SL-EXT], the leaf nodes will
+   perform equal-cost or unequal-cost load sharing towards all the spine
+   nodes.  In certain operational cases, for instance, when one of the
+   backbone links on a spine node is congested, a spine node can push a
+   higher metric towards the connected leaf nodes to reduce the transit
+   traffic through the corresponding spine node or link.
+
+1.4.  LDP IGP Synchronization
+
+   In [RFC5443], a mechanism is described to achieve LDP IGP
+   synchronization by using the maximum link metric value on the
+   interface.  But in the case of a new IS-IS node joining the broadcast
+   network (LAN), it is not optimal to change all the nodes on the LAN
+   to the maximum link metric value, as described in [RFC6138].  In this
+   case, the Reverse Metric can be used to 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 document uses the routing protocol itself as the transport
+   mechanism to allow one IS-IS router to 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.  This would allow the provisioning to be
+   performed only on a single node, setting a "reverse metric" on a link
+   and having traffic bidirectionally shift away from that link
+   gracefully to alternate viable paths.
+
+
+
+Shen, et al.                 Standards Track                    [Page 3]
+
+RFC 8500                  IS-IS Reverse Metric             February 2019
+
+
+   This Reverse Metric mechanism is used for both point-to-point and
+   multi-access LAN links.  Unlike the point-to-point links, the IS-IS
+   protocol currently does not have a way to influence the traffic
+   towards a particular node on LAN links.  This mechanism provides
+   IS-IS routing with the capability of altering 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 to be added to the existing local link and Traffic
+   Engineering metric values of the receiver; the accumulated metric
+   value is bounded as described in Section 2.
+
+1.6.  Specification of Requirements
+
+   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] when, and only when, they appear in all
+   capitals, as shown here.
+
+2.  IS-IS Reverse Metric TLV
+
+   The Reverse Metric TLV is a new TLV to be used inside an IS-IS Hello
+   PDU.  This TLV is used to support the IS-IS Reverse Metric mechanism
+   that allows a "reverse metric" to be sent to the IS-IS neighbor.
+
+       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 TLV
+
+   The Value part of the Reverse Metric TLV is composed of a 3 octet
+   field containing an IS-IS Metric value, a 1 octet field of Flags, and
+   a 1 octet Reverse Metric sub-TLV length field representing the length
+   of a variable number of sub-TLVs.  If the "sub-TLV Len" is non-zero,
+   then the Value field MUST also contain one or more sub-TLVs.
+
+   The Reverse Metric TLV MAY be present in any IS-IS Hello PDU.  A
+   sender MUST only transmit a single Reverse Metric TLV in an IS-IS
+   Hello PDU.  If a received IS-IS Hello PDU contains more than one
+
+
+
+
+Shen, et al.                 Standards Track                    [Page 4]
+
+RFC 8500                  IS-IS Reverse Metric             February 2019
+
+
+   Reverse Metric TLV, an implementation MUST ignore all the Reverse
+   Metric TLVs.
+
+      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: Flags
+
+   The Metric field contains a 24-bit unsigned integer.  This value is a
+   metric offset that a neighbor SHOULD add to the existing configured
+   Default Metric for the IS-IS link [ISO10589].  Refer to "Elements of
+   Procedure" in Section 3 of this document for details on how an IS-IS
+   router should process the Metric field in a Reverse Metric TLV.
+
+   The Metric field, in the Reverse Metric TLV, is a "reverse offset
+   metric" that will either be 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].  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.  Please refer to
+   "Multi-access LAN Procedures", in Section 3.3, for additional
+
+
+
+Shen, et al.                 Standards Track                    [Page 5]
+
+RFC 8500                  IS-IS Reverse Metric             February 2019
+
+
+   details.  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 specifies that the metric
+   calculated by the addition of the reverse metric to the "default
+   metric" is limited to 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.
+   This is only relevant to the IS-IS "wide" metric mode.
+
+   The Reserved bits of 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
+   wishes to signal additional information to its neighbor.  In this
+   document, the Reverse Metric Traffic Engineering Metric sub-TLV, with
+   Type 18, is defined.  This Traffic Engineering Metric contains 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.  The "sub-TLV Len"
+   value MUST be set to zero when an IS-IS router does not have Traffic
+   Engineering sub-TLVs that it wishes to send to its IS-IS neighbor.
+
+3.  Elements of Procedure
+
+3.1.  Processing Changes to Default Metric
+
+   It is 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 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
+
+
+
+
+Shen, et al.                 Standards Track                    [Page 6]
+
+RFC 8500                  IS-IS Reverse Metric             February 2019
+
+
+   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 is applicable 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 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
+   wishes the DIS to add the Metric value to the Default Metric
+   contained in the Pseudonode LSP specific to just Router B.  Other
+
+
+
+Shen, et al.                 Standards Track                    [Page 7]
+
+RFC 8500                  IS-IS Reverse Metric             February 2019
+
+
+   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 sending the signal to
+   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 if 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 is unnecessary and sometimes even harmful for all IS-IS
+   nodes on the LAN to advertise the maximum link metric.  [RFC6138]
+   proposes a solution to have the new node 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 mentioned problem can be used.  The
+   Reverse Metric allows the new node on the LAN to advertise its
+   inbound metric value to be the maximum, and this puts the link of
+   this new node in the last resort position without impacting the other
+   IS-IS nodes on the same LAN.
+
+
+
+
+
+
+Shen, et al.                 Standards Track                    [Page 8]
+
+RFC 8500                  IS-IS Reverse Metric             February 2019
+
+
+   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
+
+   For the use case in Section 1.1, a router SHOULD limit the period of
+   advertising a Reverse Metric TLV towards a neighbor only for the
+   duration of a network maintenance window.
+
+   The use of a Reverse Metric does not alter IS-IS metric parameters
+   stored in a router's persistent provisioning database.
+
+   If routers that receive a Reverse Metric TLV send a syslog message or
+   SNMP trap, this will assist in rapidly identifying the node in the
+   network that is advertising an IS-IS metric or Traffic Engineering
+   parameters different from that which is configured locally on the
+   device.
+
+   When the link Traffic Engineering metric is raised to (2^24 - 1)
+   [RFC5817], either due to the Reverse Metric mechanism or by explicit
+   user configuration, this SHOULD immediately trigger the CSPF
+   (Constrained Shortest Path First) recalculation to move the Traffic
+   Engineering traffic away from that link.  It is RECOMMENDED also that
+   the CSPF does the immediate CSPF recalculation when the Traffic
+   Engineering metric is raised to (2^24 - 2) to be the last resort
+   link.
+
+   It is advisable that implementations provide a configuration
+   capability to disable any IS-IS metric changes by a Reverse Metric
+   mechanism through neighbors' Hello PDUs.
+
+   If an implementation enables this mechanism by default, it is
+   RECOMMENDED that it be disabled by the operators when not explicitly
+   using it.
+
+
+
+
+
+
+
+
+
+Shen, et al.                 Standards Track                    [Page 9]
+
+RFC 8500                  IS-IS Reverse Metric             February 2019
+
+
+4.  Security Considerations
+
+   Security concerns for IS-IS are addressed in [ISO10589], [RFC5304],
+   [RFC5310], and with various deployment and operational security
+   considerations in [RFC7645].  The enhancement in this document makes
+   it possible for one IS-IS router to manipulate the IS-IS Default
+   Metric and, optionally, Traffic Engineering parameters of adjacent
+   IS-IS neighbors on point-to-point or LAN interfaces.  Although IS-IS
+   routers within a single Autonomous System nearly always are under the
+   control of a single administrative authority, it is highly
+   recommended that operators configure authentication of IS-IS PDUs to
+   mitigate use of the Reverse Metric TLV as a potential attack vector.
+
+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 new registry for sub-TLVs of the
+   Reverse Metric TLV.  The registration policy is Expert Review as
+   defined in [RFC8126].  This registry is part of the "IS-IS TLV
+   Codepoints" registry.  The name of the registry is "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:  Unassigned
+
+6.  References
+
+6.1.  Normative References
+
+   [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>.
+
+
+
+
+
+Shen, et al.                 Standards Track                   [Page 10]
+
+RFC 8500                  IS-IS Reverse Metric             February 2019
+
+
+   [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
+
+   [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>.
+
+
+
+Shen, et al.                 Standards Track                   [Page 11]
+
+RFC 8500                  IS-IS Reverse Metric             February 2019
+
+
+   [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>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Shen, et al.                 Standards Track                   [Page 12]
+
+RFC 8500                  IS-IS Reverse Metric             February 2019
+
+
+Appendix A.  Node Isolation Challenges
+
+   On rare occasions, it is necessary for an operator to perform
+   disruptive network maintenance on an entire IS-IS router node, i.e.,
+   major software upgrades, power/cooling augments, etc.  In these
+   cases, an operator will set the IS-IS Overload Bit (OL bit) within
+   the Link State Protocol Data Units (LSPs) of the IS-IS router about
+   to undergo maintenance.  The IS-IS router immediately floods its
+   updated LSPs to all IS-IS routers in the IS-IS domain.  Upon receipt
+   of the updated LSPs, all IS-IS routers recalculate their Shortest
+   Path First (SPF) tree excluding IS-IS routers whose LSPs have the OL
+   bit set.  This effectively removes the IS-IS router about to undergo
+   maintenance from the topology, thus preventing it from receiving any
+   transit traffic during the maintenance period.
+
+   After the maintenance activity has completed, the operator resets the
+   IS-IS Overload Bit within the LSPs of the original IS-IS router
+   causing it to flood updated IS-IS LSPs throughout the IS-IS domain.
+   All IS-IS routers recalculate their SPF tree and now include the
+   original IS-IS router in their topology calculations, allowing it to
+   be used for transit traffic again.
+
+   Isolating an entire IS-IS router from the topology can be especially
+   disruptive due to the displacement of a large volume of traffic
+   through an entire IS-IS router to other suboptimal paths (e.g., those
+   with significantly larger delay).  Thus, in the majority of network
+   maintenance scenarios, where only a single link or LAN needs to be
+   augmented to increase its physical capacity, or is experiencing an
+   intermittent failure, it is much more common and desirable to
+   gracefully remove just the targeted link or LAN from service
+   temporarily, so that the least amount of user-data traffic is
+   affected during the link-specific network maintenance.
+
+Appendix B.  Link Isolation Challenges
+
+   Before network maintenance events are performed on individual
+   physical links or LANs, operators substantially increase the IS-IS
+   metric simultaneously on both devices attached to the same link or
+   LAN.  In doing so, the devices generate new Link State Protocol Data
+   Units (LSPs) that are flooded throughout the network and cause all
+   routers to gradually shift traffic onto alternate paths with very
+   little or no disruption to in-flight communications by applications
+   or end users.  When performed successfully, this allows the operator
+   to confidently perform disruptive augmentation, fault diagnosis, or
+   repairs on a link without disturbing ongoing communications in the
+   network.
+
+
+
+
+
+Shen, et al.                 Standards Track                   [Page 13]
+
+RFC 8500                  IS-IS Reverse Metric             February 2019
+
+
+   There are a number of challenges with the above solution.  First, it
+   is quite common to have routers with several hundred interfaces and
+   individual interfaces that move anywhere from several hundred
+   gigabits/second to terabits/second of traffic.  Thus, it is
+   imperative that operators accurately identify the same point-to-point
+   link on two separate devices in order to increase (and afterward
+   decrease) the IS-IS metric appropriately.  Second, the aforementioned
+   solution is very time-consuming and even more error-prone to perform
+   when it's necessary to temporarily remove a multi-access LAN from the
+   network topology.  Specifically, the operator needs to configure ALL
+   devices that have interfaces attached to the multi-access LAN with an
+   appropriately high IS-IS metric (and then decrease the IS-IS metric
+   to its original value afterward).  Finally, with respect to multi-
+   access LANs, there is currently no method to bidirectionally isolate
+   only a single node's interface on the LAN when performing more fine-
+   grained diagnoses and repairs to the multi-access LAN.
+
+   In theory, use of a Network Management System (NMS) could improve the
+   accuracy of identifying the appropriate subset of routers attached to
+   either a point-to-point link or a multi-access LAN.  It could also
+   signal to those devices, using a network management protocol, to
+   adjust the IS-IS metrics on the pertinent set of interfaces.  The
+   reality is that NMSs are, to a very large extent, not used within
+   Service Provider's networks for a variety of reasons.  In particular,
+   NMSs do not interoperate very well across different vendors or even
+   separate platform families within the same vendor.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Shen, et al.                 Standards Track                   [Page 14]
+
+RFC 8500                  IS-IS Reverse Metric             February 2019
+
+
+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
+
+
+
+
+
+
+
+
+
+Shen, et al.                 Standards Track                   [Page 15]
+