idnits 2.17.1 draft-ietf-isis-oper-enhance-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 14, 2013) is 4081 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3373 (Obsoleted by RFC 5303) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IS-IS Working Group N. Shen 3 Internet-Draft T. Li 4 Intended status: Informational Cisco Systems, Inc. 5 Expires: August 18, 2013 S. Amante 6 Level 3 Communications 7 M. Abrahamsson 8 Tele2 9 February 14, 2013 11 IS-IS Operational Enhancements for Network Maintenance Events 12 draft-ietf-isis-oper-enhance-03 14 Abstract 16 This document describes an improved IS-IS neighbor management scheme 17 which can be used to enhance operational experience in terms of 18 convergence speed and finer control of neighbor cost over a LAN. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 18, 2013. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Interface Shutdown Black Hole . . . . . . . . . . . . . . 2 56 1.2. LAN of Last Resort . . . . . . . . . . . . . . . . . . . 2 57 1.3. Specification of Requirements . . . . . . . . . . . . . . 3 58 2. Sending Hellos with Fast Exit Notification . . . . . . . . . 3 59 3. Pseudonodes with Non-zero Metrics . . . . . . . . . . . . . . 3 60 3.1. Alternative Approaches . . . . . . . . . . . . . . . . . 4 61 4. Operational Considerations . . . . . . . . . . . . . . . . . 4 62 4.1. Operational Considerations: Fast Exit Notification . . . 4 63 4.2. Operational Considerations: Pseudonodes with Non-zero 64 Metrics . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 67 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 70 1. Introduction 72 The IS-IS [ISO10589] routing protocol has been widely used in 73 Internet Service Provider IP/MPLS networks. Operational experience 74 with the protocol, combined with ever increasing requirements for 75 lossless operations have demonstrated some operational issues. This 76 document describes those issues and some mechanisms for dealing with 77 those issues. These mechanisms do involve implementation support, 78 but do not require protocol changes. 80 1.1. Interface Shutdown Black Hole 82 One of these operationally problematic issues occurs when IS-IS is 83 disabled on only one side of a link. This can result in a 84 significant delay before neighbor(s) on the other end of the same 85 link notice this change. In turn, this can result in several seconds 86 during which traffic is blackholed, until the IS-IS neighbor(s) time 87 out the adjacency and IS-IS reconverges. 89 1.2. LAN of Last Resort 91 Another issue stems from a situation when operators want to 92 temporarily make an interface a "last resort" link for transit 93 traffic. This is a straightforward, though cumbersome, operation to 94 perform on a point-to-point link. Each device on the link is 95 reconfigured to use very high metric. This causes traffic to divert 96 to other links in the network. This same operation is more difficult 97 on a multi-access LAN. There, the operator would have to increase 98 the metric on each and every interface attached to the LAN, requiring 99 the reconfiguration of a number of systems. 101 1.3. Specification of Requirements 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 2. Sending Hellos with Fast Exit Notification 109 When an operator shuts down IS-IS on an interface, as described in 110 Section 1.1, there is a significant interval before the change is 111 noticed by all adjacencies and traffic is subsequently re-routed 112 around this link. This delay is unnecessary, as neighbors should not 113 have to wait for the adjacency to timeout, particularly when there 114 exist alternate, viable, paths to downstream neighbors. This delay 115 can be eliminated by carefully removing the adjacency between 116 neighbors prior to actually disabling IS-IS on the interface. 118 An IS-IS adjacency uses the 3-way handshake protocol as defined in 119 [ISO10589] for multi-access LANs and [RFC3373] for point-to-point 120 links. In both cases, the IS to IS Hello (IIH) message is used to 121 establish and maintain the adjacency carries the system identifier of 122 the adjacent systems. The receiving system expects to see its own 123 system identifier listed. If not, then it must drop the adjacency. 125 An implementation that wishes to avoid the issue in Section 1.1 can 126 do so by sending out a final IIH that includes no neighboring system 127 IDs. When this is received, it should cause all neighbors to drop 128 their adjacencies with the router that sent the IIH. This will also 129 cause the systems to update their Link State Protocol Data Units 130 (LSPs), flood them and reconverge to new paths. The technique is 131 known as Fast Exit Notification. 133 3. Pseudonodes with Non-zero Metrics 135 If an operator wishes to reconfigure a multi-access LAN so that it is 136 only used as a resource of the last resort, then with current 137 mechanisms, the operator must reconfigure each node on the LAN to 138 give the LAN a high metric, as described in Section 1.2. It would be 139 much easier for the operator if they could make a single 140 configuration change that would cause IS-IS to treat the multi-access 141 LAN as a link of last resort. 143 [ISO10589] defines the pseudonode LSP as having a metric of zero. 144 This implies that during the Shortest Path First (SPF) calculation, 145 the metric for traversing the LAN is solely based on the metric set 146 by the IS used to access the LAN. Thereby, the pseudonode does not 147 contribute to the cost of traversing the LAN. 149 However, from the point of view of the SPF calculation, the metric in 150 the pseudonode LSP does not have to be zero. Instead, the metric in 151 a pseudonode LSP could be treated just like a normal LSP and have 152 non-zero metrics to some or all of the systems on the LAN. This can 153 then be used to simplify the operation for turning an entire LAN into 154 a link of last resort. This could be done by having the Designated 155 Intermediate System (DIS) change all of the metrics within the 156 pseudonode LSP to a high value. This would effectively make the 157 entire LAN look very 'expensive' and cause SPF calculations to 158 converge to alternate links, if at all possible. 160 This technique can also be used to divert traffic away from a subset 161 of the nodes on the LAN. If the DIS increases the metric from the 162 pseudonode to a subset of the systems on the LAN, then traffic will 163 avoid exiting the LAN via that subset of systems. 165 3.1. Alternative Approaches 167 An alternative is to allow any system to temporarily become the DIS, 168 when it is directed to, and set a non-zero metric in the pseudonode 169 LSP(s). This is beneficial because the operator would otherwise 170 first have to determine the current DIS, access that system and 171 reconfigure it. If an implementation wishes to support this, it can 172 provide an operation that both changes its priority on the LAN, so 173 that a node first becomes DIS, and then generates a new pseudonode 174 LSP with the non-zero metric. 176 If there is a concern that the DIS may change, it is prudent to 177 define another node on the same LAN with the second highest priority 178 for becoming DIS. This node can be configured to also set the metric 179 in its pseudonode LSP appropriately if it becomes the new DIS. 181 4. Operational Considerations 183 4.1. Operational Considerations: Fast Exit Notification 185 The approach described in Section 2 is not guaranteed. If the final 186 IIH is lost on the link, then the neighboring systems will have to 187 wait to time out the adjacency. Since this is unlikely, it is still 188 a useful optimization. Implementations that require an even higher 189 degree of assurance can retransmit the final IIH, possibly multiple 190 times. 192 4.2. Operational Considerations: Pseudonodes with Non-zero Metrics 194 Because the change to the usage of the pseudonode LSP, as described 195 in Section 3, is in direct contradiction to the existing IS-IS 196 specification, extreme caution is necessary. Implementations that 197 would not interpret a non-zero pseudonode metric correctly might 198 cause forwarding loops. Operators should perform Lab testing and 199 take caution when deploying this feature to ensure that nodes that 200 receive a non-zero pseudonode metric will interpret it correctly. 202 5. Security Considerations 204 This document raises no new security issues for IS-IS. 206 6. Acknowledgements 208 The authors would like to thank Mike Shand, Dave Katz, Guan Deng, 209 Ilya Varlashkin, Jay Chen, Peter Ashwood-Smith, Les Ginsberg, Danny 210 McPherson, Ed Crabbe, Russ White and Robert Raszuk for their reviews 211 and contributions. 213 7. Normative References 215 [ISO10589] 216 ISO, "Intermediate system to Intermediate system routeing 217 information exchange protocol for use in conjunction with 218 the Protocol for providing the Connectionless-mode Network 219 Service (ISO 8473) ", ISO/IEC 10589:2002, . 221 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 222 Requirement Levels", BCP 14, RFC 2119, March 1997. 224 [RFC3373] Katz, D. and R. Saluja, "Three-Way Handshake for 225 Intermediate System to Intermediate System (IS-IS) Point- 226 to-Point Adjacencies", RFC 3373, September 2002. 228 Authors' Addresses 230 Naiming Shen 231 Cisco Systems, Inc. 232 225 West Tasman Drive 233 San Jose, CA 95134 234 USA 236 Email: naiming@cisco.com 237 Tony Li 238 Cisco Systems, Inc. 239 225 West Tasman Drive 240 San Jose, CA 95134 241 USA 243 Email: tony.li@tony.li 245 Shane Amante 246 Level 3 Communications 247 1025 Eldorado Blvd 248 Broomfield, CO 80021 249 USA 251 Email: shane@level3.net 253 Mikael Abrahamsson 254 Tele2 256 Email: swmike@swm.pp.se