idnits 2.17.1 draft-shen-isis-oper-enhance-00.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 (September 30, 2010) is 4955 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: April 3, 2011 S. Amante 6 Level 3 Communications 7 M. Abrahamsson 8 Tele2 9 September 30, 2010 11 IS-IS Operational Enhancements for Network Maintenance Events 12 draft-shen-isis-oper-enhance-00 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 April 3, 2011. 37 Copyright Notice 39 Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Interface Shutdown Black Hole . . . . . . . . . . . . . . . 3 56 1.2. LAN of Last Resort . . . . . . . . . . . . . . . . . . . . 3 57 1.3. Specification of Requirements . . . . . . . . . . . . . . . 3 59 2. Sending Hellos with Fast Exit Notification . . . . . . . . . . 3 61 3. Pseudonodes with Non-zero Metrics . . . . . . . . . . . . . . . 4 62 3.1. Operational Considerations . . . . . . . . . . . . . . . . 5 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 66 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 68 6. Normative References . . . . . . . . . . . . . . . . . . . . . 5 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction 74 The IS-IS [ISO 10589] routing protocol has been widely used in 75 Internet Service Provider IP/MPLS networks. Operational experience 76 with the protocol, combined with ever increasing requirements for 77 lossless operations have demonstrated some operational issues. This 78 document describes those issues and some mechanisms for dealing with 79 those issues. These mechanisms do involve implementation support, 80 but do not require protocol changes. 82 1.1. Interface Shutdown Black Hole 84 One of these operationally problematic issues occurs when IS-IS is 85 disabled on only one side of a link. This can result in a 86 significant delay before neighbor(s) on the other end of the same 87 link notice this change. In turn, this can result in several seconds 88 during which traffic is blackholed, until the IS-IS neighbor(s) time 89 out the adjacency and IS-IS reconverges. 91 1.2. LAN of Last Resort 93 Another issue stems from a situation when operators want to 94 temporarily make an interface a "last resort" link for transit 95 traffic. This is a straightforward, through cumbersome, operation to 96 perform on a point-to-point link. Each device on the link is 97 reconfigured to use very high metric. This causes traffic to divert 98 to other links in the network. This same operation is more difficult 99 on a multi-access LAN. There, the operator would have to increase 100 the metric on each and every interface attached to the LAN, requiring 101 the reconfiguration of a number of systems. 103 1.3. Specification of Requirements 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 2. Sending Hellos with Fast Exit Notification 111 When an operator shuts down IS-IS on an interface, as described in 112 Section 1.1, there is a significant interval before the change is 113 noticed by all adjacencies and traffic is subsequently re-routed 114 around this link. This delay is unnecessary, as neighbors should not 115 have to wait for the adjacency to timeout, particularly when there 116 exist alternate, viable, paths to downstream neighbors. This delay 117 can be eliminated by carefully removing the adjacency between 118 neighbors prior to actually disabling IS-IS on the interface. 120 An IS-IS adjacency uses the 3-way handshake protocol as defined in 121 [ISO 10589] for multi-access LANs and [RFC3373] for point-to-point 122 links. In both cases, the IS to IS Hello (IIH) message used to 123 establish and maintain the adjacency carries the system identifier of 124 the adjacent systems. The receiving system expects to see its own 125 system identifier listed. If not, then it must drop the adjacency. 127 An implementation that wishes to avoid the issue in Section 1.1 can 128 do so by sending out a final IIH that includes no neighboring system 129 IDs. When this is received, it should cause all neighbors to drop 130 their adjacencies with the router that sent the IIH. This will also 131 cause the systems to update their Link State Protocol Data Units 132 (LSPs), flood them and reconverge to new paths. The technique is 133 known as Fast Exit Notification. 135 This approach is not guaranteed. If the final IIH is lost on the 136 link, then the neighboring systems will have to wait to time out the 137 adjacency. Since this is unlikely, it is still a useful 138 optimization. Implementations that require an even higher degree of 139 assurance can retransmit the final IIH, possibly multiple times. 141 3. Pseudonodes with Non-zero Metrics 143 If an operator wishes to reconfigure a multi-access LAN so that it is 144 only used as a resource of the last resort, then with current 145 mechanisms, the operator must reconfigure each node on the LAN to 146 give the LAN a high metric, as described in Section 1.2. It would be 147 much easier for the operator if they could make a single 148 configuration change that would cause IS-IS to treat the multi-access 149 LAN as a link of last resort. 151 [ISO 10589] defines the pseudonode LSP as having a metric of zero. 152 This implies that during the Shortest Path First (SPF) calculation, 153 the metric for traversing the LAN is solely based on the metric set 154 by the IS used to access the LAN. Thereby, the pseudonode does not 155 contribute to the cost of traversing the LAN. 157 However, from the point of view of the SPF calculation, the metric in 158 the pseudonode LSP does not have to be zero. Instead, the metric in 159 a pseudonode LSP could be treated just like a normal LSP and have 160 non-zero metrics to some or all of the systems on the LAN. This can 161 then be used to simplify the operation for turning a LAN into a link 162 of last resort. This could be done by having the Designated 163 Intermediate System (DIS) change all of the metrics within the 164 pseudonode LSP to a high value. This would effectively make the LAN 165 look very 'expensive' and cause SPF calculations to converge to 166 alternate links, if at all possible. 168 Because this change to the usage of the pseudonode LSP is in direct 169 contradiction to the existing IS-IS specification, extreme caution is 170 necessary. Implementations that would not interpret a non-zero 171 pseudonode metric correctly might cause forwarding loops. As of this 172 writing, we are actively surveying existing known implementations to 173 determine if setting a non-zero metric in a pseudonode LSP will be 174 interpreted properly. 176 This technique can also be used to divert traffic away from a subset 177 of the nodes on the LAN. If the DIS increases the metric from the 178 pseudonode to a subset of the systems on the LAN, then traffic will 179 avoid exiting the LAN via that subset of systems. 181 3.1. Operational Considerations 183 A further simplification is to allow any system to temporarily become 184 the DIS, when it is directed to, and set a non-zero metric in the 185 pseudonode. This is beneficial because the operator would otherwise 186 first have to determine the current DIS, access that system and 187 reconfigure it. If an implementation wishes to support this, then it 188 can provide an operation that both changes its priority on the LAN so 189 that a node first becomes DIS and then generates a new pseudonode LSP 190 with the non-zero metric. 192 If there is a concern that the DIS may change, it is prudent to 193 define another node on the same LAN with the second highest priority 194 for becoming DIS. This node can be configured to also set the metric 195 in its pseudonode LSP appropriately if it becomes the new DIS. 197 4. Security Considerations 199 This document raises no new security issues for IS-IS. 201 5. Acknowledgements 203 The authors would like to thank Mike Shand, Dave Katz, Guan Deng, 204 Ilya Varlashkin, Jay Chen, Peter Ashwood-Smith and Les Ginsberg for 205 their contributions. 207 6. Normative References 209 [ISO 10589] 210 ISO, "Intermediate system to Intermediate system routeing 211 information exchange protocol for use in conjunction with 212 the Protocol for providing the Connectionless-mode Network 213 Service (ISO 8473)", ISO/IEC 10589:2002. 215 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 216 Requirement Levels", BCP 14, RFC 2119, March 1997. 218 [RFC3373] Katz, D. and R. Saluja, "Three-Way Handshake for 219 Intermediate System to Intermediate System (IS-IS) Point- 220 to-Point Adjacencies", RFC 3373, September 2002. 222 Authors' Addresses 224 Naiming Shen 225 Cisco Systems, Inc. 226 225 West Tasman Drive 227 San Jose, CA 95134 228 USA 230 Email: naiming@cisco.com 232 Tony Li 233 Cisco Systems, Inc. 234 225 West Tasman Drive 235 San Jose, CA 95134 236 USA 238 Email: tli@cisco.com 240 Shane Amante 241 Level 3 Communications 242 1025 Eldorado Blvd 243 Broomfield, CO 80021 244 USA 246 Email: shane@level3.net 248 Mikael Abrahamsson 249 Tele2 251 Email: swmike@swm.pp.se