IS-IS Routing with Reverse Metric
draft-ietf-isis-reverse-metric-05

   The challenge with the above solution are as follows.  First, it is
   quite common to have routers with several hundred interfaces onboard
   and individual interfaces that are transferring 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 its necessary to temporarily remove a multi-access LAN from the
   network topology.  Specifically, the operator needs to configure ALL
   devices's 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 LAN's, there is currently no method to bidirectionally
   isolate only a single node's interface on the LAN when performed more
   fine-grained diagnosis 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 as well as
   signaling from the NMS to those devices, using a network management
   protocol, to adjust the IS-IS metrics on the pertinent set of
   interfaces.  The reality is that NMS are, to a very large extent, not
   used within Service Provider's networks for a variety of reasons.  In
   particular, NMS do not interoperate very well across different
   vendors or even separate platform families within the same vendor.

   The risks of misidentifying one side of a point-to-point link or one
   or more interfaces attached to a multi-access LAN and subsequently
   increasing its IS-IS metric are potentially increased latency, jitter
   or packet loss.  This is unacceptable given the necessary performance
   requirements for a variety of applications, the customer perception
   for near lossless operations and the associated, demanding Service
   Level Agreement's (SLA's) for all network services.

Appendix C.  Use of Reverse Metric for LDP/IGP Synchronization on LAN's

   This document primarily outlines the use of IS-IS Reverse Metric TLV
   for networks that use IP forwarding.  However, it is also critical to
   consider application of the IS-IS Reverse Metric TLV to networks that
   use MPLS forwarding, specifically networks that use IS-IS as the IGP
   and LDP for signaling MPLS labels used for forwarding.  In these
   networks, it is often the case that IS-IS will become operational and
   determine the shortest path through a link or LAN prior to LDP
   becoming operational (forming an adjacency with a LDP neighbor and
   exchanging LDP labels), which results in temporary blackholing for
   data traffic reliant on MPLS forwarding.

Shen, et al.            Expires September 7, 2017              [Page 12]
Internet-Draft            IS-IS Reverse Metric                March 2017

   This scenario should be avoided in MPLS networks where IS-IS is the
   IGP and LDP signaling is used to exchange tunnel labels over a LAN.
   In these cases, it is recommended that the IS-IS Reverse Metric TLV
   be utilized when IS-IS and LDP adjacencies are in the process of
   becoming established among one, or several, routers attached to a
   common multi-access LAN.

   Specifically, when an IS-IS adjacency is being established from a
   non-DIS node, the non-DIS should transmit a IS-IS Reverse Metric TLV
   toward the DIS with the W-bit not set (0), as per
   "Elements of Procedure" in Section 3 of this document, until the non-
   DIS router either: a) completes transmission of a LDP End-of-LIB
   marker [RFC5919] toward the DIS; or, b) expiration of a local (pre-
   configured) timer that indicates that LDP adjacency should be fully
   operational to the DIS.  At this point, the non-DIS router should
   cease advertisement of the IS-IS Reverse Metric TLV, which should
   cause the (re-)advertisement of normal default metric(s) to itself in
   the Pseudonode LSP.

Appendix D.  Contributors' Addresses

   Tony Li

   Email: tony.li@tony.li

Authors' Addresses

   Naiming Shen
   Cisco Systems
   560 McCarthy Blvd.
   Milpitas, CA  95035
   USA

   Email: naiming@cisco.com

   Shane Amante
   Apple, Inc.
   1 Infinite Loop
   Cupertino, CA  95014
   USA

   Email: samante@apple.com

Shen, et al.            Expires September 7, 2017              [Page 13]
Internet-Draft            IS-IS Reverse Metric                March 2017

   Mikael Abrahamsson
   T-Systems Nordic
   Kistagangen 26
   Stockholm
   SE

   Email: Mikael.Abrahamsson@t-systems.se

Shen, et al.            Expires September 7, 2017              [Page 14]