--- 1/draft-ietf-isis-reverse-metric-15.txt 2018-11-04 07:13:52.164723284 -0800 +++ 2/draft-ietf-isis-reverse-metric-16.txt 2018-11-04 07:13:52.196724047 -0800 @@ -1,21 +1,21 @@ Networking Working Group N. Shen Internet-Draft Cisco Systems Intended status: Standards Track S. Amante -Expires: April 19, 2019 Apple, Inc. +Expires: May 8, 2019 Apple, Inc. M. Abrahamsson T-Systems Nordic - October 16, 2018 + November 4, 2018 IS-IS Routing with Reverse Metric - draft-ietf-isis-reverse-metric-15 + draft-ietf-isis-reverse-metric-16 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. @@ -27,72 +27,77 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 19, 2019. + This Internet-Draft will expire on May 8, 2019. Copyright Notice Copyright (c) 2018 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 (http://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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 - 1.1. Node and Link Isolation . . . . . . . . . . . . . . . . . 2 + 1.1. Node and Link Isolation . . . . . . . . . . . . . . . . . 3 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.5. IS-IS Reverse Metric . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . 9 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. Node Isolation Challenges . . . . . . . . . . . . . 12 Appendix B. Link Isolation Challenges . . . . . . . . . . . . . 13 Appendix C. Contributors' Addresses . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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 + IIH PDU to the neighbor or pseudo-node to adjust the routing metric + on the inbound direction. + 1.1. Node and Link Isolation 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 Appendix A and Appendix B of this document. @@ -214,21 +219,24 @@ 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 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]. + [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 (2^24 - 1) metric 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 @@ -403,39 +411,39 @@ 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 re- calculation to move the Traffic Engineering traffic away from that link. It is RECOMMENDED also that the CSPF does the immediate CSPF re-calculation when the Traffic Engineering metric is raised to (2^24 - 2) to be the last resort link. It is RECOMMENDED that implementations provide a capability to - disable any changes by Reverse Metric mechanism through neighbor's - Hello PDUs. It can be to a node's individual interface Default - Metric or Traffic Engineering parameters based upon receiving a - properly formatted Reverse Metric TLVs. + disable any IS-IS metric changes by Reverse Metric mechanism through + neighbor's Hello PDUs. It can be to a node's individual interface + Default Metric or Traffic Engineering parameters based upon receiving + a properly formatted Reverse Metric TLVs. If an implementation enables this mechanism by default, it is RECOMMENDED that it be disabled by the operators when not explicitly using it. 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. 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 + 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 Codepoints of 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 @@ -449,22 +457,22 @@ 18: Traffic Engineering Metric sub-TLV, as specified in this document (Section 2) 19-255: Unassigned 6. 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 and Acee Lindem for their comments and - contributions. + Raszuk, Tom Petch, Stewart Bryant and Acee Lindem for their comments + and contributions. This document was produced using Marshall Rose's xml2rfc tool. 7. References 7.1. Normative References [ISO10589] ISO, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with @@ -501,21 +509,21 @@ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [I-D.shen-isis-spine-leaf-ext] Shen, N., Ginsberg, L., and S. Thyamagundalu, "IS-IS Routing for Spine-Leaf Topology", draft-shen-isis-spine- - leaf-ext-03 (work in progress), March 2017. + leaf-ext-07 (work in progress), October 2018. [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, . [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, .